Hacker News Reader

Comment by can16358p | Hacker News Reader

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.

View on HN

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"

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.

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

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

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.

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?

Reply on news.ycombinator.com