4 ms·

Some of us learned these lessons in the SOAP/WSDL/XML-RPC days, and learned to embrace the principles of REST to a avoid exactly those issues. I looked at grap

Some of us learned these lessons in the SOAP/WSDL/XML-RPC days, and learned to embrace the principles of REST to a avoid exactly those issues. I looked at graphql and saw a return to the horror of DoSomethingBecauseItsMondayAndDueTomorrow() type API methods. Hundreds or thousands of them that accumulate like cruft over time, and no one can delete anything because you have no idea what it'll break. I stick with well designed and well planned REST APIs. It's not a panacea, but it helps.

pjmlp 4y ago
Did we? Hello gRPC, Web sockets and language specific SDKs for REST APIs, as no one actually uses REST as designed.
roflyear 4y ago
> and no one can delete anything because you have no idea what it'll break. This is a problem with GraphQL, but you can monitor if anyone is requesting that data. Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc. GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful. It depends if you're in that situation or not, or what parts of your domain are in those situations. I don't think "GraphQL everywhere" is sane.
- claytongulick 4y ago
  > Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc. Most sane REST-like implementations also support this, typically with query string modifiers like a "fields" param or similar. A lot of them also support deep relationships this way too. For example, the Directus REST API is completely feature compatible with the GraphQL API.
  - roflyear 4y ago
    Well, yes, but not really. With GraphQL you can have one user: - Request the users, their IDs, and emails, and their post ids Or: - Request the user, tons of profile information about them, and the posts with all the info about the posts You'd have to implement all this filter stuff for REST - and at this point if you have a bunch of different queries, yeah GraphQL makes sense.
    - claytongulick 4y ago
      You should really check out modern REST APIs. Again, as an example, Directus supports doing everything you just said over both REST and GraphQL. There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever. You may also want to take a look at HATEOAS and JSON:API and similar. REST-like APIs have long had feature parity with GraphQL and also superior mechanisms for caching etc...
      - roflyear 4y ago
        Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something? I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard. GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if you think they have some aversion to POSTing JSON for a query.
        claytongulick 4y ago
        > is it just "we don't like GraphQL" or something? Yes. But not without reason. GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs. You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc... This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that. With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design. GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport. Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1]. [1] https://jsonpatch.com/ https://jsonpatch.com/
eurasiantiger 4y ago
You looked at GraphQL and did not see the forest for the trees. Use the @deprecated directive on your schema.

pjmlp 4y ago

Did we? Hello gRPC, Web sockets and language specific SDKs for REST APIs, as no one actually uses REST as designed.

roflyear 4y ago

> and no one can delete anything because you have no idea what it'll break. This is a problem with GraphQL, but you can monitor if anyone is requesting that data. Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc. GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful. It depends if you're in that situation or not, or what parts of your domain are in those situations. I don't think "GraphQL everywhere" is sane.

claytongulick 4y ago
> Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc. Most sane REST-like implementations also support this, typically with query string modifiers like a "fields" param or similar. A lot of them also support deep relationships this way too. For example, the Directus REST API is completely feature compatible with the GraphQL API.
- roflyear 4y ago
  Well, yes, but not really. With GraphQL you can have one user: - Request the users, their IDs, and emails, and their post ids Or: - Request the user, tons of profile information about them, and the posts with all the info about the posts You'd have to implement all this filter stuff for REST - and at this point if you have a bunch of different queries, yeah GraphQL makes sense.
  - claytongulick 4y ago
    You should really check out modern REST APIs. Again, as an example, Directus supports doing everything you just said over both REST and GraphQL. There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever. You may also want to take a look at HATEOAS and JSON:API and similar. REST-like APIs have long had feature parity with GraphQL and also superior mechanisms for caching etc...
    - roflyear 4y ago
      Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something? I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard. GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if you think they have some aversion to POSTing JSON for a query.
      - claytongulick 4y ago
        > is it just "we don't like GraphQL" or something? Yes. But not without reason. GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs. You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc... This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that. With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design. GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport. Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1]. [1] https://jsonpatch.com/ https://jsonpatch.com/

eurasiantiger 4y ago

You looked at GraphQL and did not see the forest for the trees. Use the @deprecated directive on your schema.