3 ms·

This. Exactly this! I think anyone with experience will realise that you can get pretty much all the benefits of GraphQL with just a more sophisticated RESTish

This. Exactly this! I think anyone with experience will realise that you can get pretty much all the benefits of GraphQL with just a more sophisticated RESTish API. There is however, one thing that I think GraphQL backends have that REST backends don't, and that's the idea of introspection. Every GraphQL backend must be able to serve it's API data models and types. And I think the community tooling that leverages this makes it an amazing experience for app developers. No SDKs, any GraphQL client works with any GraphQL backend. Codegen esp for Android type apps to skip boilerplate of mapping APIs to POJOs. IDE autocomplete. I really think that the killer feature of GraphQL is that. We built a JSON DSL over a normal POST endpoint. Most GraphQL advantages sound "not really true" to me because you can always achieve the same thing (almost) yourself anyway.

iEchoic 8y ago
Yup, agreed - the developer experience and the self-documenting nature of GraphQL is a big plus. I no longer use GraphQL, but this is something I miss about it. As you mention though, people often don't realize that GraphQL is just a way to tell an endpoint that you want information in a generic way, and a pattern for having that endpoint resolve information in a generic way. It's an abstraction on top of a normal service call, and like most abstractions, it gives you consistency and ease-of-use but not any new capabilities you didn't have before.
sixdimensional 8y ago
Just wanted to chime in, OData had basically the same idea, however, from personal observation, somehow just didn't really become so popular, maybe because of its original association with Microsoft, etc. and also partially maybe its implementation. But it was pretty close, and today a lot of products support OData. I did note recently while reviewing the Microsoft API standard guidelines they share on GitHub [1], that there is a non-OData standard, but OData like recommendation for working with queries across collections, which I find to be pretty good and pretty generic. It seems like today you can do what you said - a sophisticated RESTish API without the model metadata piece pretty easily - but that metadata piece adds a lot of value. [1] https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#9-collections https://github.com/Microsoft/api-guidelines/blob/vNext/Guide... - see sections on sorting, filtering etc.
- dragonshed 8y ago
  This used to drive me crazy when GraphQL was first announced without a working download, compared to OData and several usable implementations. At the time there was also a compelling js library supporting OData.. [1]. > Breeze.js: Rich Data Management for the JavaScript Client > Client-side querying, caching, dynamic object graphs, change tracking and notification, model validation, batch save, offline support ... [1] https://github.com/breeze/breeze.js https://github.com/breeze/breeze.js Unfortunately I never had the opportunity to use it for a real project. [Edit formatting]
  - sixdimensional 8y ago
    Yeah, I have a project recently where GraphQL is actually a good fit conceptually, but I need a complete .NET client/server implementation and the open source ones are just about there, but I was still not confident enough to use it yet. Ugh. That Breeze framework was actually always super impressive. I guess there's a company behind it too. I've implemented some stuff with Telerik Kendo UI and OData (data grids, pivot tables) and it also is still working really quite well.

iEchoic 8y ago

Yup, agreed - the developer experience and the self-documenting nature of GraphQL is a big plus. I no longer use GraphQL, but this is something I miss about it. As you mention though, people often don't realize that GraphQL is just a way to tell an endpoint that you want information in a generic way, and a pattern for having that endpoint resolve information in a generic way. It's an abstraction on top of a normal service call, and like most abstractions, it gives you consistency and ease-of-use but not any new capabilities you didn't have before.

sixdimensional 8y ago

Just wanted to chime in, OData had basically the same idea, however, from personal observation, somehow just didn't really become so popular, maybe because of its original association with Microsoft, etc. and also partially maybe its implementation. But it was pretty close, and today a lot of products support OData. I did note recently while reviewing the Microsoft API standard guidelines they share on GitHub [1], that there is a non-OData standard, but OData like recommendation for working with queries across collections, which I find to be pretty good and pretty generic. It seems like today you can do what you said - a sophisticated RESTish API without the model metadata piece pretty easily - but that metadata piece adds a lot of value. [1] https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#9-collections https://github.com/Microsoft/api-guidelines/blob/vNext/Guide... - see sections on sorting, filtering etc.

dragonshed 8y ago
This used to drive me crazy when GraphQL was first announced without a working download, compared to OData and several usable implementations. At the time there was also a compelling js library supporting OData.. [1]. > Breeze.js: Rich Data Management for the JavaScript Client > Client-side querying, caching, dynamic object graphs, change tracking and notification, model validation, batch save, offline support ... [1] https://github.com/breeze/breeze.js https://github.com/breeze/breeze.js Unfortunately I never had the opportunity to use it for a real project. [Edit formatting]
- sixdimensional 8y ago
  Yeah, I have a project recently where GraphQL is actually a good fit conceptually, but I need a complete .NET client/server implementation and the open source ones are just about there, but I was still not confident enough to use it yet. Ugh. That Breeze framework was actually always super impressive. I guess there's a company behind it too. I've implemented some stuff with Telerik Kendo UI and OData (data grids, pivot tables) and it also is still working really quite well.