apis posts

API Complexity Revisited

In a previous article, I discussed Surfaces as an abstraction on APIs and how we could measure complexity as the size of that surfaces' perimeter – the "visible" part of the API to consumers. I shared this article with a colleague who I was actively working closely with on a new implementation of a design system. They has some interesting feedback on different ways of reducing complexity of certain APIs that I felt compelled to revisit this topic.

Agents, Agents, Agents

In 2008, Steve Ballmer once famously said ā€œDevelopers, developers, developersā€ in a highly meme-able video. He was trying to emphasize the importance of software developers in business and that their importance was only going to continue to grow. Microsoft shifted to try to support software developers, noticing that if they supported developers, they would build better software for Windows, which in turn would make people want to use Windows.

APIs, Complexity, and Surfaces

Maintaining growing software is challenging. Poorly architected APIs and incorrect abstractions can significantly impact the ability for engineering teams to deliver new features in a timely manner. If we consider an API's complexity as being a significant contributor to its overhead, maintainability, and ease of use, then it becomes a question of how do we best measure this complexity so that we can make informed decisions about how to refactor and improve our APIs.