| - what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees? With REST you can have an N+1 query, but you're making multiple round trips from the client to the server. With GraphQL, you can also write an N+1 query, so you can shoot yourself in the foot either way. I would probably use graphql-middleware to log the backend calls, or just look at my backend's log, identify the N+1 query and instrument data loader to batch it out. But of course you should load test your app before even shipping it so why would you have this problem unless you do not test? - what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs? I can add the field without impacting existing clients that I have shipped. With REST, the old clients would also get the new field. - if your teams are dysfunctional, then of course, that's what you will end up having. The point is that your teams can function independently of each other, each focusing more effort on doing their own job & less time syncing with the other team. |
With REST I can specifically optimise the calls because I know the contract and the possible incoming/outgoing requests.
> I can add the field without impacting existing clients that I have shipped. With REST, the old clients would also get the new field.
Why are so many people discussing REST in GraphQL threads so oblivious of what REST is?
One word: versioning
> The point is that your teams can function independently of each other, each focusing more effort on doing their own job & less time syncing with the other team.
Don't blame your failing processes on technology. There's nothing magical in GraphQL that makes it a magical thing making teams independent of each other. Tell me: what happens when frontend team requests data that's not exposed in the GraphQL schema?