Net API Notes for 2019/06/19

Busy week in a busy month.
<Insert folksy personal antecedent here if there is time>

Onto the notes! ;)



A service mesh is how containerized application infrastructure (often supporting cloud-based microservices) talks to its various pieces reliably. As numerous individual items are being auto-scaled up and down, it is imperative to have functionality like service discovery, load balancing, observability, traceability, and authentication that can adapt.

Last week, Christian Posta published an article entitled "Moving the Service Mesh Community Forward". It describes the rationale behind forming the SMI, or a standardized 'Service Mesh Interface'. Using Kubernetes as the underlying container orchestration, the SMI hopes to unify the features sets from a wide variety of service mesh providers, including Istio, Hashicorp Consul, LinkerD, and App Mesh.

For a developer standpoint, I imagine a degree of standardization is welcome news. From a sociotechnical perspective, I will be fascinated to watch which industry players are incentivized to participate, and why.


Infoq recently posted the video of Randy Shoup talking about his talk. If that sounds a bit meta, it is. However, the information is no less useful.

In the short piece, Randy covers a tremendous amount of ground discussing the move from monolith to microservices. I appreciated the immediate caveat that there is a place for monoliths, along with the acknowledgment that these transformations are usually a result of convergent evolution, rather than a coordinated rallying around some architectural cult of personality.

The prized insight, however, was about the appropriate architectural approach while a company scales. Structural complexity to support scale that doesn't exist is premature optimization. Addressing scaling needs at the appropriate times, like when the monolith becomes a problem, is when to lead with modification to the organizational chart (an implication of Conway's law). The technology boundaries will shake out from that.


In the last newsletter I mentioned that Kin announced his return to the API Evangelist. Shortly after that, new content began appearing on the blog. In the piece "Why API Definitions are Important", Kin list several seemingly useful areas where the specification could go further. Right now these are only suggestions but, to me, they make sense.


GraphQL, with it's 'standardized query-language over HTTP-POST', represents a different set of security challenges. These challenges may be unfamiliar to those who have only ever had to maintain and secure more traditional net APIs.

The enigmatic @ghostlulz1337 wrote a piece entitled "API Hacking GraphQL". He provides a high-level overview of common entry points for GraphQL APIs, as well as how to use the query language properties to return detail about the information stored inside.

Once a malicious entity understands the structure of the data, they can then construct a malicious query; the GraphQL equivalent of a Denial-of-Service (DoS) attack. As this piece on Securing your GraphQL API, by Max Stoiber, describes:

"With GraphQL you can query exactly what you want whenever you want. That is amazing for working with an API, but also has complex security implications. Instead of asking for legitimate, useful data, a malicious actor could submit an expensive, nested query to overload your server, database, network, or all of these."

For those running (or preparing to run) a GraphQL API, I'd encourage them to give both pieces a scan.



If you are in the DC or Nothern Virgina area (NoVA) on Monday, June 24th check out the Technical Product Manager Meetup. I'll be discussing 'Planning Tetris', 'Feature Factory', and 'Success Theater' phenomenon (and what to do about them). If that wasn't enough, I'll be using illustrative techniques from the Lego Serious Play approach to walk the audience to new metaphors about their role in the process (hopefully). If nothing else, it will be an exciting experiment.

As I mentioned in the last edition, I'll also be speaking in San Francisco at APIDays, July 16th. The event theme is 'The Future API Stack for New Product Experiences'. My talk will be "Layers, API Governance, and Winning through the Principle of Least Power". I've done with the first draft. I'm looking forward to delivering a subversion of expectations.

For more in-person net API events, check out Is there an upcoming activity that isn't mentioned? I'm happy to add to it if you send me an email.

Finally, as always, my Patreon sponsors keep me well caffeinated through the mornings and nights spent threshing the intellectual wheat from the chaff. Thank you.

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.