5 ms·

"Let's use GraphQL"

can16358p 5y ago
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?
littlecranky67 5y ago
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)

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

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?

littlecranky67 5y ago

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)