I see it's advantages of having auto-documentation for each API. Thumbs up here.
Having said that, the amount of hoops one has to jump before completely adopting it - makes it 'meh'. There are lot of things : cache (clien-and-server), n+1, apollo (why?), deeply nested queries, schema stitching. The amount of patch work one needs to learn is not worth it.
I disagree. GraphQL is more difficult to implement than "bad REST", but probably easier to implement than "good REST", partially because there's very little tooling around good REST implementations.
If you just want JSON over HTTP with some status codes, then sure GraphQL is loads more work, but that's definitely not REST.
yes this
Qualifier: have not been able to use graphql yet, and I'd still like to try it out at least before making and judgements
Just some benefits we've seen:
- Automatic codegen in the client removes a lot of boilerplate.
- Verification of schemas in CI makes sure we don't "go backwards" on the API inadvertently.
- Documentation tooling that makes it easy to show API structure.
- Easy to generate schemas automatically from underlying data models in the backend service (database tables, ORM models, enums, etc).
- Great type safety compared to JSON over HTTP.
The innumerable patches/packages trying to fix what GraphQL lacks - goes to show it's a good idea at surface level yet poorly thought out from ground up.