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

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



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.


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.


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.



Become a Patron of Net API Notes

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

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.