4 ms·
> 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.
by JohnHaugeland 4y ago
> 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/dictionaries."
Not an API characteristic
.
"No clear path for Api versioning"
Not an API characteristic
.
Looks like it's actually zero for four
- gabereiser 4y agoIn 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.
- legalcorrection 4y agoIt’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.
- intelVISA 4y agoSeriously. I sometimes think I'm visiting a satirical alter realm when I see these obtuse systems that end up requiring more cognitive energy to glue together than the regular version in <lang of your choice here> being praised rather than derided.
- lelanthran 4y ago> I sometimes think I'm visiting a satirical alter realm when I see these obtuse systems that end up requiring more cognitive energy to glue together than the regular version in <lang of your choice here> being praised rather than derided. You're lucky, you're only visiting. I'm working in that alternate reality :-)