By Matthew Reinbold in Newsletter — Nov 15, 2020

Net API Notes for 2020/11/16 - Issue 146

This week, I've got some thought provoking stories. No intro required. To the notes!

NOTES

HOW NETFLIX SCALES ITS API WITH GRAPHQL FEDERATION

Netflix's "experience layers" is one of the seminal chapters in net API history. Anything published on the Netflix engineering blog is likely to get widely seen, in part, because of that fine pedigree. With that background, it is worth discussing a recent post by Tejas Shikhare on "How Netflix Scales its API with GraphQL federation.

Netflix needed a way of managing all the information related to their studio ecosystem. This includes everything from the initial pitch, business negotiations, production, and through the eventual launch of their custom content. Moving through that workflow involves connected data with known relationships. However, this data was distributed across numerous microservices. Further, as the number of developers grew and the domain complexity increased, it became more difficult to create API aggregation layers.

A federated GraphQL platform solved many of the consistency and development velocity challenges while still maintaining scalability and operability. This graph API provides a unified abstraction while still maintaining distributed ownership and implementation.

If the familiarity of these concerns raise your neck hairs, be sure to give the piece a once-over.

CREATING 'FIT' URLS

Hyrum's Law says that any provided resource, even if only mentioned in the payload of a hypermedia API, invites assumptions. The solution, according to Mark Seemann, is 'Fit' URLs. Fit URL is a scheme where the actual URLs are signed and thus opaque to the client. The thinking goes that if you can't see the values that comprise a URL, you won't go hand-rolling variations (and thus create an undesired coupling).

It is fascinating, at least theoretically. However, I'm unsure of how consumer-friendly this approach is. Seeing the URL relationships connotes a fair amount of insight into how a company operates. Successfully "reading" API documentation is as much comprehending what is written as it is what lies between the lines. I acknowledge, maybe a tuned intuition reflects poorly on the lack of industry progress over the last decade. However, I'm hesitant to call this an obvious win for all sides.

Are you doing something like signing your URLs in a hypermedia API? Is the documentation public? I'd like to explore the approach further with some real examples.

WHY IS SERVICE MESH SO HARD?

I've been talking about service meshes, in one form or another, for years. However, the adoption of service meshes for managing microservice architectures remains limited. Lin Sun, a senior technical staff member at IBM, delves into the reasons why in a recent article.

Specifically, she identifies four reasons service meshes remain scarce:

Lack of clear guidance on whether a service mesh is needed
Fear of breaking services after inserting a new sidecar
Unpredictable starting or stopping behavior for services
Zero code changes to get a service running within a service mesh is currently not possible
There is an incredible amount of complexity in client and service side configurations

For any technology to be adopted, it has to hit a sweet spot: capable enough to address a critical need or solve a problem, but simple enough to remain approachable and malleable. Certain companies may require the complexity of service meshes to manage their highly distributed, complex ecosystems. Articles like this one, however, make me wonder if those cases lie more on edge than in the norm.

MILESTONES

Thrillophilia had a rather nasty API vulnerability. Click through for the full write-up. The TL;DR is that the API blindly trusted the email parameter received.
The Atlantic continues to provide some of the most comprehensive state-level coronavirus data via API. While I have quibbles with the resource design, it doesn't diminish the data's importance.
There's a new IETF working group that targets HTTP usage in APIs. There's a video between Erik Wilde and the new group chair, Darrel Miller.
Apigee has launched a new gRPC service for managing API descriptions. The machine-readable enterprise catalog can be used to populate online portals and power workflow managers.
There's a new Thoughtworks Technology radar out. Of note, "GraphQL Grandiosity" is identified as a major theme: "GraphQL offers convenient capabilities to solve this increasingly common problem. Like all powerful abstractions, it offers trade-offs and requires careful consideration by teams to avoid long-term negative effects." Other noteworthy API-mentions are weariness over "ESBs in API Gateway's clothing" and the CI/CD paradigms possible due to APIs.

WRAPPING UP

To close, thank you to my Patreons. There are many early mornings and long nights that go into scouring the web for what to highlight. I appreciate people declaring, financially, that this work is valuable.

Till next time,

Matthew @libel_vox and matthewreinbold.com