[samblr]

Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST.

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.

[danpalmer]

> Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST.

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.

[samblr]

If only Facebook was not behind GraphQL - this would have faded to oblivion (RIP Parse)

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.

[spiritcat]

"If you just want JSON over HTTP with some status codes"

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

[danpalmer]

GraphQL costs a lot more to do, but also gives you a lot more.

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.