I feel that by using these types of tools you could really miss out on a fantastic opportunity to create a schema that models the business domain as accurately and elegantly as you want to make it, regardless of the underlying service topology or the databases behind it.
That's what I find the most attractive about GraphQL. Large companies and companies that have grown fast often have all kinds of APIs made at different time by different people with different standards. GraphQL lets you paper over that without breaking existing, revenue making code.
I completely agree. I've posted about this before in discussions about Hasura, but I feel that all these "expose your DB as a GraphQL endpoint" are setting themselves up for a world of hurt down the road.
GraphQL is a fantastic tool to enable an API that maps extremely closely to the front end (check the spec, that is exactly what it was intended to do); instead building it so it exactly matches your DB schema is a huge mistake IMO.
Two points, if your DB schema doesn't model your domain correctly you're doing it wrong to start with. And two, views are typically used to decouple the raw database tables from whatever you want to expose to others, be those other developers or in this case external API users.
Modelling databases this way has fallen out of favour for various reasons, but it becomes extremely useful and relevant again with systems like Hasura.
If you really do that, people tend to accuse you of doing RPC and not building a "true" API, because you're creating a lot of special case functions for the remote caller's business case.
That is exactly what GraphQL is designed to do. Taken straight from the spec:
> Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.
The whole point of GraphQL is that since each client asks for exactly the fields they want, having those "special case functions" is not a problem because other clients don't need to ask for those fields.
> Delegate authorization logic to the business logic layer
If you take security or performance debugging seriously, you should never expose database models through APIs directly in a production app.
To illustrate, say you have an Employee model:
query {
employee(userId=uuid) {
name
salary
}
}
Say you add some hacks on top of this to only allow users to query their own employee data, believing this provides adequate security.
The next day, someone creates a Manager object, a relation from employee to Manager, and Manager to employee.
Now, without having consider security for a second, you've granted all employees the ability to query each other:
query {
employee(userId=uuid) {
name
salary
manager {
employees {
name
salary
}
}
}
}
To say that these problems occur in the wild frequently is an understatement. Since these graphql frameworks also expose introspection capabilities, discovering these exploits can be automated using crawlers. If you write a bug like this, and you will, people will find it.
Please, please stop encouraging people to directly expose their databases through an API.
I agree that this is indeed a problem, but your proposed cure is unnecessarily onerous. At least with Hasura's equivalent product, allowing queries on related objects is an opt-in process for the admin, after each related object is defined.
I think a better piece of advice is: Please stop allowing people to query relational models automatically, and surface a separate locked-down schema for the GraphQL user.
These GraphQL over DB tools have real value. I've moved from using OpenResty to Hasura in order to surface Postgres APIs, and the time saved has been significant.
Let's be clear: many folks today are directly exposing their databases through REST. The API protocol really doesn't matter. CRUD has no affinity for any one technology or methodology.
GraphQL is no more vulnerable to crawlers than any REST server with OpenAPI on it. And yes, introspection can be disabled.
It's not like tools like Hasura, Prisma, or Postgraphile have no security baked into their products, often via a cryptographically signed JWT.
Having a JWT or whatever authn is irrelevant. The problem is an insufficient authz model.
Exposing databases through APIs is not the problem. Exposing relations without authorization is.
Under these frameworks, you can add an innocuous relationship between two models that entirely compromises security without even touching the API code. Not only that, but the graph of relations and their associated ACLs is complex. Every time you add a relation, you need to create a graph of your data model and ensure that it's safe. There are far, far more surface area to make a critical error, allowing attackers to exfiltrate large volumes of your data.
I've written these bugs in similar modeled systems (there were GQL like systems before GQL). I've fixed these bugs. I've caught these bugs in code review.
These bugs are orders of magnitude less likely to happen with a simpler authz model where you don't need to lock down every relation, just the table itself. This is why the GraphQL creators themselves encourage users to put authz at the business layer.
2 out of three examples above literally have no framework authz support. Postgraphile requires setting up row level security policies, meaning you have no control over what layer of code you want authz policies to live; they must be in the database. Even if you are ok with that sacrifice, you still have to find ways to manage this in version control and test, for which there is scarce tooling.
Hasura seems to do the right thing here, provided you opt into it. It's not clear if it allows you to easily version control or test your ACLs.
> And that's all assuming the GraphQL server has a public IP, which is far from a certainty (just like REST).
Security doesn't stop at your VPN. At several hundred engineers, organizations begin implementing internal controls.
In fact, my example was an employee comp manager :|.
Been playing around with GraphQL in the last day or so and just can't see any reason to use it over REST (or REST + an ORM). Am I missing something? Is it just so people don't have to learn SQL?
Client-side shaping of queried data without directly writing SQL against a back-end database, and without having to pre-arrange queried data structure with the back-end.
Wouldn't SPARQL be a better choice for this? It's an actual Web standard, unlike GraphQL so a better fit to general-purpose clients with no "pre-arranged queried structure".
I love SQL. I'll write CTEs and window functions until the cows come home with a smile on my face. But not everyone needs to know SQL. There are many other worthy pursuits.
REST suffers from the N+1 problem and overfetching. Most ORMs do as well. "Oh! You want order info AND product reviews? (At least) 2 more REST calls for you. Oh! You don't need the person's shipping and billing addresses in this case? So sorry, take them anyway, otherwise we would have to make another REST endpoint just for you."
Also affects versioning. In REST you commonly see URLS like "/v1/foo/54321" because if you try to remove or rename ANY PART of the JSON payload coming back, you break a contract. With GraphQL, you make the new name available and mark the old name with a directive like @deprecated. Over time you watch the logs to see if any clients are still using the old name. If so, keep it around and write another blog post asking folks not to use it anymore. If not, just remove it. You're done. No broken contracts. No differently versioned URLs.
GraphQL handles N different clients with a single schema. Mobile app clients, desktop clients, B2B clients, et al get exactly the data they need—no more and no less. REST either shoehorns them all into one or two access models or explodes into an unmaintainable mess of hundreds or thousands of often redundant endpoints.
The biggest difference, the one that GraphQL was really originally built to solve at Facebook, was to allow the CLIENT to determine what data they needed at any given time rather than REST which may be driven by client requests but ultimately is what servers THINK clients will need, and is much harder to change as needs change (and they will change).
I used it once upon a time to essentially allow joins across 3 separate databases that had all been developed/grown independently. Once you have certain kinds of resolvers between types, all sorts of neat stuff is possible. Ultimately, once we had time to update the applications, we merged the databases and dropped the GraphQL app entirely.
EDIT: It was awesome, and I kind of miss it, but it was too much to maintain within our constraints.
Looks like early day project. Had this exact project in mind when working with Postgraphile. JVM tooling around databases are amazing. Using clojure on top of that foundation with honey-sql was something I wish existed. Good luck! I might look into helping build it someday.
Readit News
That's what I find the most attractive about GraphQL. Large companies and companies that have grown fast often have all kinds of APIs made at different time by different people with different standards. GraphQL lets you paper over that without breaking existing, revenue making code.
GraphQL is a fantastic tool to enable an API that maps extremely closely to the front end (check the spec, that is exactly what it was intended to do); instead building it so it exactly matches your DB schema is a huge mistake IMO.
Modelling databases this way has fallen out of favour for various reasons, but it becomes extremely useful and relevant again with systems like Hasura.
> Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that.
The whole point of GraphQL is that since each client asks for exactly the fields they want, having those "special case functions" is not a problem because other clients don't need to ask for those fields.
https://graphql.org/learn/authorization/
> Delegate authorization logic to the business logic layer
If you take security or performance debugging seriously, you should never expose database models through APIs directly in a production app.
To illustrate, say you have an Employee model:
Say you add some hacks on top of this to only allow users to query their own employee data, believing this provides adequate security.The next day, someone creates a Manager object, a relation from employee to Manager, and Manager to employee.
Now, without having consider security for a second, you've granted all employees the ability to query each other:
To say that these problems occur in the wild frequently is an understatement. Since these graphql frameworks also expose introspection capabilities, discovering these exploits can be automated using crawlers. If you write a bug like this, and you will, people will find it.Please, please stop encouraging people to directly expose their databases through an API.
For example, with postgres: https://stackoverflow.com/questions/49261452/combining-row-l...
I think a better piece of advice is: Please stop allowing people to query relational models automatically, and surface a separate locked-down schema for the GraphQL user.
These GraphQL over DB tools have real value. I've moved from using OpenResty to Hasura in order to surface Postgres APIs, and the time saved has been significant.
GraphQL is no more vulnerable to crawlers than any REST server with OpenAPI on it. And yes, introspection can be disabled.
It's not like tools like Hasura, Prisma, or Postgraphile have no security baked into their products, often via a cryptographically signed JWT.
Query cost analysis. Query depth limits. Query pattern allow lists.
And that's all assuming the GraphQL server has a public IP, which is far from a certainty (just like REST).
Exposing databases through APIs is not the problem. Exposing relations without authorization is.
Under these frameworks, you can add an innocuous relationship between two models that entirely compromises security without even touching the API code. Not only that, but the graph of relations and their associated ACLs is complex. Every time you add a relation, you need to create a graph of your data model and ensure that it's safe. There are far, far more surface area to make a critical error, allowing attackers to exfiltrate large volumes of your data.
I've written these bugs in similar modeled systems (there were GQL like systems before GQL). I've fixed these bugs. I've caught these bugs in code review.
These bugs are orders of magnitude less likely to happen with a simpler authz model where you don't need to lock down every relation, just the table itself. This is why the GraphQL creators themselves encourage users to put authz at the business layer.
2 out of three examples above literally have no framework authz support. Postgraphile requires setting up row level security policies, meaning you have no control over what layer of code you want authz policies to live; they must be in the database. Even if you are ok with that sacrifice, you still have to find ways to manage this in version control and test, for which there is scarce tooling.
Hasura seems to do the right thing here, provided you opt into it. It's not clear if it allows you to easily version control or test your ACLs.
> And that's all assuming the GraphQL server has a public IP, which is far from a certainty (just like REST).
Security doesn't stop at your VPN. At several hundred engineers, organizations begin implementing internal controls.
In fact, my example was an employee comp manager :|.
REST suffers from the N+1 problem and overfetching. Most ORMs do as well. "Oh! You want order info AND product reviews? (At least) 2 more REST calls for you. Oh! You don't need the person's shipping and billing addresses in this case? So sorry, take them anyway, otherwise we would have to make another REST endpoint just for you."
Also affects versioning. In REST you commonly see URLS like "/v1/foo/54321" because if you try to remove or rename ANY PART of the JSON payload coming back, you break a contract. With GraphQL, you make the new name available and mark the old name with a directive like @deprecated. Over time you watch the logs to see if any clients are still using the old name. If so, keep it around and write another blog post asking folks not to use it anymore. If not, just remove it. You're done. No broken contracts. No differently versioned URLs.
GraphQL handles N different clients with a single schema. Mobile app clients, desktop clients, B2B clients, et al get exactly the data they need—no more and no less. REST either shoehorns them all into one or two access models or explodes into an unmaintainable mess of hundreds or thousands of often redundant endpoints.
The biggest difference, the one that GraphQL was really originally built to solve at Facebook, was to allow the CLIENT to determine what data they needed at any given time rather than REST which may be driven by client requests but ultimately is what servers THINK clients will need, and is much harder to change as needs change (and they will change).
EDIT: It was awesome, and I kind of miss it, but it was too much to maintain within our constraints.