CQRS (The Command and Query Responsibility Segregation) is an architectural principle when the api is divided into 2 parts:
- requests (without changing data)
- changing data (without giving back data, only the id of the created object is possible if it was not transmitted, but generated by the server)
It is clear that with such a division there are several advantages:
- you can separately scale parts of the application to read and write
- it’s easier to cache data
- there are fewer changes to the api and they are more targeted – you do not need to build all the options for changing and returning data in requests
And minus:
- you need to make several requests if you want to get some changed data immediately after the change
Separately, I will say that CQRS itself does not say what should happen when there is a request to read data immediately after the change: is the system obliged to always return new data or is there some kind of lag for synchronization.
GraphQL has built-in support for CQRS. There it is called query and mutation.
CQRS performs well, especially in conjunction with GraphQL – when each call location can get the data that is needed.
As an additional material, I can recommend https://cqrs.nu/faq – short, succinct questions and answers.