Net API Notes for 2019/09/17
There have been lots of announcements this past week. Let's get to them!
IDENTIFYING GRAPHQL'S SWEET SPOT
Where GraphQL shines is when the API client and the producer are the same (or close to it). This is Chris Coyier's conclusion in his piece, "The Best GraphQL API is the one you write". It is a sentiment shared by Ben Nadel in "REST And GraphQL Are Not Your Only Choices When Building An HTTP API".
If Chris's point is that GraphQL is super convenient when both the producer and consumer are intimate with the problem set, Ben's point is that if the producer and consumer are even more intimate (like the same person on a smaller dev team) then even the hoops of adopting GraphQL may be unnecessary.
What I also found interesting about Chris's GraphQL piece is that we often hear about how a GraphQL's query language makes it superior in usage to a REST-ish (or net) API. Imagine my surprise, then, when Chris provides several examples of where a GraphQL's design (or lack of it) impedes the consumer. It turns out a standardized query language over HTTP might not be the silver bullet it was billed as.
An API experience, in most cases, should be designed. However, as these two pieces illustrate, the form that design takes is entirely dependent on the context.
AN APPROACHABLE GUIDE TO CACHE HEADERS
"The fastest request is the one that doesn't need to happen."
Development teams are willing to try many things to get better API performance. That includes esoteric architectural patterns, untested frameworks, and trivial refactoring. One of the biggest bangs-for-the-proverbial-buck, however, is including reasonable caching headers with an API request.
Harry Roberts has an approachable guide to the most common caching headers called "Cache-Control for Civilians". Must you implement all of them? No. However, implementing even a few (and nudging clients to use them) can have a huge positive impact on API performance.
STUDYING AMAZON'S EVOLUTION INTO A MICROSERVICE ORGANIZATION
Amazon has been building API-led, distributed systems for twenty years. Werner Vogels, Amazon's CTO, summarized the journey in his piece "Modern Applications at AWS".
What started with a monolithic bookstore application has created numerous touchstones a modern developer will be familiar with: from two-pizza teams to continuous integration to microservices. Serverless even makes an appearance!
If you follow the space intently, there may not be much new here. Further, a retrospective over this amount of time is sure to smooth over many of the rough edges. But, for those interested in seeing the big picture of how numerous technical components aggregate together into profound business differentiation, this is a refresher for you.
MILESTONES
September is when I see folks shake off the summer slumber. This fall sees a slew of announcements in the fall conference season. A brief list includes the following:
- OWASP announced it's top 10 API Vulnerability List. This is similar to lists for its Web and Mobile applications.
- NGNIX deepened its API management capabilities, Kong introduced Kuma, it's "universal service mesh" (based on Envoy), and Postman has a crazy number of things that it can do (slide deck by Valentin Despa).
- Speaking of Postman, Kin Lane has joined Postman as their Chief Evangelist. You can expect plenty of additional Postman coverage from Kin, like the usefulness of combing NASA to create a Postman collection.
- Version 2 of the AsyncAPI specification is done. Changes include tweaks to the various subsections, specifying multiple protocols, multiple message schemas, and more.
- A new CLI from Optic allows for monitoring of runtime traffic against an OpenAPI description.
WRAPPING UP
The meetups and conferences for the end of the year are coming up quickly. NetAPI.events is my list of in-person opportunities to socialize with other API practitioners from around the world. If there is a meetup, hackathon, or conference that is missing, let me know. I'd be happy to add it.
Finally, thank you goes out to my Patreons.
Till next time,
Matthew @libel_vox and matthewreinbold.com