5 ms·

GraphQL is so much heavier, code wise, than REST for Rails apps that it feels like a bad fit to me. Notice that these examples have created a completely paralle

GraphQL is so much heavier, code wise, than REST for Rails apps that it feels like a bad fit to me. Notice that these examples have created a completely parallel schema - new classes for every object in the GraphQL graph, which are analogous but separate from the Rails models, each one acting like a combination of controller and presenter for its Rails model, and breaking the ORM encapsulation to write efficient SQL queries. I think if GraphQL had existed in the early days of Rails, the natural assumption would have been that ActiveRecord model classes should double as GraphQL result objects, and there would be a nice DSL for specifying how to safely expose those objects to the API. But I haven't seen anyone try to build that - maybe the feeling is that Rails is _complete_ so new responsibilities need to live somewhere else

Daishiman 6y ago
The problem is GraphQL, fundamentally. GraphQL creates the illusion for the consumers that arbitrary queries are cheap, possible, and transparent. None of those things are true. Whether that reality is exposed to the client through more restricted REST endpoints or whether the backend has to support this fiction by handling all these performance considerations in GraphQL in the backend, the fact is that some queries are cheap, others are near impossible to achieve efficiently. So GraphQL doesn't really _reduce_ complexity; it merely pushes it into other places. Whether the right place is the client or the server depends on your organization and the acceptable engineering tradeoffs, but there's no free lunch when it comes to data locality.
- ljm 6y ago
  GraphQL, from what I see, is a solution designed by tech that is still best meant for big tech. Facebook had their reasons for coming up with it, because their user base is hitting the billions in scale. "But my mobile app makes too many requests!" says the hopeful engineer, "and graphql means we can optimise the network!" Well, yeah, it probably looks like that when you see one nice request from the browser dev-tools, rather than dozens, but that's not what it will look like on the server side, or in the database, when you can get into situations with quadratic queries, never mind N+1. And yes, I've seen that with my own eyes. If you're sending a dozen or so requests to the server to render a screen in a mobile app, then the slowest thing might just be the stage where you spin up a connection and do the old TLS dance. Unless you're hitting Big Tech scale that's probably acceptable versus the insane amount of money you'll dump into building and maintaining a GraphQL-based architecture without any data proving that this approach would actually be an optimisation. Just like Kafka, Kubernetes, etc. which have come out of incredibly large-scale projects and businesses...you don't have to and shouldn't use this stuff just because it's the popular thing to do. Startups and small businesses became successful without any of this.
  - Skgqie1 6y ago
    The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. Most places seem to just pick something because they heard it's used by Facebook or Google, and they think cargo culting those companies might make them successful too. Usually, any disagreement is seen as either contrarian or ignorant, and you end up building an over engineered monstrosity because that's what they want.
    - rodgerd 6y ago
      > The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. As someone who is nominally a decision maker (in that my job title has "architect" in it), I have the opposite experience, I guess: most of the pushes for GraphQL have come from devs desperate to have a magic bullet, rather than to rework an overly-granular API. (Of course there are also the folks who want a tick on their CV but that's a whole other problem)
  - ForHackernews 6y ago
    I sort of disagree. The big win from GraphQL (vs REST) is flexibility: You don't have to define all your endpoints up front. The client(s) can make the sorts of queries they want. If you're building a single page app frontend where most of the business logic is on the client side, it makes sense to empower the client to define the types of queries it wants to make. If anything, running a GraphQL architecture seems like less maintenance burden to me, because it makes the server side API less rigid, so the coupling between client and server becomes looser.
    - ljm 6y ago
      And how often do you need that sort of decoupling at all? Beside that, I disagree in principle because, like the OP said, it's just hiding the maintenance burden elsewhere. It doesn't go away.
- drchopchop 6y ago
  Additionally, most real-world applications fall into very predictable patterns which can be encapsulated by REST API's with hand-tweaked SQL access patterns for speed. You don't generally need arbitrary query patterns from the client, and Rails/ActiveRecord already has tons of problems minimizing SQL calls. If you've built a decent backend API framework, making a new route should be quick, it's just access/auth boilerplate plus whatever retrieval is the most efficient.
- rwoerz 6y ago
  I think there are some similarities between a "GraphQL vs REST" tradeoff and a "SQL vs NoSQL" one. As a rule of thumb I would use a GraphQL API if I (as a server developer) don't know my clients and their API access patterns and do not want them to assemble what they want on their own in n+1 requests, particularly if they are somewhere in the internet and would suffer from network latency in each request. Likewise, I (as a database developer) would prefer a SQL database if its clients (e.g. independently developed inhouse applications) and their access patterns are unknown. Conversely, as, e.g., a backend microservice developer, you mostly know the access patterns between a database and its clients, mostly because there there is just one database client per database and both constitute the microservice. So you are safe to choose a NoSQL database here with, say, a document-oriented datamodel that is optimized for that single database client. With regard to the API of that microservice, you also know your clients (i.e. other microservices), so you can also optimize a RESTful (or even GRPC) API for them in order to avoid the over-/underfetching/n+1 problem. Even if you cannot optimize your internal RESTful API to satisfy each of your clients' requests in a single response, network latency is not such a big problem here because clients of a back-end microservice are often somewhat close to it.
SkyPuncher 6y ago
I'm not really seeing the GraphQL code he presented as fundamentally different than serializers. I've used a similar pattern at several companies and one of the biggest pains is making sure you're lookups stay in-sync with the serializers to avoid N+1. This is simply recognizing the fact that many serialization patterns do not work in a black box. They inherently rely a coordination with SQL queries to load necessary data.
Envek 6y ago
> have created a completely parallel schema - new classes for every object in the GraphQL graph, which are analogous but separate from the Rails models, each one acting like a combination of controller and presenter And IMO this is good. Now you have dedicated place (namely `app/graphql` folder) for API-specific data mapping and validations. And in general GraphQL-Ruby gently pushes you to decouple your API from your database schema so you will be able to refactor and optimize things under your application hood later.
Envek 6y ago
> the natural assumption would have been that ActiveRecord model classes should double as GraphQL result objects, and there would be a nice DSL for specifying how to safely expose those objects to the API. GraphQL-Ruby Types _is_ that DSL. You specify what fields can be exposed to the world and this is also the place where you can hide too low-level specifics (e.g. join separate `amount` and `price` columns into specific `Money` type). Then you pass AR object to GraphQL-ruby and it does what you said in DSL.
jamil7 6y ago
Schema duplication also exists in most of the popular python implementations I’ve seen although I don’t do much backend right now I might be mistaken.
phaedryx 6y ago
At my last job, we just dynamically generated the GraphQL schema from our Rails models and our permission system. Once we had that in place we just developed as usual.
- joelbluminator 6y ago
  Any gem for that?
  - phaedryx 6y ago
    Unfortunately, I've switched jobs and they own the code I wrote. I could probably write something from scratch, using the same principles and be okay :thinking_face:
deleted 6y ago
[deleted]

Daishiman 6y ago

The problem is GraphQL, fundamentally. GraphQL creates the illusion for the consumers that arbitrary queries are cheap, possible, and transparent. None of those things are true. Whether that reality is exposed to the client through more restricted REST endpoints or whether the backend has to support this fiction by handling all these performance considerations in GraphQL in the backend, the fact is that some queries are cheap, others are near impossible to achieve efficiently. So GraphQL doesn't really _reduce_ complexity; it merely pushes it into other places. Whether the right place is the client or the server depends on your organization and the acceptable engineering tradeoffs, but there's no free lunch when it comes to data locality.

ljm 6y ago
GraphQL, from what I see, is a solution designed by tech that is still best meant for big tech. Facebook had their reasons for coming up with it, because their user base is hitting the billions in scale. "But my mobile app makes too many requests!" says the hopeful engineer, "and graphql means we can optimise the network!" Well, yeah, it probably looks like that when you see one nice request from the browser dev-tools, rather than dozens, but that's not what it will look like on the server side, or in the database, when you can get into situations with quadratic queries, never mind N+1. And yes, I've seen that with my own eyes. If you're sending a dozen or so requests to the server to render a screen in a mobile app, then the slowest thing might just be the stage where you spin up a connection and do the old TLS dance. Unless you're hitting Big Tech scale that's probably acceptable versus the insane amount of money you'll dump into building and maintaining a GraphQL-based architecture without any data proving that this approach would actually be an optimisation. Just like Kafka, Kubernetes, etc. which have come out of incredibly large-scale projects and businesses...you don't have to and shouldn't use this stuff just because it's the popular thing to do. Startups and small businesses became successful without any of this.
- Skgqie1 6y ago
  The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. Most places seem to just pick something because they heard it's used by Facebook or Google, and they think cargo culting those companies might make them successful too. Usually, any disagreement is seen as either contrarian or ignorant, and you end up building an over engineered monstrosity because that's what they want.
  - rodgerd 6y ago
    > The problem I've always encountered with this (which I 100% agree with), is that I've never met anyone in a decision making position who's cared or been open to discussing it. As someone who is nominally a decision maker (in that my job title has "architect" in it), I have the opposite experience, I guess: most of the pushes for GraphQL have come from devs desperate to have a magic bullet, rather than to rework an overly-granular API. (Of course there are also the folks who want a tick on their CV but that's a whole other problem)
