4 ms·

Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving da

Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving data piece by piece in the frontend instead of leveraging GraphQL types and adding types, fields and field resolvers as needed so that the frontend can do one query to get all the data it needs. No wonder it feels like a clunky extra glue layer if it’s being used as one.

claytongulick 4y ago
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.
- eurasiantiger 4y ago
  You looked at GraphQL and did not see the forest for the trees. Use the @deprecated directive on your schema.

claytongulick 4y ago

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.
eurasiantiger 4y ago
You looked at GraphQL and did not see the forest for the trees. Use the @deprecated directive on your schema.