Hacker News Reader

Comment by silisili | Hacker News Reader

I've always found REST more logical. In a way, it's like the Unix philosophy...do one thing(at a time) and do it well. Implementing Graphql on the backend turns into a clusterf of spaghetti code real quick. And there are a lot of footguns.

I've noticed a lot of frontend folks especially like GraphQL, as they just want the data in as few calls as possible, which I can't fault them for.

I've read about an apollo bridge that basically does GQL over REST. I'm pretty curious how well that works, because it sounds like the best of both worlds. Clients who want GQL have it, clients that want REST have it, and backend logic itself is massively less complex.

View on HN

Interestingly, the principle of single responsibility is specifically why I like GraphQL over REST. As your frontend complexity grows, your REST payloads tend to become carefully-balanced collections of complex shapes, and it becomes very difficult to maintain and refactor over time. In GQL, by comparison, each field or mutation has its own isolated implementation, authorization is handled at a granular level, and frontend queries can evolve as needed without imposing any significant need for changes on the backend.

REST is great for small, compact APIs which serve a couple of views, but as the product grows in scope and complexity, GraphQL ends up feeling significantly easier to keep straight.

The other thing is that it's very easy to build "complex" REST APIs on top of GraphQL - execute an internal query, reshape the result into a JSON payload to conform to the REST contract - but implementing GraphQL on top of a bunch of REST calls is a lot hairier. GraphQL feels more like a set of primitives, while REST is a coalesced interface.

> I've always found REST more logical.

They shouldn't be at odds with each other. GraphQL was explicitly designed to sit in front of your REST services - occupying the so-called backend for frontends (BFF) layer – allowing your service graph to be navigated by query in order to allow frontend folks to roll up all their calls in a single request to reduce the high round trip costs that can be found outside of the datacenter.

The Unix philosophy remains. You are still calling individual REST services, assuming you hold true to GraphQL's intent. The only difference is that the client is able to leverage GraphQL to push that work to inside of the datacenter, where latency is much more tolerable. If REST services are your individual Unix tools, the GraphQL resolver is the shell that ties them all together.

Granted, if your clients are known to be on solid connections you likely don't need to even bother with a BFF layer, but GraphQL comes from Facebook where a large segment of their users are on spotty mobile networks where round trip reduction is critical to providing a usable experience.

For more info on BFFs: https://bff-patterns.com/

Postgraphile https://postgraphile.org/

Hasura https://hasura.io/

Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.

writing graphql resolvers by hand was what I did in ... 2017. I've been using postgraphile since and couldn't be happier. I don't think I've written a single line of Apollo in 5+ years.

And with postgraphile, and a remix/next BFF, you don't even need a backend!

I dont konw if this is a good practise. I start off initially with REST endpoints that expose (basic) data models - and then have the API the calls it needs. Over time there is a tendency to bloat your REST calls (a good sign is you need to combine two different models - joins). At this point what I have found useful is instead of putting a full blown layer graphql layer that does this scatter-gather for you - I add explicit "viewmodel" APIs. I am sure this was what graphql was for - but for some reason for me having explicit protos/rest specs to model your view models seems more incremental and less stressful. Or may be just old-school thinking?

Reply on news.ycombinator.com