Hacker News Reader

Comment by tlackemann | Hacker News Reader

"Let's use GraphQL"

Literally happened to me. Our backend guys decided to switch to GraphQL from perfectly functioning REST. Result: release postponed by 4 months and 30% of the client side had to be rewritten. The whole client logic relies on Redux state as the single source of truth and I always fetch objects fully anyway, so it even makes less sense to switch.

But again, backend guys being backend.

I've begun to recognize "unnecessary GraphQL" as a code smell, and one usually indicative of wider architectural problems in a project.

I have yet to be wrong in immediately steeling myself for the worst the second I see the word.

What would you consider to be "necessary GraphQL"

Nothing. But the utility it provides is a unification layer for heterogeneous data sources to enable ad-hoc queries on the consumer side.

Are you Facebook?

Pretty much this - I can see why Facebook use it but I wouldn't have gained much from GraphQL in any of my jobs.

> backend guys being backend

I've found backend devs to be more conservative than front.

Backend devs—who've been at it for any amount of time—know they're gonna have a really bad night followed by a really bad week and, quite possibly, a really bad month, if the wrong sort of stuff gets written to the production DB. Or someone accidentally deploys redirect or routing code that's effectively an open proxy and kills your IP block's reputation. Or et c., et c.

Graphql implementation generic and possibly interesting on the backend and shuffles query complexity to the frontend.

Well, yes, but you can always trivially "shuffle query complexity to <x>" without mention of whole-project complexity, which might dictate where that complexity should be.

for example, any/all logic can be in the backend. A fn call fn(a), fn(b) or fn(c) in the FE can simply be fn_a(), fn_b() and fn_c() instead, but that would needlessly complicate the backend. If there is an object with N fields, and I want a subset, there are N*2 possible subsets, and whatever number of subsets I need (between 1 and N*2), I can either create that many BE endpoints, or a single endpoint that accepts a list of fields it should return - which is what I believe graph-ql is?

Yup. Not only that the whole client layer has changed completely, it literally added nothing valuable to the project. GraphQL code generation is nice (but has many unnecessary bells and whistles) but Swagger code generation was just perfect too.

Great example, I contract in FE space and GraphQL is very often brought up - 100% in project context where it didn't really make sense and most of the time I got the feeling they will bring it up to have it on the CV or out of FOMO.

I personally see good use in GraphQL for 2 usecases:

- Aggregator over existing (!) microservices backend arch that has REST (plus maybe gRPC) in place, to allow FE people to move fast with their UI. In no way should new services be written in GraphQL, BE should still use REST (+gRPC)

- Prototyping/Fast clickdummy implementation; ideally a Snapshopt of an existing DB is used, and graphQL adapter for 1:1 entity mapping to allow 1-2 FE devs to quickly toss together a new FE (this should under no circumstances be used for anything even close to production)

Cases where it has been pitched to me where I see no increased value:

- BE team is too slow/lazy/defensive for new features (just have a GraphQL adapter and 1:1 map db entities to GraphQL entities -> please don't do that)

- having "typed" queries (you should just use typescript to strictly type your REST DTOs instead and optionally use a VM mapping)

Reply on news.ycombinator.com