3 ms·

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