A large swath of the internet these days relies on APIs to function. Software products, particularly SaaS products live or die based on their ability to integrate with others, and APIs are the best way to make that happen. By exposing your product's functionality with an openly-documented API, your users can take advantage of what you've built in ways you can't imagine, and that is very powerful.
API stands for Application Programming Interface, which is a method of connecting two systems together by defining a set of endpoints or functions that can be called by a third-party.
For a few months now, I've been thinking about how people will build software for the next few years, and something that has become very clear is more software will be built using low-code and no-code tooling. The ability to combine the functionality of multiple services by weaving together their APIs is a powerful skill, and it's becoming a more common method of building workflows, processes, and even entire products. I've heard it referred to as 'Vendor Engineering', which I think is an over-simplification of a complicated practice.
As more companies make the inevitable transition to being a software company, more products will make the inevitable choice to offer an API. Offering avenues to take full advantage of your software by tying it into other products is a great way to drive adoption, create community around what you've built, and create long-lasting partnerships with other companies.
One aspect of today's SaaS integrations is they are most often surfaced to users with a limited set of configuration options that only offer a minimal set of choices for how the integration operates. I see this as a natural limitation of the current generation of API-based integration features, and I've been thinking hard about how this can evolve to help Vendor Engineers build more complex and more tightly integrated functionality.
In my head, this new evolution is 'Domain-Specific Serverless' (DSS). The idea boils down to allowing users to write code that tightly integrates with a product - because it runs within it. By re-imagining integrations as serverless functions that users have full control over, we allow them to be expressed with the highest level of customization.
You could imagine creating links between products by writing code to express what you need. When you inevitably bump up against the available settings for a product's pre-built integrations, you instead could write a dozen lines of code to express exactly what you want. This could be the ultimate solution to a hairy problem. The key is ensuring these functions are executed in a reliable, simple manner, and that's where DSS shines.
Webhooks are commonly used to provide customization and extension to a modern API-driven application, and they are a well-understood paradigm. I posit that we can vastly improve the experience of building these integrations by moving the onus of executing custom code onto the product itself, with functions executing in the cloud right beside a product's app servers. Rather than forcing users to stand up infrastructure and write an entire webserver to handle a simple event or three, let's get out of their way and do it for them.
If SaaS products begin embedding serverless capabilities directly, it allows users to take full advantage of their offerings without needing to undergo the huge lift of developing custom software. This is the key advantage of DSS; a tight integration between the business logic of an application and the execution of users' serverless functions, making it possible to customize a product with little effort. Not to mention the vast performance and security benefits this method has over traditional webhooks.
I'll be exploring this concept more in the coming months as I believe Atmo's WebAssembly-based platform makes perfect sense for these scenarios. Domain-specific serverless is a fairly novel capability that has been out of reach because of the dangers inherent in running untrusted user-submitted code, and Wasm makes it much more tenable due to the properties of its security sandbox.
If you're interested in exploring some of these ideas with me, join the Suborbital Discord and help me build the future of cloud-native platforms!
Cover photo by Laurent Perren on Unsplash