Net API Notes for 2020/01/02 - Issue 117
Looking back, 2019 was notable for several reasons:
I wrote more than 25,000 words on APIs in this newsletter, as well as a fair bit more over on my public website.
While the landing page is very rudimentary, I've put considerably more work into processing the archives with Natural Language Processing (NLP) and Named Entity Recognition (NER). That should set the foundation for some harvestable projects going forward.
I rethought my travel and offset 34.5 tons of carbon dioxide; more to do, but it is a first step.
Since I've been trying to cut back on the caffeine, I've been redistributing Patreon money to, among others:
Pihole, a hardware ad blocker that runs on a Raspberry PI
Sam Aaron, a pioneer in the realm of "communicative programming" with the Sonic PI Project
Sam Battle, lover of musical junk and innovative creator of Furby organs and synthesizer bikes
In 2019, I also ran two 5ks. My times won't dazzle anyone, but after tearing a knee ligament and enduring a 9-month recovery in the not so distant past, I'll take it.
LOOKING FORWARD
Prediction is a game of numbers: throw out enough of 'em, and eventually statistics say you'll be right on something. While I fully expect to be surprised throughout 2020, here is some of the things I expect to write about in the coming year:
- Service Meshes - The service mesh hype has cooled as people move into implementation. The "lessons-learned" case studies are emerging, and the challenge of debugging this-much-distributed anything ain't pretty. Still, for companies that are embracing the cloud at scale, the complexity will require further discussion.
- Event-driven Microservices - The area including webhook apis and asyncapi will continue to grow. While this approach doesn't enjoy the stratospheric trajectory that service meshes did, it also won't have the crater of disillusionment, either. The demand for real-time experiences continues, and so will architectures to meet it.
- AI via API - I have a low tolerance for vendor BS, and much of what is touted as AI stinks of it. However, for specific applications, machine learning will be significant. Creating models for things like image recognition and language processing are bespoke, expensive affairs. Because of this, the future of AI will be delivered through APIs. I feel this so much so that I'm presenting on this topic at the January 7th DC Web API meetup group.
SUPERFACE.AI
Also looking ahead are Zdenek Nemec and Mike Amundsen. At last December's Paris API Days conference, they jointly announced superface.ai. "Superface" is a portmanteau of "super" and "interface". A superface, as the newly launched website describes, is a combination of:
- Autonomous APIs
- Decoupled Components
- Self-Driving Clients
You can review the slides and prepared remarks in the deck "The Mother of All APIs".
"Wait," I can imagine you say, "isn't that just hypermedia?"
In part, yes. Providing meaningful affordances, in the form of hypermedia links, remains an underutilized aspect of many API designs. The perceived utility of links, however, was never the hangup to adoption. The crux is being able to meet developers where they are.
The business reality in my inbox - be it regulatory accountability, security efficacy, or privacy enforcement - is predicated on knowing who the person is, what information they have access to, and when they accessed it. Humans remain in the loop for making the call on those decisions, and will mostly likely remain so for liability reasons. A free-for-all, autonomous, discovery and consumption story is not where business is at.
Further, there's friction between delivery incentives (produce an outcome ASAP) verses idealized, architectural ones. While long-term business outcomes should be aligned with architectural investment, this is a very hard thing do, much less maintain.
I'd like to be wrong on this and see superface.ai flourish. The year ahead will be telling.
MILESTONES
- Tom Johnson, organizer of an API documentation workshop I recently added to WebAPI.events, also is running a survey. Tom is a tech writer and is gathering details about trends, tools, practices, and workflows. If you've got a few minutes to spare this new year and have thoughts on developer documentation, give the survey a few minutes and help Tom out.
- At re:Invent, Amazon announced the least searchable product name, ev-var: API Gateway HTTP API. The company has had some naming clunkers in the past. As someone who regularly goes deep into naming for intuitiveness and comprehensibility, I can confidently say this sets a new standard.
- If you are interested in the Oracle v Google API case the Supreme Court will hear, there's now a comprehensive update available.
- Facepager, a tool used by researchers for studying Facebook, has a new lease on life. You might remember the ban contributed to the '#APIcalypse' for many academic researchers in early in 2019. We'll see how long this access holds.
- MessageDB launched. It promises to be an event and message store for PostgreSQL, providing features like Pub/Sub on top of the popular open-source database.
WRAPPING UP
Interested in meeting with other like-minded API practitioners? Make a New Year's resolution to meet with folks and check out NetAPI.events for the latest happenings in your area. If you know of a meetup, hackathon, or conference that isn't there but should be, respond to this message and let me know.
I'll end by saying thank you to the generous Patreons who have continued to support this newsletter in small but meaningful ways.
Till next time,
Matthew @libel_vox and matthewreinbold.com