Net API Notes for 2019/06/12

It has been a strange couple of weeks. On the one hand, there's been a fair amount of content that I've been reviewing on an ongoing basis. On the other, much of it is derivative. When I first created this newsletter, it was with the understanding that people are busy; linking to everything wasn't the point.

The result is that some weeks I delete everything I've identified and start over. However, that means editions like this one have some thought I've found unique and worth your time.

Let's get to it.



When does it make sense to create a shared service? Nick Tune has created a checklist in his piece entitled, "Should we Create a Shared Service?".

Nick succinctly starts by describing the tradeoff:

"Creating a shared dependency can boost the productivity of downstream teams. They can outsource some of their product’s responsibilities to another team owned by another service, and can instead focus more on innovating on their core capabilities.

"Shared services aren’t all fun and games, however. Introducing a shared service creates a coupling and a dependency. Instead of a team being highly autonomous, now they may have to wait on shared service teams to deliver key improvements."

For people creating APIs, guidelines for how to go about decomposing a monolith vary. The questions that Nick lists are a great starting point for practitioners looking to make the right design decisions.


I spend a fair chunk of time reviewing published net API material from the perspective of internal API usage. It is where I see a significant amount of activity and commonality across a broad swath of industries. However, that doesn't mean that external API platforms don't exist. And ensuring that they have proper measurement is essential for their success.

Derric Gilling, in his piece, "Mastering API Analytics for API Programs", talks about which metrics are worth monitoring. An insight that I appreciated was how the sales funnel doesn't end when somebody signs up for API access. How developers flow through pre-integration, use the test and sandbox areas, and register for production should also be carefully monitored.

Utilizing available signals to evolve a program is important. For example, are numerous people signing up for an account but never moving past the sandbox? That is a sign there is a problem. Perhaps the support documentation is insufficient, expected SDK support is absent, or the specific configuration is more trouble than the perceived benefit. Derric lists those issues and more.

For those that manage external API programs, I highly recommend this piece.


If you've spent any amount of time following bloggers, you'll know that Medium is a popular online publishing platform. On the Medium Engineering blog, Xiao Ma has shared a bit about the company's microservices journey.

I appreciate Xiao addressing the semantic diffusion around "microservices"; what once might have been a precise term has been stretched and warped to mean different things to different people (and vendors). Xiao starts by defining his criteria, thankfully digressing to reassert that microservices are not based on size, despite what the name implies.

He then proceeds and shares useful criteria in evaluating how to decompose a monolith. This includes when it makes sense to share implementation details across data layers. Xiao also details the decision making that lead to the selection of gRPC (TL;DR: the automatically generated stubs and boilerplate code possible with gRPC helped sidestep debating different approaches to JSON-over-HTTP design).

It is a practical, real-world example that provides a foil for Benjamin Huston's "Why Microservices Should Scare You More.



EXCITING ANNOUNCEMENT ALERT: I'll be speaking in San Francisco at APIDays, July 16th. The working title is "Layers, API Governance, and Winning through the Principle of Least Power". Will you be there? If so, ping me - glad to chat.

Speaking of events, should be updated. I appreciate the folks reaching out to let me know the URL forwarding from last week's newsletter was funky. At some point, I'll get around to re-plumbing how requests get to where they were meant to be. Do you have an in-person event that isn't mentioned? Shoot me an email; I'd be happy to add to it.

Finally, thank you to my Patreon sponsors for their ongoing support.

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.