After writing about how GraphQL and REST differ in various regards, and taking a closer look at caching in particular, I wanted to write about how you can get some of the benefits of GraphQL into an existing endpoint-based API.
It's finally live, and over on the Runscope blog.
Normally I'd post this sort of thing on here, but I've got a smashed racing bike to pay for, Runscope are awesomely generous with their rates, and they didn't meddle with the article in the slightest - other than defeating the usual bevy of typos.
This article aims to highlight the fact that a lot of what is popular about GraphQL is not actually new. That's not to shit-talk GraphQL, but OData covers a lot of the same concepts (with a less lovely syntax), SOAP was doing a lot of this and getting a bad wrap, and - as was pointed out in the comments - SPARQL had a good go at the whole "standardisation" thing GraphQL fans keep touting about their new fave query language.
More on GraphQL:
- GraphQL vs REST: Overview
- GraphQL vs REST: Caching
- You Might Not Need GraphQL
- Representing State in REST and GraphQL
If you appreciate these articles and want me to keep them coming, fire some coins over. Maybe I'll even run the next one through a spell checker.
bitcoin - 1PNbuCjgATjaaHtq7zZKqe3FBL7ngyDi23
etherium - 0x507d6E943885a5AeD76Fa3C43dB5C73a0f1Dc792