[hn_throwaway_99]

Aaaaarrrgggghhh! I feel like I post this same comment whenever the discussion is about GraphQL.

I love GraphQL. What I hate about GraphQL is that it has "QL" in the name, so it confuses people into thinking it's somehow comparable to SQL. The question "How is GraphQL for aggregate queries?" doesn't even make sense.

GraphQL is simply another format for APIs. E.g. you could do APIs with SOAP, using REST, or with GraphQL.

[wasd]

Actually, that's really helpful. Thank you! I was under the impression GraphQL was API end point and query resolver (so it knows how to do GraphQL -> SQL).

[wenbert]

Same. I wished they didn't call it GraphQL. When I first looked into this, I had to explain to people that it was just a spec. A spec that can be implemented in different languages. It is not SQL.

I jumped into GraphQL form the PHP side. And after understanding what it was the next step was simplly exposing an endpoint. From there, https://webonyx.github.io/graphql-php/ took over.It went like: Route --> Controller/action --> Use `graphql-php`. For the resolvers, I was able to re-use the services the returned data.

The "entry barrier" to the existing legacy-ish framework we were using wasn't too hard. But the learning curve to solve problems in "GraphQL way" is much harder to push as most people are used to REST way of doing things.

[acjohnson55]

Totally. As I tell people, it's neither a query language, nor particularly graph-oriented. I describe it instead as a toolkit for writing custom domain-specific languages for your services.

[chrismorgan]

Eh, I’d call it a query language in the same way that I’d call XML a language. I’ve heard the term metalanguage bandied about for XML, but it never really seemed to catch on. GraphQL could perhaps be called a query metalanguage, defining grammar and language semantics.

[acjohnson55]

They're both metalanguages to me. You use them to define domain-specific languages. We may as well throw JSON in the mix, too. Sure, it's a language with its own grammar, but it's only really useful when implementing the semantics of an API contract (whether that contract is explicitly specified or not).

The reason I object to the "query" part is that GraphQL has no built-in operators that true query languages invariably have. All you really get is inclusion of fields into your request and parameterization. All other semantics have to be implemented by the user in their own spec.

[steveklabnik]

Yes, this caused major confusion for me for a very long time. I assumed that it was like MySQL/Postgres, with different data stores implementing a query language. That’s really only Fauna.