7 ms·

> GraphQL is a great experience when you consume it and the service fulfills your query needs. Unless you already know SQL, and you realise how small and simpl

by jseban 4y ago

> GraphQL is a great experience when you consume it and the service fulfills your query needs. Unless you already know SQL, and you realise how small and simple the queries could be, then it's really not a great experience to be forced to use graphql.

papito 4y ago
Hell yes. Good knowledge of SQL is a superpower and is becoming a rare art form. The new generation of devs thinks that frameworks and ORMs will do the magic for them at no cost, but they don't. There is no substitute for leveraging your storage engine to the max. The sad part is that databases have evolved and became much better in the last 20 years (I started with MySQL 3.x), but we just don't use them. Everyone acts like "microservices" solved all of our technical challenges. Right.
- jimbokun 4y ago
  In my opinion, the value of a well architected micro service is to figure out how to optimize and leverage the capabilities of the underlying storage engine, while presenting a simple performant and correct API to consumers, while not requiring those consumers to understand the underlying details of the datastore.
  - papito 4y ago
    I am not talking about the customers. Of course they are not supposed to understand it. I am talking about the system design. And microservices do not solve problems in most companies, just create new ones. Distributed systems did not magically become simpler to reason about just because there is Docker.
- KptMarchewa 4y ago
  It's "previous" generation of devs that build Hibernates and Entity Frameworks and other ORMs. I work with "data" systems, where everything has been migrating in the other direction - to SQL - from custom code for last 5 years or more.
- bcrosby95 4y ago
  > The sad part is that databases have evolved and became much better in the last 20 years (I started with MySQL 3.x), but we just don't use them. Yes, it's a bit like buying a set of silverware and insisting on using the handle as the business end incase you decide to switch your tool.
pier25 4y ago
Exactly. I've been in web dev for 20 years but mostly in the front end space. A couple of years ago I started doing full stack and trying different databases. For the past year or so I've been using Postgres and learning SQL. This is by far the best solution I've used so far. SQL is extremely expressive, powerful, and elegant. The problem is that SQL has a strong learning curve which many devs want to avoid. I'm convinced this is the main reason stuff like Mongo or Prisma are so popular. I actually tried Prisma before raw SQL and I vastly prefer SQL for writing queries. I deeply regret not having spent some time learning SQL years ago.
- eurasiantiger 4y ago
  How many different entity types and relationships between entities does your typical application have?
- reidjs 4y ago
  I started a toy project with the intention of using raw SQL, but I ended up starting to build my own ORM around all the models. If I have a User and who is trying to create a new Post, with Prisma you eventually set it up to do something like User.createPost(content). What does createPost method look like with raw SQL? Does it read in from a .sql file that you pass values to?
  - jeffdn 4y ago
    That, or just a string in your application’s code. The problem with using the ORM as you describe is that when you hit any sort of scale, you need to be doing bulk operations, otherwise your latency goes through the roof, to the point that the number of inefficient queries you are doing can tank the database. I speak from the experience of having seen a database collapse under the load of a backend written in this fashion having request load grow past a certain point — not pretty! The interim solution is to bulkify existing queries and functions in place to the greatest extent possible, while preparing for: Converting a codebase from having endpoints doing individual ORM operations as described to having proper separation of concerns with a business logic layer between the endpoints and the database is a _massive_ cost. The earlier you implement that, the happier you will be in the longer term. It doesn’t have to be with raw SQL, but many bulk operations are much easier to express with SQL than with the ORM.
