[randomdata]

You don't, obviously – we already talked about how many don't. But if you don't have a graph of "microservices" in which to query, what do you need GraphQL for? Especially if all you are doing is returning the results from a database. The database will already have its own API. Why not just use it? The native API is always going be better than your attempt to translate.

[hansonkd]

Because exposing your Database to the outside world is asinine. GQL sits between letting the frontend query semi-customizable queries and not having any customizability to select related resources.

[randomdata]

Nobody said you should expose your database to the outside world. Do you not understand the difference between APIs and services?

[hansonkd]

You said

> The database will already have its own API

Where is this API coming from? You have to build it. I'm saying you should make those APIs graphql apis though a language framework and not REST apis because GQL consuming GQL is much better than GQL consuming REST.

[randomdata]

Someone has to build it, but as long as you are using a popular DMBS the work is no doubt already done. All you need to do is stick your application-y bits in the middle – same as you have to do with GraphQL. Computers aren't exactly magic. It's all just 1s and 0s at the end of the day. You can do just about anything and make it work. But there are tradeoffs to different approaches. If GraphQL is the best choice for working with databases, why don't DMBSes use it natively?

[int_19h]

I'm curious as to why you believe that exposing direct SQL over the database is "asinine" but GQL is fine, given that either one is very generic, and e.g. the security issues are very similar (as the article points out).