this post was submitted on 14 Apr 2024
202 points (97.6% liked)
Programming
17325 readers
100 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If Json wasn't status quo, coming from a language that's status quo, all these comments could be reversed against it.
And well, if you're not using JavaScript, Json is not that great anyways.
What I like about graphql that Json over rest doesn't have it: fragments and types.
On types: have you ever got across bad swagger documentation? Like a parameter called something unclear like usertype, with no explanation of what it is or examples, ? Oh yeah, it's a string. Very helpful. Well in graph ql, that parameter is likely to be called userType, which if you go into the schema file, you'll likely see it's an enum and you'll also see all possible values. If your backend developer is half decent you'll also get comments right there next to the enum. You don't need a tool to spit out a html page that you'll host somewher. Most reasonable information can be part of the schema file, and that's it.
All that said, everyone now is familiar with Json and rest. Because of that, small projects are better doing it. But that supremacy will eventually end. And for large projects,, specially with static types, graphql makes some things much easier, like types, fragments and unions.