tshaddox 4y ago
But wait, doesn’t that directly contradict the first commenter’s next paragraph? > On the other hand, when you are the one to implement the Graphql server, it feels like writing your own database. You have to create a query plan, handle optimizations, corner cases, etc. If it’s so easy to craft any GraphQL query as an SQL query and let the RDBMS plan an execute the query, then shouldn’t it be easy to implement the GraphQL server on the backend?
- tehbeard 4y ago
  You're conflating a hand coded and optimized query vs. Building a system to take a tree and generate said optimized query automatically and quickly and correctly.
  - tshaddox 4y ago
    I don't think I'm conflating it. jseban's comment indicates that anyone who knows how to write simple SQL queries would get no benefit from using GraphQL to consume data, which must mean that there is a simple SQL query that can be written to fulfill any GraphQL query.
    - marcosdumay 4y ago
      > there is a simple SQL query that can be written to fulfill any GraphQL query This is true (as long as you expect both queries to be simple, or allow both to be complex). But the conclusion you get up there is wrong and (obviously) does not follow from that. Creating a software that translate any one query into the other is a very difficult task.
    - charcircuit 4y ago
      Not all of the data sources for graphql may be in a single database. They may not necessarily even be stored in something that can be accessed with SQL.
- necovek 4y ago
  I think your point is a fair one. The distinction is that it's easy to write a contextual SQL query for any one GraphQL query when your database model closely matches your API objects. "Contextual" means that sometimes this requires a "side effect" to happen (eg. creating an index on a column in the SQL DB). Making it generic and performant at the same time is where the complexity is. It would be akin to saying how, since knowing that you might need an index in the SQL database is simple, a RDBMS could decide to create those indexes for you.
ushakov 4y ago
- jdlshore 4y ago
  Let's not stereotype a whole category of people.
tracyhenry 4y ago
GraphQL is just an API language. It doesn't free you from writing database queries. The point of GraphQL is mostly separation of backend/frontend and avoiding over-fetching/under-fetching. If those don't sound like a benefit, you should use REST.
- freedomben 4y ago
  I would agree, but would add one note at the end: "Yes you can do this with REST by including query params to reduce/tune what gets returned, but that can quickly balloon into a monster when you get beyond pagination, ?expanded=1 for full objects (vs partials/abbreviated), etc."
  - necovek 4y ago
    The same is true of GraphQL, if you want to control how much of nested objects you get (eg. introduce limits on the number of nested objects). Basically, with GraphQL you hide all the complexity behind generic-seeming API requiring one API call, whereas with REST you'd usually hit multiple endpoints for different data types. GraphQL has the benefit of allowing the backend to smartly decide how to restrict the data (eg. do the joins between what would have been two bigger REST queries), but that incurs a development cost. The complexity is in marrying all the familiar optimization tricks for SQL databases with exposing that in a generic but still restricted way.

by jseban 4y ago

papito 4y ago

Hell yes. Good knowledge of SQL is a superpower and is becoming a rare art form. The new generation of devs thinks that frameworks and ORMs will do the magic for them at no cost, but they don't. There is no substitute for leveraging your storage engine to the max. The sad part is that databases have evolved and became much better in the last 20 years (I started with MySQL 3.x), but we just don't use them. Everyone acts like "microservices" solved all of our technical challenges. Right.

jimbokun 4y ago
In my opinion, the value of a well architected micro service is to figure out how to optimize and leverage the capabilities of the underlying storage engine, while presenting a simple performant and correct API to consumers, while not requiring those consumers to understand the underlying details of the datastore.
- papito 4y ago
  I am not talking about the customers. Of course they are not supposed to understand it. I am talking about the system design. And microservices do not solve problems in most companies, just create new ones. Distributed systems did not magically become simpler to reason about just because there is Docker.
KptMarchewa 4y ago
It's "previous" generation of devs that build Hibernates and Entity Frameworks and other ORMs. I work with "data" systems, where everything has been migrating in the other direction - to SQL - from custom code for last 5 years or more.
bcrosby95 4y ago
> The sad part is that databases have evolved and became much better in the last 20 years (I started with MySQL 3.x), but we just don't use them. Yes, it's a bit like buying a set of silverware and insisting on using the handle as the business end incase you decide to switch your tool.

pier25 4y ago

Exactly. I've been in web dev for 20 years but mostly in the front end space. A couple of years ago I started doing full stack and trying different databases. For the past year or so I've been using Postgres and learning SQL. This is by far the best solution I've used so far. SQL is extremely expressive, powerful, and elegant. The problem is that SQL has a strong learning curve which many devs want to avoid. I'm convinced this is the main reason stuff like Mongo or Prisma are so popular. I actually tried Prisma before raw SQL and I vastly prefer SQL for writing queries. I deeply regret not having spent some time learning SQL years ago.

