3 ms·

Care to elaborate?

by plun9 3y ago

Care to elaborate?

firecall 3y ago
In my experience, it’s unnecessary layers of abstraction for benefits that are not realised unless you are at some level of scale where you know it does. Facebook invented React and GraphQL for good reasons. But many of those reasons don’t apply but the implementation does add development time and code complexity. In a React and Django Graphene API situation, you have to write GraphQL queries and mutations on both sides. The idea being you might write a GraphQL query that only retrieves exactly the data you need and nothing more. Which is great when those optimisations improve customer experience, but for most of the SMEs I work with, they do not make any perceivable difference. GraphQL is layering on complexity and additional libraries when a good old fashioned REST API does everything you need anyway! I guess GraphQL is fashionable right now!
- MichaelRo 3y ago
  "Mit Kanonen auf Spatzen schießen" : shooting sparrows with a cannon. This is the story of software development, nobody uses a shotgun to get the job done quickly, because afterwards they're out of job. It's borderline criminal but all the nonsense is about scamming your employer to pay you hefty money for many years to build the Kaiser Wilhelm Gun. And the "geniuses" disappear right when the project gets to be delivered. Like the past few projects I worked on, the original developers that shall remain unnamed would spit out code like there was no tomorrow, always latest fashion and of course throw one or two badly broken ad-hoc domain specific languages pulled out of their ass. Get paid for two years or so and in 6 months before scheduled release, suddenly "be assigned to an uttermost important project", in fact another two years of jacking off with no responsibility. While their piece of art gets transferred to suckers like me who only need to do the "easy" finishing touches and get it released. If it succeeds, praise is in them, if it fails, it's my fault.
  - sparker72678 3y ago
    Where do I get one of these jobs where you make every task take longer than it should but get promoted instead of fired?
    - firecall 3y ago
      DM me when you find out ;-)
sparker72678 3y ago
If you're providing an API that's well defined and constrained in scope (i.e. a typical CRUD API where you're creating/modifying normalized objects in a non-changing object hierarchy), then graphql is usually just a shitload of unnecessary overhead. Examples that come to mind: 1. An internal API where you own all the clients (you own every query; optimize them.) 2. An API that deals with objects where scopes aren't going to vary (i.e. if your clients are fetching the same 6 basic queries every time, you're not getting benefits out of GQL). 3. APIs that are write/update heavy. Every mutation is the same amount of work (or more) that a REST controller would have to deal with, but you have the overhead of the GQL library on top. Basically: everything is just JSON on the wire anyway. Stop paying the overhead penalty of GQL unless you have a zillion clients and a massive object graph that's going to be queried in unpredictable ways. Typical REST libraries make backend code management and structure MUCH cleaner than GQL, with much more obvious points for caching, query optimization, etc.

Care to elaborate?

by plun9 3y ago

Care to elaborate?

In my experience, it’s unnecessary layers of abstraction for benefits that are not realised unless you are at some level of scale where you know it does. Facebook invented React and GraphQL for good reasons. But many of those reasons don’t apply but the implementation does add development time and code complexity. In a React and Django Graphene API situation, you have to write GraphQL queries and mutations on both sides. The idea being you might write a GraphQL query that only retrieves exactly the data you need and nothing more. Which is great when those optimisations improve customer experience, but for most of the SMEs I work with, they do not make any perceivable difference. GraphQL is layering on complexity and additional libraries when a good old fashioned REST API does everything you need anyway! I guess GraphQL is fashionable right now!

MichaelRo 3y ago
"Mit Kanonen auf Spatzen schießen" : shooting sparrows with a cannon. This is the story of software development, nobody uses a shotgun to get the job done quickly, because afterwards they're out of job. It's borderline criminal but all the nonsense is about scamming your employer to pay you hefty money for many years to build the Kaiser Wilhelm Gun. And the "geniuses" disappear right when the project gets to be delivered. Like the past few projects I worked on, the original developers that shall remain unnamed would spit out code like there was no tomorrow, always latest fashion and of course throw one or two badly broken ad-hoc domain specific languages pulled out of their ass. Get paid for two years or so and in 6 months before scheduled release, suddenly "be assigned to an uttermost important project", in fact another two years of jacking off with no responsibility. While their piece of art gets transferred to suckers like me who only need to do the "easy" finishing touches and get it released. If it succeeds, praise is in them, if it fails, it's my fault.
- sparker72678 3y ago
  Where do I get one of these jobs where you make every task take longer than it should but get promoted instead of fired?
  - firecall 3y ago
    DM me when you find out ;-)

sparker72678 3y ago

If you're providing an API that's well defined and constrained in scope (i.e. a typical CRUD API where you're creating/modifying normalized objects in a non-changing object hierarchy), then graphql is usually just a shitload of unnecessary overhead. Examples that come to mind: 1. An internal API where you own all the clients (you own every query; optimize them.) 2. An API that deals with objects where scopes aren't going to vary (i.e. if your clients are fetching the same 6 basic queries every time, you're not getting benefits out of GQL). 3. APIs that are write/update heavy. Every mutation is the same amount of work (or more) that a REST controller would have to deal with, but you have the overhead of the GQL library on top. Basically: everything is just JSON on the wire anyway. Stop paying the overhead penalty of GQL unless you have a zillion clients and a massive object graph that's going to be queried in unpredictable ways. Typical REST libraries make backend code management and structure MUCH cleaner than GQL, with much more obvious points for caching, query optimization, etc.