Hacker News Reader

Comment by superice | Hacker News Reader

I like how GraphQL essentially popularized the advantages of a CQRS (without Event Sourcing!) approach for your public API by explicitly giving you different DTOs for queries and mutations. It's a pretty neat way of enforcing this while not being a super heavy handed framework like for instance Axon + Spring Boot tends to be.

View on HN

REST did the same with POST/PUT/DELETE vs GET. I mean, technically HTTP did, before that.

No, REST puts the Resource at the forefront, and normally you use different verbs on the same resource: you PUT/POST to create a new resource, you can then GET that resource to read it, you PUT/PATCH to modify it, you DELETE a resource to delete it.

CQRS usually means that Commands (modifying the system) are handled differently than Queries (checking the current state of the system).

Of course, you can absolutely create a REST API where there is one set of resources that you can modify but not read (Command resources), and one set of resources you can read but not modify (Query resources). But that would definitely not fit the general idea of what people expect from a REST API.

Also, such an API would be relatively hard to make HATEOAS-compliant, for those that care about "ultimate"/"true" REST.

No, I wasn't saying that REST was the same as CQRS. I was replying to the comment that made the case that GraphQL was similar to CQRS because it separated reads from writes by having queries and mutations. I'm saying that REST also separates reads from writes in almost identical capacity. Neither of them are comparable to CQRS.

>>I'm saying that REST also separates reads from writes in almost identical capacity.

Not really. REST just models everything as resources that are targetted by requests. REST states nothing about how rewuests should be segregated by commands and queries.

REST usually has the same content in your request replacing the entire resource on a PUT, or returning an identical thing on a POST. There is no difference in the schema of the JSON (or XML) you send and receive.

As a sibling comment said: if you implement GraphQL with DTOs that look exactly the same for reading and writing, sure, you won't have CQRS, but it seems like the structure encourages you not to do that since you explicitly CANNOT use the output types as your input types in a GraphQL schema. Besides, real world usages seem to mostly treat it in a CQRS-style way instead of just CRUD operations.

The parent claimed that GraphQL has different DTOs for reads and writes. That could make it CQRS compatible, couldn't it?

I don't know if it would be any more idiomatic for GraphQL than it would be for REST.

You could argue that a REST DTO for reads is a query string and a REST DTO for writes is a JSON body. That seems comparable to the GraphQL case to me.

In the end it's about whether the term tells you something about the architecture, and in neither of those cases would I gain useful knowledge of the system from someone saying "it's CQRS."

A better litmus test is probably something to do with enumerating possible commands. So a GraphQL API with a specific set of mutations could be a CQRS design. But if your mutations are just CRUD spelled differently, it's probably not.

Reply on news.ycombinator.com