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! ;)

NOTES

MOVING THE SERVICE-MESH COMMUNITY FORWARD

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.

MICROSERVICES, THE REALITY OF CONWAY'S LAW, AND EVOLUTIONARY ARCHITECTURE

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.

IDEAS FOR EXTENDING OPENAPI DEFINITIONS

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.

HACKING GRAPHQL APIS

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.

MILESTONES

• RapidAPI, an API marketplace, received a $25 million investment. Microsoft's venture capital arm M12 led the round. Marketplaces are a tricky chicken-n-egg proposition. However, it is presumed that the investment will be used to continue to expand the number of APIs in its portfolio to continue to attract developers.
• I might not have mentioned that APIStrat has a new name: the API Specifications Conference, or "ASC". Steven Willmott, one of the original APIStrat founders, has a post on the change.
• Stephen Mizell has written an OpenAPI extension for changing and evolving APIs.
• Another draft of the "Deprecation" header was published. Given the importance of managing the entire API lifecycle, not just creation, be sure to check it out.
• Prism, which allows API mocking from a spec, just released the first beta for V3.
• I'll end with noting that GraphQL is getting its own documentary. The teaser trailer is on YouTube. I guess this is a thing query languages do now? Maybe? I need to sit down. I feel old.

WRAPPING UP

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 Netapi.events. 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 matthewreinbold.com