Hey Z!
Sorry, I’m a bit confused about this laziness argument. I know you’ve read a few other articles I’ve written about GraphQL, so I know you know that I consider it to be a really well built subset of what REST sets out to achieve, with a bunch of HTTP APIs best practices rolled into one package.
I totally agree, and have agreed many times, that the “being rolled into one package” thing is a big deal. That said, I have seen a lot of articles literally saying GraphQL or gRPC are “better than REST” because they have strict types out of the box, and suggest you should rewrite your REST APIs to those systems based on that.
This messaging is dangerous, confusing, and leads to teams all over the world wasting their time.
If you allow me an analogy. I like bikes.
GraphQL is a really really great racing bike. It comes in blue, it’s made out of carbon fiber, it’s designed by Cannondale for speed, and if you’re into racing its literally the best bike for you. People are confused about why anyone else would have any other bike.
REST is literally the concept of bikes. Not a specific bike. Not a hybrid or a mountain bike, just literally the concept of “bikes”. You can pick your wheels, frame, whatever you want, and put things together in a way that works for your needs.
You can build a racing bike. You can build a mountain bike. You can buy a road bike and swap out the forks to make it into a half-decent cyclocross bike. You can do whatever the hell you want with REST.
Suggesting that a concept full of great ideas is somehow lazy because it doesn’t provide specific implementations makes my brain hurt. If that’s not what you meant then ok, but it sounded like that and it’s a common argument.
Now, of course a lot of people aren’t interested in having to mix and match components or think about how to do any of this, absolutely. They should probably use an existing solution.
A lot of languages have REST packages that cover a lot of stuff, like Grape for Ruby, instead of them having to do everything entirely by themselves. Theres more work to be done there, and yeah 100% gRPC is a more full package.
But sadly a lot of people are acting like GraphQL or gRPC can do something that REST can’t do, just because it does it by default, and a REST API would need to install a single gem to add that specific feature.
> But providing the metadata and then programing the client / server to make use of / provide the metadata takes a non-trivial effort, and frankly, why I should do it in the live-fast code-faster world (rhetorical question)? Most of us would rather throw in some ready to eat solution.
- As I said in this article, Protobuff equally available in REST as it is anywhere else. REST can use Protobuff.
- Writing JSON Schema is not particularly different to writing types in GraphQL.
- JSON Schema is an optional layer of metadata for clients that want to act intelligently, but lets clients JSON in/out if they want to be ignorant. That’s a powerful thing for many APIs (more users = more money)
- JSON Schema can generate Protobuff for you giving you the best of both instead of just the one
The API world needs more education on this stuff absolutely, otherwise people think its hard and don’t bother. People are very welcome to use pre-packaged solutions for specific use cases (gRPC/GraphQL) but I’m going to continue educating about general concepts so they can be used by anyone and everyone.
I do this to avoid people thinking they have to recode to get one thing they need based on some misleading information they read in an article. :)
