4 ms·

I cant speak to Netflix's reasons, but one thing you get with GraphQL is a strongly-typed interface. REST has Swagger/OpenAPI, but it was tacked on as an aftert

I cant speak to Netflix's reasons, but one thing you get with GraphQL is a strongly-typed interface. REST has Swagger/OpenAPI, but it was tacked on as an afterthought and the tooling is often second-rate compared to GraphQL (which often allows you to make use of codegen). Strongly Schema'd interfaces makes client development go faster and smoother in general.

candiddevmike 3y ago
It's all JSON typically, I don't think you can really compare the two that way. They're both just contracts that you hope are respected.
barbazoo 3y ago
Couldn't that be dealt with by improving the tooling dev teams are using? I'm assuming a migration like the one described here are a huge effort.
- deckard1 3y ago
  yes. If GraphQL is anything it's absolutely batteries not included. When people speak of tooling they are almost certainly talking about Apollo. I think you could probably find a similar analog in the SOAP XML days. There were lots of vendors, lots of tooling, and mostly the same challenges and outcomes. It could be as nice as you wanted if you spent the time and effort getting there. To make this more concrete, GraphQL is "strongly typed" in the sense that you get a run-time error when you use the types incorrectly. That's fine for development. Not so much for production. In order to get end-to-end typing you need to integrate with TypeScript or whatever language you're using. That has its own set of challenges. Your build process needs to know which GraphQL endpoint to use (not so easy when doing development on the API or need to use staging environments, etc.) and then generate typings based on that. Errors are another GraphQL travesty. Do you use out-of-band HTTP errors? In-band error codes? Both? (ugh, but probably once more than 1 developer touches the code). Do those errors kill your entire query? What or who determines that? I could also mention caching. But that's enough headaches for today. You need tooling just to get up to bog standard HTTP and browser caching gives you for free.
  - satvikpendem 3y ago
    You can get compile time typing too, if you use GraphQL's unions. I wrote an example in my other comment: https://news.ycombinator.com/item?id=37125685 https://news.ycombinator.com/item?id=37125685 If unions are used for errors as well, you essentially have the Result/Either type inside GraphQL at compile time. This is much stronger than anything REST provides.
  - ttfkam 3y ago
    Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Examples of "batteries included" GraphQL. Combine with a type generator for the language of your choice (eg. https://the-guild.dev/graphql/codegen https://the-guild.dev/graphql/codegen), and you've got your client interface to avoid any type errors. Each comes with a GraphiQL UI for access out of the box as well. It's more turnkey than any REST solutions I've seen, that's for sure. For different environments, it's quite possible (even normal?) to generate your types and GraphQL schema ahead of time, before CI/CD build of the UI to catch errors early at compile time. Now add in SvelteKit with KitQL (https://www.kitql.dev/ https://www.kitql.dev/), and you've got a very simple, flexible, and efficient end-to-end solution. As for errors, because each resolver can generate errors and not all errors are considered fatal, the errors must necessarily be embedded with the response and treated by the network client as they see fit. It's definitely different from REST, but not inferior. It's a different set of tradeoffs. When using a schema generator like Postgraphile or Hasura, it's unlikely you'd get errors in practice. The endpoints are basically guaranteed to resolve, and the generated SQL is nigh certain to execute correctly. If you get one error, chances are the whole endpoint is down due to a database connectivity problem. (That has been my experience at any rate.) Don't take my word for it. Bring up a Postgres database, put some data in, and point one of these tools at it. I think you'll be pleasantly surprised. You may still prefer REST (or gRPC), but I think we can both agree that "batteries included" is definitely an option with GraphQL.
tmpz22 3y ago
> Strongly Schema'd interfaces makes client development go faster and smoother in general. What trade-offs exist for strongly typed schemas? It reminds me of indexing database inserts, longer to write and faster to subsequently query. I would argue strong schemas require more design and architectural discipline during constructions and are thus easier to consume down the line. To quote Bay Area rapper G-eazy "everything costs something bro"
gitaarik 3y ago
What do you mean with an afterthought and second rated? Maybe you mean that it's not defined in the "protocol" itself, REST is not really much of a protocol anyway, but rather a set of guidelines on how to use HTTP sanely to make a CRUD API. You can still have all your REST API's from your application follow a certain agreed on "REST protocol". If you use a framework / library for making the API then usually you don't really have to think about that (much).

candiddevmike 3y ago

It's all JSON typically, I don't think you can really compare the two that way. They're both just contracts that you hope are respected.

barbazoo 3y ago

Couldn't that be dealt with by improving the tooling dev teams are using? I'm assuming a migration like the one described here are a huge effort.

deckard1 3y ago
yes. If GraphQL is anything it's absolutely batteries not included. When people speak of tooling they are almost certainly talking about Apollo. I think you could probably find a similar analog in the SOAP XML days. There were lots of vendors, lots of tooling, and mostly the same challenges and outcomes. It could be as nice as you wanted if you spent the time and effort getting there. To make this more concrete, GraphQL is "strongly typed" in the sense that you get a run-time error when you use the types incorrectly. That's fine for development. Not so much for production. In order to get end-to-end typing you need to integrate with TypeScript or whatever language you're using. That has its own set of challenges. Your build process needs to know which GraphQL endpoint to use (not so easy when doing development on the API or need to use staging environments, etc.) and then generate typings based on that. Errors are another GraphQL travesty. Do you use out-of-band HTTP errors? In-band error codes? Both? (ugh, but probably once more than 1 developer touches the code). Do those errors kill your entire query? What or who determines that? I could also mention caching. But that's enough headaches for today. You need tooling just to get up to bog standard HTTP and browser caching gives you for free.
- satvikpendem 3y ago
  You can get compile time typing too, if you use GraphQL's unions. I wrote an example in my other comment: https://news.ycombinator.com/item?id=37125685 https://news.ycombinator.com/item?id=37125685 If unions are used for errors as well, you essentially have the Result/Either type inside GraphQL at compile time. This is much stronger than anything REST provides.
- ttfkam 3y ago
  Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Examples of "batteries included" GraphQL. Combine with a type generator for the language of your choice (eg. https://the-guild.dev/graphql/codegen https://the-guild.dev/graphql/codegen), and you've got your client interface to avoid any type errors. Each comes with a GraphiQL UI for access out of the box as well. It's more turnkey than any REST solutions I've seen, that's for sure. For different environments, it's quite possible (even normal?) to generate your types and GraphQL schema ahead of time, before CI/CD build of the UI to catch errors early at compile time. Now add in SvelteKit with KitQL (https://www.kitql.dev/ https://www.kitql.dev/), and you've got a very simple, flexible, and efficient end-to-end solution. As for errors, because each resolver can generate errors and not all errors are considered fatal, the errors must necessarily be embedded with the response and treated by the network client as they see fit. It's definitely different from REST, but not inferior. It's a different set of tradeoffs. When using a schema generator like Postgraphile or Hasura, it's unlikely you'd get errors in practice. The endpoints are basically guaranteed to resolve, and the generated SQL is nigh certain to execute correctly. If you get one error, chances are the whole endpoint is down due to a database connectivity problem. (That has been my experience at any rate.) Don't take my word for it. Bring up a Postgres database, put some data in, and point one of these tools at it. I think you'll be pleasantly surprised. You may still prefer REST (or gRPC), but I think we can both agree that "batteries included" is definitely an option with GraphQL.

tmpz22 3y ago

> Strongly Schema'd interfaces makes client development go faster and smoother in general. What trade-offs exist for strongly typed schemas? It reminds me of indexing database inserts, longer to write and faster to subsequently query. I would argue strong schemas require more design and architectural discipline during constructions and are thus easier to consume down the line. To quote Bay Area rapper G-eazy "everything costs something bro"

gitaarik 3y ago

What do you mean with an afterthought and second rated? Maybe you mean that it's not defined in the "protocol" itself, REST is not really much of a protocol anyway, but rather a set of guidelines on how to use HTTP sanely to make a CRUD API. You can still have all your REST API's from your application follow a certain agreed on "REST protocol". If you use a framework / library for making the API then usually you don't really have to think about that (much).