Comment

Comment by erikpukinskis

I don’t really think of GraphQL as a data querying language like SQL.

I think of it as a domain querying language.

SQL is meant to allow you to write queries to your data model which are:

- arbitrary, and

- efficient

I don’t think of GraphQL that way. I think of it as the place where you encode your set of valid domain actions (i.e. not arbitrary). And I don’t think the consumers of the GraphQL API should think about efficiency. They should just specify what data they need and then the backend is responsible for figuring out how to query the data model efficiently.

In other words, I don’t really see any overlap between GraphQL and SQL in terms of the role they play in a stack.

One helpful thing this distinction allows, is type inference. You can trivially write a type generator that gives you the type signature of a GraphQL query in any language. This is precisely because of its limitations. That allows you to automate the validation of your frontend and backend speaking the same language.

You can’t easily infer the return types of arbitrary SQL queries. To me, that highlights the different purposes of the languages.

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton