Let Your Users Code

Let Your Users Code

Dan Callahan's photo
Dan Callahan
·Sep 29, 2022·

4 min read

More than 20 years ago, Jamie Zawinski observed that "every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." As he later clarified, his point wasn't about bloat, but rather, extensibility: "Apps that you 'live in' all day have pressure to become everything and do everything. An app for editing text becomes an IDE, then an OS."

In the days of desktop software, extensibility was easy: programs often had built-in support for plug-ins, or if not, the data was right there on your hard drive ready for processing with other tools.

Somewhere on the road to Software as a Service, we lost the power to extend our applications. And it makes sense! If you write custom code locally, it's your computer, your data, and your problem if it breaks. In the cloud, it's not your computer, it's not only your data, and breakage is everyone's problem.

So how do we get extensibility back, now that our software runs on other people's computers?

The Fourth Type of SaaS Extensibility

Traditionally, there have been three ways to extend SaaS applications:

  1. APIs (REST, GraphQL, etc.), which allow programs to directly communicate with a SaaS application to access its data or perform operations.
  2. Webhooks, where a SaaS application can notify a remote server whenever certain types of events occur.
  3. Native Integrations, where the SaaS application provides a prebuilt way to connect itself to other popular SaaS applications.

These all have a place, but they're also incomplete.

Webhooks and APIs let you run completely custom code, but you have to bring your own computer to do it. Native Integrations don't require any effort from the user, but they're rigid and inflexible.

Where's the option to write some code and let the application take care of running it? To operate close to the data and change how things work in situ?

That's the fourth category of extensibility. Not just APIs, Webhooks, or Native Integrations, but also Programmability. Giving people the power to just write code.

Programmable SaaS is Already Here

Millions of people can write simple functions in Excel to summarize and process data. Entire industries run on Excel. If you let people code, they will code.

And this does exist in SaaS... just, not everywhere. Yet.

GitHub Actions is a great example of a programmable SaaS platform. More than just CI/CD, GitHub Actions can run user-provided code in response to many dozens of triggers. These triggers include on-platform activity, off-platform events, and even recurring timers. If something happens, GitHub Actions can run arbitrary code to react to it. And the users don't have to provide any of their own infrastructure... just some code.

This is possible because GitHub's parent company, Microsoft, also runs the second largest cloud computing company on the planet. They have the infrastructure and resources to throw an endless fleet of Virtual Machines at the problem.

But what about the rest of us?

Democratizing Programmability

Many companies have built their success on Programmability. GitHub, as above, but also Salesforce, Twilio, and others. So why is Programmability "a thing" now? Because right now, we're witnessing the democratization of Programmability thanks to browser-borne technologies like WebAssembly.

The core problem is one of running untrusted code safely... but browsers do that all the time. And they do it quickly. Every time you navigate to a new page. And they've developed proven technologies for sandboxing and mitigation to make that possible.

So if you take that technology from the browser and apply it to the server-side, you get all of the hard-won security benefits of that runtime, but in a package that can be operated by a small team and with a minimal footprint. Suddenly, you don't need entire teams of security engineers working full time to maintain a system that sandboxes and virtualizes code execution.

WebAssembly is key because it makes it feasible for many languages, including Go, Rust, and Python, to run efficiently inside a browser-grade sandbox.

So let's do that. Let's let our users code, again.

 
Share this