- ForHackernews 6y ago
  I sort of disagree. The big win from GraphQL (vs REST) is flexibility: You don't have to define all your endpoints up front. The client(s) can make the sorts of queries they want. If you're building a single page app frontend where most of the business logic is on the client side, it makes sense to empower the client to define the types of queries it wants to make. If anything, running a GraphQL architecture seems like less maintenance burden to me, because it makes the server side API less rigid, so the coupling between client and server becomes looser.
  - ljm 6y ago
    And how often do you need that sort of decoupling at all? Beside that, I disagree in principle because, like the OP said, it's just hiding the maintenance burden elsewhere. It doesn't go away.
drchopchop 6y ago
Additionally, most real-world applications fall into very predictable patterns which can be encapsulated by REST API's with hand-tweaked SQL access patterns for speed. You don't generally need arbitrary query patterns from the client, and Rails/ActiveRecord already has tons of problems minimizing SQL calls. If you've built a decent backend API framework, making a new route should be quick, it's just access/auth boilerplate plus whatever retrieval is the most efficient.
rwoerz 6y ago
I think there are some similarities between a "GraphQL vs REST" tradeoff and a "SQL vs NoSQL" one. As a rule of thumb I would use a GraphQL API if I (as a server developer) don't know my clients and their API access patterns and do not want them to assemble what they want on their own in n+1 requests, particularly if they are somewhere in the internet and would suffer from network latency in each request. Likewise, I (as a database developer) would prefer a SQL database if its clients (e.g. independently developed inhouse applications) and their access patterns are unknown. Conversely, as, e.g., a backend microservice developer, you mostly know the access patterns between a database and its clients, mostly because there there is just one database client per database and both constitute the microservice. So you are safe to choose a NoSQL database here with, say, a document-oriented datamodel that is optimized for that single database client. With regard to the API of that microservice, you also know your clients (i.e. other microservices), so you can also optimize a RESTful (or even GRPC) API for them in order to avoid the over-/underfetching/n+1 problem. Even if you cannot optimize your internal RESTful API to satisfy each of your clients' requests in a single response, network latency is not such a big problem here because clients of a back-end microservice are often somewhat close to it.

