[hansonkd13]

OK to give you a clear example.

Say you have a REST interface for Student and Class.

What do you do in rest if you want to get just a class? What do you do if you want to get a class and its students? What do you do if you want to get a Student and also its class?

For every iteration of the way you need to access the data you have to modify and extend your REST endpoint or do separate queries. Every time the frontend devs want new data related to existing data, they have to do another query or ask the backend to include it.

Or lets say Class has 1000 attributes. Does your REST interface return all 1000 every time? Or can the frontend specify which attributes to load? Things like computed attributes and functions that return data related to the object. GraphQL allows this.

In graphql doing these relationships is dead easy. You define a class and how a student is related to it. Then you could even ask a query like “give me the classes of a student. For each class give me all the students in those classes. For each of those students, give me their classes”. Without the backend having to add anything. All the backend has to do is define the relationship and permissions about how to access the data.

Most GraphQL libs provide helpers for avoiding n+1 queries also, so things get optimized in the above case by only making 4 queries to the DB. Obviously thats a contrived example and most nested things wont go so crazy. But it goes to show how a powerful the API can become from defining such a simple relationship.

As a backend dev you just have to work on transforming data, defining the relationships and checking permissions. You let the frontend determine what data they want to access.

Before working with REST almost every page seemed to need a specialized endpoint to be implemented for the frontend to work, but with GraphQL, the frontend can work much more independently without having to ask the backend to provide a specialized view for more data.

[vanshg]

Isn't this exactly what SQL is supposed to be for? Why not just submit SQL queries and get the response directly from the DB?

That is to say, what differentiates GraphQL from SQL?

[hansonkd13]

GraphQL is a layer in front of SQL.

I can write a Graphql endpoint in python (Using Django-Graphene). I can write python functions that return data to the graphql. I can write ORM queries that write data to grapqhl. I can specify access, permissions and certain queries based on the user.

Graphql is more of a relational FFI than a SQL replacement.

Also the frontend never sends SQL to get data because it is unsafe. This is what a GraphQL framework allows you to do, clean up and filter queries so they are safe and then translate them into efficient lookups in a RDBMS.

[taylodl]

SQL is a leaky abstraction, which makes your system more brittle. The front-end now has intimate knowledge about the physical data management. You don't want that. If later you decide you want to change your physical data layout to improve data storage and retrieval performance then your queries have to be modified. The front-end and data tier can't vary independently from one another. That's what makes your system brittle.

That's not even getting into the tremendous attack surface you've just opened leaving your application vulnerable to SQL injection attacks. SQL injection is a real problem and scrubbing all the inputs is a pain and you can never be sure you got everything. One mistake and congratulations! - you've made headline news!

These are the problems GraphQL solves.