I went to a talk where it labeled it as halfway between a dsl and sql. I haven't used it in about a year. ``` user { id, first_name } ``` would on the b

I went to a talk where it labeled it as halfway between a dsl and sql. I haven't used it in about a year. ``` user { id, first_name } ``` would on the back end map to a function that runs something like. ``` select id, first_name from users ``` So the fields are dynamic in a way. Allowing you to select only the data you want. You can also nest data calls, like joins. ``` user { id, first_name, user_profile { bio, recent_comments } } ``` This would execute the above. Then take that user object into a query context. That query context allows you grab any elements from the parent returned object. I.E. the user id. That would then execute the nested query like ``` select bio, recent_comments from user_profile where id = $user.id ``` So instead of rest end points. You are building a number of functions that return an object. You can then define relations that operate off of those returned objects. You can also restrict queries in production. So only white listed / approved queries are run. A schema is a list of all these objects that may be returned and their relation also including type. Instead of a reverse proxy like nginx. There is schema stitching. Which combines all the schemas into one big schema. When querying it will proxy the respective calls to the respective back end services. I did a talk on GraphQL a bit ago, so it may be out dated. https://blog.animus.design/kotlin-backend-presentation/ https://blog.animus.design/kotlin-backend-presentation/ Corresponding repo https://gitlab.com/AnimusDesign/KotlinIMDBDemo/blob/master/api/src/main/java/design/animus/kotlingraphqlrestpresentation/api/graphql/service/NameBasicService.java https://gitlab.com/AnimusDesign/KotlinIMDBDemo/blob/master/a... I've not used Graphql in production. When I was researching it's ecosystem anything outside of JS leaved a bit to be desired. That being said. It's a solution to a problem. Openapi can generate clients. But if you need to make six calls. It's not performance or transit time. It's cleaning up the errors on that. Waiting for one to respond then another. From that vantage point I see the benefit. One query get what you need. If anything fails along the way it stops. It shifts the error checking pattern to the server. Additionally in react and even mobile. There are redux or state machine stores that operate strictly off of graph ql. You've now centralized data retrieval, and state management of the app. That's a pretty big win. https://www.apollographql.com/docs/react/data/local-state/ https://www.apollographql.com/docs/react/data/local-state/ All of this is very beneficial to the front end / mobile. Easing data retrieval, being more expressive and type safe. But it's the front end driving how data is presented and stored to an extent. By using graphql to get the best support you should be running on node.