[chrisquinnr]

>I have felt strongly that we would have been better off with a more boring approach like REST

What led you to this feeling? I know you want to hear from people on why GraphQL is good, but why would REST have been a better choice in that situation? I'm interested as someone who works with both day to day.

[langsa]

Thanks for your reply, I would love to hear more about which one you prefer in general REST or GraphQL, or if you have different situations where you choose one or the other and why.

Here were some of the things I noticed when comparing to REST:

  - Caching can become a nightmare and requires a lot of effort to get working correctly for non trivial use 
    cases / you cannot really use the already "built in" cache control headers in the browser with GraphQL

  - Another caching one, but you almost are required to have some kind of server side cache in addition to 
    the client side cache, it can quickly become disorienting trying to figure out exactly where something 
    is cached and why, or why you are getting stale data, etc...

  - Some abstractions in GraphQL can make the code hard to follow / read in my opinion (data loaders for 
    example) and also make it hard to follow where the data is actually coming from especially in federated 
    subgraphs

  - Error handling in GraphQL can be really unintuitive and more work is needed to not have the error 
    response come back as a 200 status code (or handle it correctly if it is an error inside of a 200)

[Xt-6]

- monitoring and observability are more complex/require more tools to work and/or extra convention like forcing people to name their queries

[ipaddr]

The tone from the author is less complexity. It's a backend vs frontend debate. GraphQL can be magic from the client side but on the server side you have tons of boilerplate weighing you down.

[paulddraper]

REST is simpler to implement and understand.