4 ms·

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.

by samblr 8y ago

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 8y ago
> 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.
- spiritcat 8y ago
  "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 8y ago
    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.
- samblr 8y ago
  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.

by samblr 8y ago

danpalmer 8y ago

> 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.

spiritcat 8y ago
"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 8y ago
  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.
samblr 8y ago
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.