Hacker News Reader

Comment by jes5199 | Hacker News Reader

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

View on HN

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.

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.

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.

> 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)

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.

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.

The problem is the server has a connection to the database that’s infinitely more reliable than the client -> server.

I’ve dealt with garbage REST APIs with tons of sequential calls and in low reliability scenarios 1 call is a massive improvement over a scenario where 4-5 sequential calls need to be made and if/when one of them fails you need to start over.

Now the client has to handle result caching and all the different error states because some server dev couldn't be bothered to batch a few calls and return all the required models.

At my company, we benefit from loose coupling between components every time we'd like to release an update to one without a concomitant deploy to some other service.

If you control the back and front end, I don't buy into this argument. You don't have to define all your REST endpoints up front, you can add them as needed.

If you're serving a public API and you really don't know up front what endpoints people will need, or like facebook you have tons of people with different needs, then maybe GraphQL makes sense.

When you have separate backend and frontend teams, Conway's Law starts to rear its ugly head. GraphQL can help smooth over some of that organizational friction and maybe keep the frontend team from making N+1 requests because they gotta get this feature out by the end of the sprint and backend's busy with its stuff. They tell themselves, "It'll be fine. It's performs acceptably on my machine with my company internet connection."

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.

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.

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.

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.

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.

Any gem for that?

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:

> 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.

> 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.

Reply on news.ycombinator.com