SkyPuncher 6y ago

I'm not really seeing the GraphQL code he presented as fundamentally different than serializers. I've used a similar pattern at several companies and one of the biggest pains is making sure you're lookups stay in-sync with the serializers to avoid N+1. This is simply recognizing the fact that many serialization patterns do not work in a black box. They inherently rely a coordination with SQL queries to load necessary data.

Envek 6y ago

> have created a completely parallel schema - new classes for every object in the GraphQL graph, which are analogous but separate from the Rails models, each one acting like a combination of controller and presenter And IMO this is good. Now you have dedicated place (namely `app/graphql` folder) for API-specific data mapping and validations. And in general GraphQL-Ruby gently pushes you to decouple your API from your database schema so you will be able to refactor and optimize things under your application hood later.

Envek 6y ago

> the natural assumption would have been that ActiveRecord model classes should double as GraphQL result objects, and there would be a nice DSL for specifying how to safely expose those objects to the API. GraphQL-Ruby Types _is_ that DSL. You specify what fields can be exposed to the world and this is also the place where you can hide too low-level specifics (e.g. join separate `amount` and `price` columns into specific `Money` type). Then you pass AR object to GraphQL-ruby and it does what you said in DSL.

jamil7 6y ago

Schema duplication also exists in most of the popular python implementations I’ve seen although I don’t do much backend right now I might be mistaken.

phaedryx 6y ago

At my last job, we just dynamically generated the GraphQL schema from our Rails models and our permission system. Once we had that in place we just developed as usual.

joelbluminator 6y ago
Any gem for that?
- phaedryx 6y ago
  Unfortunately, I've switched jobs and they own the code I wrote. I could probably write something from scratch, using the same principles and be okay :thinking_face:

deleted 6y ago

[deleted]