4 ms·
> To start with, it’s not as though client developers can compose arbitrary queries, limited only by the semantics of GraphQL, and expect to get uni
by tuukkah 8y ago
> To start with, it’s not as though client developers can compose arbitrary queries, limited only by the semantics of GraphQL, and expect to get uniformly decent performance. (To be fair, the same is true of SQL.)
Maybe I'm missing something, but isn't that exactly what you can expect from a GraphQL API as a sweet spot between SQL and REST? Semantics of GraphQL enable a schema-dependent set of queries, not arbitrary queries.
> Anyhow, I see GraphQL as a convenience feature designed to make synchronous APIs run more efficiently.
For asynchronicity, GraphQL has subscriptions.
That being said, I agree GraphQL (of today at least) won't be a solution to every problem and I bet transports such as HTTP/2 and HTTP/3 will cause new things to be built which don't look like just a faster REST, GraphQL or MQTT. I would mention event sourcing and persistent logs in addition to just stream/queue processing.
Tooling (like API management gateways and API consoles) is not still all there for GraphQL and MQTT either.
- tootie 8y agoI'm surprised we haven't seen more development already with HTTP/2 REST APIs. It let's you do your API at whatever logical level makes sense and then do your orchestration independently.
- cryptonector 8y ago> Semantics of GraphQL enable a schema-dependent set of queries, not arbitrary queries. I mean, in SQL useful queries are generally schema-dependent. Sure, you could have XPath/JSONPath/whatever extensions that allow you to query something closer to free-form documents, but your queries will still be schema-dependent in some way.
- tuukkah 8y agoSQL schema defines data and you cannot limit which queries are available on that data, whereas GraphQL schema defines both data and which queries are available.
- deleted 8y ago[deleted]