4 ms·
The GraphQL specification doesn't mention HTTP. It's just a query language, like SQL, but with a different focus. I understand what people complain about in thi
by jensneuse 4y ago
The GraphQL specification doesn't mention HTTP. It's just a query language, like SQL, but with a different focus. I understand what people complain about in this discussion. It makes sense. Talking GraphQL between client and server can be a headache. That said, I'd like to propose a completely different use case. Have you thought about using GraphQL as a "meta-language" to compose APIs? A pure Server-Side solution to manage APIs as "dependencies", and turn them into a JSON-RPC API as you need them. I wrote about this here: https://docs.wundergraph.com/docs/architecture/manage-api-dependencies-explicitly https://docs.wundergraph.com/docs/architecture/manage-api-de...
I'm curious what people think about this use case of the Query language.
- hn_throwaway_99 4y ago> It's just a query language, like SQL, but with a different focus. No, no, no! I love GraphQL, and have been using it on projects for many years now, but the thing that is difficult for me to forgive the original designers of the spec that they put "QL" in the name, confusing so many developers into thinking it is a generic query language. GraphQL is simply a spec and contract for exposing an API. Its "competing technologies" are things like RESTful APIs and gRPC. It really has nothing to do with a generic "query language" like SQL.
- mdaniel 4y agoIt is a query language in that one can select the fields one wishes to be returned, including conditional evaluation of interior clauses via e.g. https://spec.graphql.org/October2021/#sec--skip https://spec.graphql.org/October2021/#sec--skip The field selection is certainly possible in REST via something like /foo?include=a,b,c but starts to get just downright silly with /foo?include=a,b.c[1].d,e[*].f which has now become its own DSL