Phil Sturgeon

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.

Recently I wrote GraphQL vs REST: Overview, giving a hype-free outline of the differences between REST and GraphQL. One section that would not have fit into that already lengthy article was caching, so I thought I'd fire that out next.

A few months back I wrote a comparison between RPC and REST for Smashing Magazine, and now I want to talk about the differences between REST and GraphQL: the new kid on the block.

Ignoring one session covering basic CRUD and deserialization using ActiveModel::Serializer, we get to a more interesting session: Handling Errors Nicely.

Now that we've started building a very basic API, we should make sure that the documentation is kept up to date with our progress. Even better, we can use our documentation as a basic contract test, to make sure we aren't lying about what our API offers.

Third video in a pile of LiveCoding.tv videos, shows how to use ActiveModel Serializer to shape the output of your resources. I totally forgot how links work, so watch me flap around trying to get it working and chuckle as I flail.

The second video in a pile of LiveCoding.tv videos shows how to use your API Blueprint documentation to mock APIs, and a few different ways of serving those mocks up to people.

Two years ago I finished the first edition of Build APIs You Won't Hate, and since then I've worked on bigger and better projects, using my API experience, honing some approaches, and throwing out some approaches entirely.

Sidekiq is great. It's a really handy way to take slow stuff that your application is doing like uploading images or sending emails, and get them out of the web request. Users don't want to sit around waiting for that stuff to happen most of the time, and if they do want to be alerted as to the success or failure of a job, there are other ways to achieve that than simply blocking the web request; returning a web socket to watch, polling, emails, etc.

Code of Conducts are, for some reason, hated by a substantial portion of the tech community. For some people I think this comes down to the idea that they are silly and shouldn't be required. I entirely agree with the portion "they should not be required" and have made fun of them myself plenty when they started popping up at conferences a few years ago. Sadly, there is a reason we need warnings like "These peanuts may contain nuts" or "Hot coffee is hot". Some people are muppets, and don't know what being "not nice" is. Some people know, and don't care.