3 ms·

Adding any layer for clients to fetch data introduces another layer of complexity and if you have graphql purely to surface something that could be queried dire

by dpix 6y ago

Adding any layer for clients to fetch data introduces another layer of complexity and if you have graphql purely to surface something that could be queried directly then it is definitely overhead. Where I see graphql shine is: 1. reducing large payloads to only the data you need 2. combining responses from many different sources into one query - especially when these might all talk different protocols, one sql, one nosql, one http etc Is graphql the only solution to this? No Is graphql designed pretty well to make this simple? Yes

curryst 6y ago
> Adding any layer for clients to fetch data introduces another layer of complexity and if you have graphql purely to surface something that could be queried directly then it is definitely overhead. It's not just overhead, there are a lot of benefits to it as well. I've worked a few places that just have all their applications talk to the same database and have had enormous issues. Firstly, there is the issue of failing over to secondary databases. You can build it into GraphQL to just have it fail over to secondaries. With raw SQL, each application has to handle that sanely, and the chances that they all do is slim. You could put something like pgbouncer in front of it, but at that point you're still adding that layer of complexity. You'll also have those people that crush the database with poorly optimized queries. GraphQL lets me choose what queries I allow, so no one can lock the database for an hour doing something insane. SQL doesn't give you a lot of tools for that; especially not when some people are supposed to be allowed to lock the database for an hour and others are not. GraphQL also knows whether the query is a read or write operation; they're separate in GraphQL. You can sanely route read queries to replicas and pass write queries to the master. This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think). I'm not saying GraphQL is the only answer to this, but I have yet to see any implementation of "all the clients just connect to our DB" that worked well.
- takeda 6y ago
  > Firstly, there is the issue of failing over to secondary databases. You can build it into GraphQL to just have it fail over to secondaries. With raw SQL, each application has to handle that sanely, and the chances that they all do is slim. You could put something like pgbouncer in front of it, but at that point you're still adding that layer of complexity. Not really, you place pgbouncer in front and problem solved, it's also very likely more performant than your glue app would be. > You'll also have those people that crush the database with poorly optimized queries. GraphQL lets me choose what queries I allow, so no one can lock the database for an hour doing something insane. SQL doesn't give you a lot of tools for that; especially not when some people are supposed to be allowed to lock the database for an hour and others are not. we are talking about read queries there (in the tweet he mentioned he is not yet convinced about making changes this way), you can have dedicated instance just for handling that traffic, you also can set up timeout for the query. You also have the same chance of getting bad queries when you use ORM. > GraphQL also knows whether the query is a read or write operation; they're separate in GraphQL. You can sanely route read queries to replicas and pass write queries to the master. This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think). this is not an issue pgpool-II does that as well, although author was talking about select queries.
- dragonwriter 6y ago
  > You'll also have those people that crush the database with poorly optimized queries. GraphQL lets me choose what queries I allow, so no one can lock the database for an hour doing something insane. SQL doesn't give you a lot of tools for that; especially not when some people are supposed to be allowed to lock the database for an hour and others are not. You don't need a lot of tools for that, but SQL gives you complete tools for it. (Including, if necessary, strictly limiting allowed queries by only authorizing certain particular roles to access a defined set of sprocs without any access to base tables or even views, which seems to be the direct equivalent of what you are suggesting with GraphQL. This is an extremely common enterprise approach.) Because RBAC is standard with SQL RDBMSs (other than embedded/single-user stores like SQLite), it's trivial to handle “some roles are restricted to pre-cleared access patterns and others have either different pre-cleared patterns or free-query access.” > GraphQL also knows whether the query is a read or write operation; So does SQL. > You can sanely route read queries to replicas and pass write queries to the master. Replicated SQL setups do this routinely. > This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think). Well, by definition to route requests to different backends you need a server separate from the backends (or, at a minimum, all but one of them, but you want it separately from all of them in practice anyway.)

by dpix 6y ago

curryst 6y ago

> Adding any layer for clients to fetch data introduces another layer of complexity and if you have graphql purely to surface something that could be queried directly then it is definitely overhead. It's not just overhead, there are a lot of benefits to it as well. I've worked a few places that just have all their applications talk to the same database and have had enormous issues. Firstly, there is the issue of failing over to secondary databases. You can build it into GraphQL to just have it fail over to secondaries. With raw SQL, each application has to handle that sanely, and the chances that they all do is slim. You could put something like pgbouncer in front of it, but at that point you're still adding that layer of complexity. You'll also have those people that crush the database with poorly optimized queries. GraphQL lets me choose what queries I allow, so no one can lock the database for an hour doing something insane. SQL doesn't give you a lot of tools for that; especially not when some people are supposed to be allowed to lock the database for an hour and others are not. GraphQL also knows whether the query is a read or write operation; they're separate in GraphQL. You can sanely route read queries to replicas and pass write queries to the master. This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think). I'm not saying GraphQL is the only answer to this, but I have yet to see any implementation of "all the clients just connect to our DB" that worked well.

takeda 6y ago
> Firstly, there is the issue of failing over to secondary databases. You can build it into GraphQL to just have it fail over to secondaries. With raw SQL, each application has to handle that sanely, and the chances that they all do is slim. You could put something like pgbouncer in front of it, but at that point you're still adding that layer of complexity. Not really, you place pgbouncer in front and problem solved, it's also very likely more performant than your glue app would be. > You'll also have those people that crush the database with poorly optimized queries. GraphQL lets me choose what queries I allow, so no one can lock the database for an hour doing something insane. SQL doesn't give you a lot of tools for that; especially not when some people are supposed to be allowed to lock the database for an hour and others are not. we are talking about read queries there (in the tweet he mentioned he is not yet convinced about making changes this way), you can have dedicated instance just for handling that traffic, you also can set up timeout for the query. You also have the same chance of getting bad queries when you use ORM. > GraphQL also knows whether the query is a read or write operation; they're separate in GraphQL. You can sanely route read queries to replicas and pass write queries to the master. This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think). this is not an issue pgpool-II does that as well, although author was talking about select queries.
dragonwriter 6y ago
> You'll also have those people that crush the database with poorly optimized queries. GraphQL lets me choose what queries I allow, so no one can lock the database for an hour doing something insane. SQL doesn't give you a lot of tools for that; especially not when some people are supposed to be allowed to lock the database for an hour and others are not. You don't need a lot of tools for that, but SQL gives you complete tools for it. (Including, if necessary, strictly limiting allowed queries by only authorizing certain particular roles to access a defined set of sprocs without any access to base tables or even views, which seems to be the direct equivalent of what you are suggesting with GraphQL. This is an extremely common enterprise approach.) Because RBAC is standard with SQL RDBMSs (other than embedded/single-user stores like SQLite), it's trivial to handle “some roles are restricted to pre-cleared access patterns and others have either different pre-cleared patterns or free-query access.” > GraphQL also knows whether the query is a read or write operation; So does SQL. > You can sanely route read queries to replicas and pass write queries to the master. Replicated SQL setups do this routinely. > This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think). Well, by definition to route requests to different backends you need a server separate from the backends (or, at a minimum, all but one of them, but you want it separately from all of them in practice anyway.)