eurasiantiger 4y ago
How many different entity types and relationships between entities does your typical application have?
reidjs 4y ago
I started a toy project with the intention of using raw SQL, but I ended up starting to build my own ORM around all the models. If I have a User and who is trying to create a new Post, with Prisma you eventually set it up to do something like User.createPost(content). What does createPost method look like with raw SQL? Does it read in from a .sql file that you pass values to?
- jeffdn 4y ago
  That, or just a string in your application’s code. The problem with using the ORM as you describe is that when you hit any sort of scale, you need to be doing bulk operations, otherwise your latency goes through the roof, to the point that the number of inefficient queries you are doing can tank the database. I speak from the experience of having seen a database collapse under the load of a backend written in this fashion having request load grow past a certain point — not pretty! The interim solution is to bulkify existing queries and functions in place to the greatest extent possible, while preparing for: Converting a codebase from having endpoints doing individual ORM operations as described to having proper separation of concerns with a business logic layer between the endpoints and the database is a _massive_ cost. The earlier you implement that, the happier you will be in the longer term. It doesn’t have to be with raw SQL, but many bulk operations are much easier to express with SQL than with the ORM.

tshaddox 4y ago

But wait, doesn’t that directly contradict the first commenter’s next paragraph? > On the other hand, when you are the one to implement the Graphql server, it feels like writing your own database. You have to create a query plan, handle optimizations, corner cases, etc. If it’s so easy to craft any GraphQL query as an SQL query and let the RDBMS plan an execute the query, then shouldn’t it be easy to implement the GraphQL server on the backend?

tehbeard 4y ago
You're conflating a hand coded and optimized query vs. Building a system to take a tree and generate said optimized query automatically and quickly and correctly.
- tshaddox 4y ago
  I don't think I'm conflating it. jseban's comment indicates that anyone who knows how to write simple SQL queries would get no benefit from using GraphQL to consume data, which must mean that there is a simple SQL query that can be written to fulfill any GraphQL query.
  - marcosdumay 4y ago
    > there is a simple SQL query that can be written to fulfill any GraphQL query This is true (as long as you expect both queries to be simple, or allow both to be complex). But the conclusion you get up there is wrong and (obviously) does not follow from that. Creating a software that translate any one query into the other is a very difficult task.
  - charcircuit 4y ago
    Not all of the data sources for graphql may be in a single database. They may not necessarily even be stored in something that can be accessed with SQL.
necovek 4y ago
I think your point is a fair one. The distinction is that it's easy to write a contextual SQL query for any one GraphQL query when your database model closely matches your API objects. "Contextual" means that sometimes this requires a "side effect" to happen (eg. creating an index on a column in the SQL DB). Making it generic and performant at the same time is where the complexity is. It would be akin to saying how, since knowing that you might need an index in the SQL database is simple, a RDBMS could decide to create those indexes for you.

ushakov 4y ago

jdlshore 4y ago
Let's not stereotype a whole category of people.

tracyhenry 4y ago

GraphQL is just an API language. It doesn't free you from writing database queries. The point of GraphQL is mostly separation of backend/frontend and avoiding over-fetching/under-fetching. If those don't sound like a benefit, you should use REST.

freedomben 4y ago
I would agree, but would add one note at the end: "Yes you can do this with REST by including query params to reduce/tune what gets returned, but that can quickly balloon into a monster when you get beyond pagination, ?expanded=1 for full objects (vs partials/abbreviated), etc."
- necovek 4y ago
  The same is true of GraphQL, if you want to control how much of nested objects you get (eg. introduce limits on the number of nested objects). Basically, with GraphQL you hide all the complexity behind generic-seeming API requiring one API call, whereas with REST you'd usually hit multiple endpoints for different data types. GraphQL has the benefit of allowing the backend to smartly decide how to restrict the data (eg. do the joins between what would have been two bigger REST queries), but that incurs a development cost. The complexity is in marrying all the familiar optimization tricks for SQL databases with exposing that in a generic but still restricted way.