Hacker News Reader

Comment by dmitriid | Hacker News Reader

GQL, in no particular order:

- GQL allows unbounded arbitrary queries. The awkward workarounds turn it into REST with none of REST semantics

- default query method (POST) cannot be cached by literally anything in the infrastructure because POST is not cacheable by definition. The awkward workarounds require you to parse and look up fields in both request and response. Both of them arbitrarily large.

- instead of delegating requests to optimized queries (db or services) you now collect all that data manually, in-memory, on the server with little to no insight into what the data is, and how to optimize its retrieval

- default types doesn't provide useful primitives like dates

- you now have to keep up with evolution of every single microservices you depend on

There's more that I've forgotten.

It's really good for building internal tools that usually have different requirements than what existing APIs provide you

View on HN

> - GQL allows unbounded arbitrary queries. The awkward workarounds turn it into REST with none of REST semantics

This is essentially a solved problem. You simply give all your fields a complexity value and then you limit the allowed complexity.

> - instead of delegating requests to optimized queries (db or services) you now collect all that data manually, in-memory, on the server with little to no insight into what the data is, and how to optimize its retrieval

Or you simply integrate tightly with an ORM or something and generate optimized queries from your GQL queries.

> - default types doesn't provide useful primitives like dates

Just not really an issue in practice, and really comes down to the underlying transport medium. JSON is limited. If you send a date over the string, it's either going to be a timestamp or a string. Your consumer will still need to know it's actually a date that needs to be deserialized. At least in GQL this is easy to do.

> - you now have to keep up with evolution of every single microservices you depend on

How is this a problem with GQL? Do you think that API versioning is in any way easier to when you have REST APIs? It's actually the opposite, because OpenAPI schemas suck and there is no great tooling that helps you stay on top of the changes. In contrast, there is excellent tooling for GQL that literally diff your new schema vs the old and tell you if any recent clients would be affected. You can do all this as part of your workflow(in CI etc) and act accordingly.

> This is essentially a solved problem. You simply

> you simply integrate

> or something

"simply", "essentially", "something". An equivalent of "just".

In reality: none of this is solved, non of this is "simply" etc. because every single lib and framework (often multiple for a language) will have their own awkward workarounds for these "solved" problems.

> Just not really an issue in practice, and really comes down to the underlying transport medium. JSON is limited

It is an issue in practice because every single framework does implement a date/time/datetime extension to built-in types. And this has nothing to do with JSON. Every single modern protocl for some reason forgets that dates, times and timestamps are sued everywhere and by everyone. See protobuf for example. Encodes to binary, has no dat representation.

> How is this a problem with GQL? Do you think that API versioning is in any way easier to when you have REST APIs?

Yes. API versioning is easy with REST API. You can even evolve schema versions for the same resource without ever changing the endpoint by looking at "Accepts" headers. When you have ad-hoc clients doing ad-hoc queries with GQL you can't even be sure which particular subset of data is requested by whom, and can you remove or deprecate or change it.

Yeah, yeah, here the "solution" is to use a hack called "persisted queries" which is literally REST but with all the good parts removed, and a lot of unnecessary steps added.

Reply on news.ycombinator.com