[siscia]

I completely agree!

I really don't understand why we don't simply ship SQL queries around, maybe a very simple subset of SQL so that it either works on most vendors or that it can be easily manipulated and adapt to different storage backend.

Can somebody enlight me?

[bryanrasmussen]

it is unlikely that all the data sources you will be querying now are directly available in an SQL database.

[siscia]

For sure they are not available in a /rest or GraphQL engine neither.

SQL should be only the syntax used to communicate with the backend, the real implementation would be in whatever make sense.

[notus]

That would require you to map the SQL to something else which would then map back to SQL or mongo or w/e. For example if you're trying to join data from multiple microservices you can't execute the join because most microservices setups are not going to allow joins. The joins would have to be mapped to service to service calls and at this point you're just rebuilding an orchestration layer which has already been solved by graphql.

[siscia]

So we invented a query language (GraphQL) to solve an orchestration problem?

Sorry but I don't buy this reason. Especially not to the question: "Why we don't use SQL as a query language?" especially because REST was around way earlier than GraphQL.

Your reasoning could be great to answer the question: "Why we like GraphQL where there are a lot of microservices?"

BTW, there is nothing inherent in the language in itself, if each microservices would be speaking SQL, you would simply need to optmize your SQL query, decompose your optimized SQL query creating simpler queries one for each microservice, send each of those queries to the relative microservices, compute back the final result.

If you replace "microservices" with "table" here you get the standard way an SQL engine works :)

Please, it is not that I am against GraphQL, but it honestly seems like some engineer at facebook was annoyed by SQL, and decide to re-invent it. And that we are all following him or she just because they worked at facebook, which seems unwise.

Maybe the use of types? But what is the difference between a type and something that belong to a table?

Anyway, I am looking now at [GraphQL: The Documentary (Official Release)][1]

[1]: https://www.youtube.com/watch?v=783ccP__No8&feature=youtu.be

[xwowsersx]

> So we invented a query language (GraphQL) to solve an orchestration problem? Sorry but I don't buy this reason.

Exactly. I came here to say the same thing. This seems like an attempt to justify the existence of a thing after-the-fact. And it's a reason which isn't even the stated reason of the project itself!

[bryanrasmussen]

There is nothing about GraphQL that makes me think someone invented it because they were annoyed by SQL and decided to reinvent it, generally reinvention means a lot of similarity only badly done. You might argue GraphQl is badly done in comparison to SQL, but surely not that it is similar.

[siscia]

Honestly I don't use it so often, but it seems that any query in graphql could be easily and automatically translated to a SQL query. Am I wrong?

There are definitely trying to solve the same problem, aren't they? What are the advantages of GraphQL over SQL?

Please, I really want to know the answer to this question.

The previous answer was "the infrastructure we build around GraphQL is better for microservices", ok I can see that. But it is the only answer? It seems like a little weak reason to create a language so that later you can create a new infrastructure around it.

Am I missing something?

Why you don't find GraphQL similar to SQL?

[thrower123]

Exposing that much of your internal implementation details could be very problematic.

[siscia]

Sorry, I realize my first message wasn't as clear as I wanted.

You would not expose the internal implementation, you would simply accept SQL queries, maybe against a separate view of your SQL database, or maybe against a custom backend.

SQL shuould be the query languange, not the implementation.

[onlydnaq]

That’s exactly what I meant as well. SQL may be the implementation, but if so with a well designed exposed schema, not with the application internals.