3 ms·

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 cl

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.

jarcane 5y ago
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.
- corpdronejuly 5y ago
  What would you consider to be "necessary GraphQL"
  - jarcane 5y ago
    Are you Facebook?
    - jamesfinlayson 5y ago
      Pretty much this - I can see why Facebook use it but I wouldn't have gained much from GraphQL in any of my jobs.
  - dgb23 5y ago
    Nothing. But the utility it provides is a unification layer for heterogeneous data sources to enable ad-hoc queries on the consumer side.
Chris2048 5y ago
> backend guys being backend I've found backend devs to be more conservative than front.
- handrous 5y ago
  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.
- dgb23 5y ago
  Graphql implementation generic and possibly interesting on the backend and shuffles query complexity to the frontend.
  - can16358p 5y ago
    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.
  - Chris2048 5y ago
    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?

jarcane 5y ago

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.

corpdronejuly 5y ago
What would you consider to be "necessary GraphQL"
- jarcane 5y ago
  Are you Facebook?
  - jamesfinlayson 5y ago
    Pretty much this - I can see why Facebook use it but I wouldn't have gained much from GraphQL in any of my jobs.
- dgb23 5y ago
  Nothing. But the utility it provides is a unification layer for heterogeneous data sources to enable ad-hoc queries on the consumer side.

Chris2048 5y ago

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

handrous 5y ago
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.
dgb23 5y ago
Graphql implementation generic and possibly interesting on the backend and shuffles query complexity to the frontend.
- can16358p 5y ago
  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.
- Chris2048 5y ago
  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?