The Composable Future of API Development
This is the 5th edition of GET PUT POST, a newsletter all about APIs. Each edition features an interview with a startup about their API and ideas for developers to build on their platform. Want the latest interviews in your inbox? Sign up here
This week, I spoke with Ross Boucher from Tonic. The company lets developers build APIs by writing JavaScript code in the browser. They’re creating a composable API architecture that removes the hassle of managing servers.
Thanks to Dan at Accel Partners for introducing me to Ross. Enjoy the interview!
What is Tonic?
Tonic helps you rapidly prototype and explore API ideas in JavaScript.
Tonic Notebooks let you quickly write JavaScript right in the browser and execute that code in a Node.js sandbox. You can create a new notebook here. For example, every NPM package has a “try it out” link that lets developers quickly run real code snippets using Tonic. Here’s the canvas package example:
Tonic Endpoints let you expose any JavaScript function as an API. You can interact with it in any app over HTTPS. It’s really easy to prototype a mobile backend or setup a new microservice.
How is Tonic different from services like AWS Lambda?
There’s a movement to write whole systems without worrying about the server. Lambda lets you interact with other Amazon services like S3 and SQS, but it doesn’t make it easy to build a serverless architecture.
In Lambda, you have a separate API gateway that controls HTTP-level functions. You have to hook it up to a function that you published that gets a context object. The work required to try something new is really high.
Tonic makes prototyping possible without any setup.
It can be very difficult just bootstrap a Node project, especially with things like an ES6 transpiler. Our approach is to make it as easy as possible to try out an idea and immediately have a functional API.
You can just require any Node package and we pull it in for you automatically. We create the endpoint on-demand and spin up new containers as requests come in. After you change the code, new requests to the endpoint are immediately interacting with the latest version.
We are much more focused on ease of use and removing the pain when deploying many different services.
Stateless is a totally different model. It’s going to be much more heavily-used by new projects and people experimenting. I do think Lamdba is really good if you’re already in AWS and using a bunch of their enterprise features. We are much more focused on ease of use and removing the pain when deploying many different services.
How do you make the service so fast?
We do everything in Docker and have a pool of available containers. The pending containers are waiting to be told what code to run on every request.
The first step is to configure a pending container. When an incoming request hits an endpoint, a proxy looks up the code for that URL and forwards it to a container. The container responds when it’s ready and then we proxy the rest of the traffic directly.
We don’t need a container waiting all the time like a normal server because it typically takes around 300 milliseconds to start up with fresh code. If you make a bunch of requests in a row to a booted container, there’s only a ~10 millisecond overhead to proxy back and forth.
How do environment variables work in a composable architecture?
Every user has environment variables tied to their account. Whenever a notebook is executed or a request hits an endpoint, we inject those environment variables into the running process. Then, you can use them in your code like normal.
Right now, everything on Tonic is explicitly published, but there’s privacy for environment variables. If anyone clones your notebook, they won’t have the same variables and they can’t see your environment variables if they visit the webpage.
In the future, we’ll introduce fine-grained privacy and sharing models. I still think environment variables will be the right way to store secrets. Just like you don’t want them in your git repository, you probably shouldn’t just have them sitting in code.
How do Tonic Notebooks change the API development process?
The main advantage of the notebook is that you can interactively evaluate code and see the results. You can play around with a function and iterate on the behavior in real-time. Then, you just hook it up to the request handler and it becomes an API endpoint.
We learned a lot from IPython, which is now becoming Jupyter. I don’t think we’re competing with them directly because most people use it for scientific research and computing. Python has a huge set of libraries for that environment and JavaScript doesn’t have the same ecosystem.
Notebooks make it really easy to create a feature or figure out exactly how to interact with a new library. It’s often helpful to break a system down to the smallest composable components and make sure each piece works in isolation. Then, you can easily hook up each component to the rest of the system.
I was recently working on a feature that would take snapshot previews of our website on-demand. I built the whole thing in Tonic and exposed it as a new endpoint. There’s no longer a delay between feature development and deploying a live API.
What are some new features in the pipeline?
It’s very fun to build our own stuff using the platform. Managing all of the containers and routing requests properly takes some pretty complex software, but I think a lot of the simpler parts can be converted to run on Tonic. Here are some of the upcoming features:
- Improved endpoint functionality. Public endpoints aren’t currently designed for running in production and have certain limits in place. For example, we need to expose more visibility into in-flight requests, traffic analytics, and availability guarantees.
- Tools to create sample requests more easily. It’s easy to test the non-request logic, but it’s annoying to create a dummy request object and think through the different edge cases.
- Additional webhook support to connect endpoints to other services.
- Scheduled tasks to trigger functions without an external web request.
What are some cool APIs running on Tonic?
Hopefully this interview sparked some new ideas for breaking down API architecture into simple, reusable parts. If you’re building something interesting using Tonic, tweet at me and I’ll share it in a future newsletter.
Want API interviews in your inbox? Subscribe here
