Ignore all the noise and just use an RPC model between your backend and frontend. All these stupid trends and overengineered abstractions will come and go, but people will still be using plain RPC in 5, 10, 100, and 1000 years.
GraphQL kinda sucks
11–20 of 448 posts
Re: GraphQL kinda sucks
#12I tried graphql in a microservices environment and had huge headaches over schema stitching.
Turns out, if you have lots of objects from disparate sources, graphql don’t like that. Now you must stitch these schemas together into an über schema roll query and use with graphql. Maybe we missed a step. Maybe we misunderstood. Maybe it was a bad decision.
Re: GraphQL kinda sucks
#13Earlier quoted context omitted.
A regular api poorly implemented will have all the same cons and none of the pros.
> A regular api poorly implemented will have all the same cons and none of the pros. Okay, so don't make a poorly implemented one? Also, no, it kind of won't. Let's look at what they are again . "It is actually a pain to use" Not an API characteristic . "you'll have to manage two or more type systems if there are no code first generates in your language" Not an API characteristic . "It doesn't support map/tables/dict…
In order to build a properly implemented one, one must first learn to build one. I find most people jump onto graphql because they see the volume of work to create crud endpoints for all of their models and decided to punt.
Re: GraphQL kinda sucks
#14> It can save you bandwidth. Get what you ask for and no more
I don't, and never have believed this argument. I would bet that JSON with Gzip or Zstd is just as small, or close enough that it doesn't matter.
Re: GraphQL kinda sucks
#15Facebook intended it to be used with Relay... so a lot of problems can be avoided by using Relay.
Re: GraphQL kinda sucks
#16Earlier quoted context omitted.
> A regular api poorly implemented will have all the same cons and none of the pros. Okay, so don't make a poorly implemented one? Also, no, it kind of won't. Let's look at what they are again . "It is actually a pain to use" Not an API characteristic . "you'll have to manage two or more type systems if there are no code first generates in your language" Not an API characteristic . "It doesn't support map/tables/dict…
In order to build a properly implemented one, one must first learn to build one. I find most people jump onto graphql because they see the volume of work to create crud endpoints for all of their models and decided to punt.
It’s a false promise. You’re just moving the complexity elsewhere, into wiring this ridiculous graphql infrastructure together and making it actually do what you want in all but the simplest/tutorial-like scenarios.
Re: GraphQL kinda sucks
#17Yes, graphql does indeed suck. Or rather it is not the best solution for all client-server communication that people treat it as, so it ends up being used in a lot of situations where it does suck.
Backend to backend communication is almost never graphql (is that changing in a big way?) which would indicate the main reason for graphql in a client-server situation is data saving but at the cost of complexity and other downsides. Almost certainly the data savings in many cases is not worth it.
Oh and then you have things like Apollo having cache bugs that result in incident level problems.
Re: GraphQL kinda sucks
#18Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers.
Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly, get more or less as they see fit.
It lets everyone move faster.
But as a backend developer, I actually fucking hate it, myself.
Re: GraphQL kinda sucks
#19What exactly is the simpler solution that doesn’t result in your same cons mentioned?
SQL statements wrapped in function calls.
Re: GraphQL kinda sucks
#20> It can save you bandwidth. Get what you ask for and no more I don't, and never have believed this argument. I would bet that JSON with Gzip or Zstd is just as small, or close enough that it doesn't matter.
If you have any data sets with an open text field that you don't care about, or where you really only need to get the ID from a wide table, it will definitely save a ton of bandwidth. How often that really matters on the other hand...