[RussianCow]

> If we consider GraphQL to be a domain querying language, what have we gained over REST?

Part of the value is in standardization. Yes, you can get most of the benefits of GraphQL by creating your own layer over REST, but then you've just written a badly specified, bug-ridden version of GraphQL. The latter has enough momentum that there now exist tons of tools for working with it, which obviously wouldn't be true for anything you build yourself.

> Most sufficiently ORMs can also give you this, and in other languages there are libraries that will compile-time-check the arbitrary SQL queries you write and won't compile if they're invalid.

You're missing the point here: GraphQL gives you type safety between the server and client. This has nothing to do with ORMs or your database. What this means is that, when building your web (or Android, or iOS, or refrigerator, or whatever) frontend, you can guarantee the type of every part of your query before even executing it. This is a powerful guarantee, and paired with something like GraphiQL[0], it allows for a level of exploratory programming that isn't currently possible with REST.

[0]: https://graphql.org/swapi-graphql

[hardwaresofton]

> Part of the value is in standardization. Yes, you can get most of the benefits of GraphQL by creating your own layer over REST, but then you've just written a badly specified, bug-ridden version of GraphQL. The latter has enough momentum that there now exist tons of tools for working with it, which obviously wouldn't be true for anything you build yourself.

Right, and you could have done this standardization somewhere else right -- GraphQL is a NIH version of what could have existed on top of well-considered existing standards.

> You're missing the point here: GraphQL gives you type safety between the server and client. This has nothing to do with ORMs or your database. What this means is that, when building your web (or Android, or iOS, or refrigerator, or whatever) frontend, you can guarantee the type of every part of your query before even executing it. This is a powerful guarantee, and paired with something like GraphiQL[0], it allows for a level of exploratory programming that isn't currently possible with REST.

I was responding to the point the person made in particular, I'm aware of the mismatch in tiers, but their question was specifically about being able to infer types from SQL queries. They were comparing SQL to GraphQL. There is nothing stopping you from using compile-time-checking on the client side, if you use something like TypeScript, which is why the rest of the surrounding example was given.

This also is related to the database, because the original point was that people go GraphQL -> Resolver -> DB, rather than HTTP -> HTTP Endpoint -> DB, and because they have chosen GraphQL, they must now write efficient, general resolvers that are essentially hand-built query optimizers whereas with REST you can build with higher granularity and usually higher, easier-to-achieve efficiency.

You can guarantee every part of your query with REST as well, if what you mean is you can avoid writing an invalid query -- Typescript + generated OpenAPI client libraries do this very well -- it's not unique to GraphQL.

[RussianCow]

> Right, and you could have done this standardization somewhere else right -- GraphQL is a NIH version of what could have existed on top of well-considered existing standards.

Maybe, but I think building GraphQL on top of REST would have produced something much more convoluted and verbose. As an example, see the OData standard[0], which, at least from the client's perspective, is unnecessarily complex compared to GraphQL. There may be cleaner ways to structure this, but I'm not aware of any such attempts, and I doubt you'd get a result as easy to use and understand as GraphQL.

> This also is related to the database, because the original point was that people go GraphQL -> Resolver -> DB, rather than HTTP -> HTTP Endpoint -> DB, and because they have chosen GraphQL, they must now write efficient, general resolvers that are essentially hand-built query optimizers whereas with REST you can build with higher granularity and usually higher, easier-to-achieve efficiency.

That's fair, but as you pointed out earlier, you're just shifting complexity around in any case. REST is simple because it's so granular, which is great when all of your data needs are met by that granularity. As soon as you have more complex data requirements, you end up either making ad hoc endpoints or evolving your API into a giant monstrosity so that you can handle the more general cases. GraphQL significantly simplifies this implementation on both the client side and the API side. Yes, the tradeoff is that now you need to optimize your data access manually, but as others have said, there are now tools for dealing with this issue—and it's not like you don't gain anything from it.

For a simple but concrete example, if I need to fetch data from ten different entity types in order to render a page in my web app, I can do so in a single GraphQL query and handle caching, etc in one pass, as opposed to needing ten different REST calls and having to consolidate them by hand. On top of the maintainability benefits of this approach, the productivity gains are huge.

[0]: https://www.odata.org/

[hardwaresofton]

> Maybe, but I think building GraphQL on top of REST would have produced something much more convoluted and verbose. As an example, see the OData standard[0], which, at least from the client's perspective, is unnecessarily complex compared to GraphQL. There may be cleaner ways to structure this, but I'm not aware of any such attempts, and I doubt you'd get a result as easy to use and understand as GraphQL.

I'd never heard of OData, thank you very much for the link! I've been meaning to give it a shot (try to put together a GraphQL using the other REST tools/standards), if I do I will definitely post it to HN. I agree that it would likely look more complex in the naive case but that could be ironed out -- the foundations feel identical. GraphQL's productivity and ergonomics are definitely something to strive for on the REST side.

> That's fair, but as you pointed out earlier, you're just shifting complexity around in any case. REST is simple because it's so granular, which is great when all of your data needs are met by that granularity. As soon as you have more complex data requirements, you end up either making ad hoc endpoints or evolving your API into a giant monstrosity so that you can handle the more general cases. GraphQL significantly simplifies this implementation on both the client side and the API side. Yes, the tradeoff is that now you need to optimize your data access manually, but as others have said, there are now tools for dealing with this issue—and it's not like you don't gain anything from it.

True -- growth of REST API endpoints is somewhat unbounded and it gets harder and harder to differentiate/name endpoints and separate functionality in a satisfying way. There was another comment[0] that showed the gains that a small team got from GraphQL, I can't argue with that. It does work extremely well for some teams.

> For a simple but concrete example, if I need to fetch data from ten different entity types in order to render a page in my web app, I can do so in a single GraphQL query and handle caching, etc in one pass, as opposed to needing ten different REST calls and having to consolidate them by hand. On top of the maintainability benefits of this approach, the productivity gains are huge.

This has been an oft-cited benefit of GraphQL, and it looks like a legitimate clear benefit -- not having to think about that is indeed very nice.

[EDIT] - Yeah after poking around OData for a bit, I don't think I'll be touching that but it's nice to know it exists.

[0]: https://news.ycombinator.com/item?id=26226642

[RussianCow]

> I've been meaning to give it a shot (try to put together a GraphQL using the other REST tools/standards), if I do I will definitely post it to HN.

Please do! I'd love to see what you come up with.