I was recently introduced to the concept of Command & Query Responsibility Separation (CQRS), which if you’re unfamiliar, once explained will make perfect sense to you as well.
The basic concept is that every method should be either a command to perform an action, or a query that returns data, but not both.
This idea can be complex to set up, but will help with scalability, data schemas, security, and the separation of concerns.
Often times an application pulls a lot of different data based on the view and what is required, and object mapping can get messy amongst all the different data structures. Creating and updating information can require validation and logic, and get bulky and complicated.
CQRS separates these tasks into Commands and Queries — commands create, update, and delete data, while Queries read data, completing our full CRUD requirements.
There are still some different ways to go about implementing CQRS including utilizing two different databases that sync, one for reading data, and one for writing (or updating) data. Other implementations include the Event Sourcing Pattern where app state is kept as a sequence of events that represent changes to the data allowing the app to store and update current state and display different data based on user actions.
There are truly a ton of possibilities when it comes down to it, and I’ve only begun to brush the tip of the iceberg here. I’ll certainly be diving in deeper as I begin building my next full stack application.
Cheers, and I’ll see you again soon!