4 ms·

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 man

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
    GraphQL enables entity-level caching. That is not possible in REST.
  - roflyear 4y ago
    Oh, totally agree the best cases for GraphQL are like 10% or so of the usecases for APIs. I don't think you should use it everywhere. I also think GraphQL should never be used for updating data, just that it is nice for a segment of problems related to querying data.

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
  GraphQL enables entity-level caching. That is not possible in REST.
- roflyear 4y ago
  Oh, totally agree the best cases for GraphQL are like 10% or so of the usecases for APIs. I don't think you should use it everywhere. I also think GraphQL should never be used for updating data, just that it is nice for a segment of problems related to querying data.