Development

Twilio Previews a Serverless Capability, Called Functions, to Manage Messaging Apps

28 Jun 2017 2:00am, by

Twilio has launched a preview service, called Functions, that lets developers write and run serverless code within the Twilio Runtime console, giving them more control over how to manage their Twilio API-driven messaging applications. This pre-configured environment has helper libraries, API keys, asset storage and debugging tools, which can be accessed inside the Twilio web portal.

“The primary reason we built Functions was to improve the speed of development, to make it so you don’t need to think about ‘how do I scale web infrastructure?’” Twilio messaging general manager Patrick Malatack told The New Stack. “Now you don’t need to think about scaling, you just deploy it to Twilio. We abstract away all the OS, all the hardware, and all the infrastructure and let you focus exclusively on your code.”

Twilio Functions isn’t intended to compete with general use serverless environments, such as Azure Functions or AWS Lambda. In fact, it runs on Lambda. Rather, it can help developers better scale and manage their Twilio-based messaging apps.

Twilio has had a web-based GUI for letting non-developers create small voice and SMS applications (called Twimlets) for some time. You can create TwiML (Twilio Markup Language) apps and TwiML Bins to store that code that handles incoming call events, in the Twilio portal.

Usually, the first step in building an app using Twilio APIs is standing up a public web server to receive the webhooks, those APIs used to connect to remote software, and to manage the authentication and access tokens to do that securely. That’s one more thing to troubleshoot when you’re prototyping and app, and when you put an app into production you need to make sure that the server scales to cope with the demand.

Functions does away with the need for that server, removing one more thing that can go wrong. It lets developers use templates with pre-written code and configuration or write Node.js code. There are a handful of templates to handle common patterns like call forwarding and setting up a conference or creating an access token for Twilio’s Sync service, with more in development.

 

Creating a new Twilio function from a template or with your own node.js code.

“I use Sync for my state and Functions for all my compute and I can build any communications experience on Twilio,” Malatack told us.

Start with one of the templates and the code editing window is pre-populated with code, including the credentials and environment variables passed in from the function configuration (stored as key-value pairs), the event information passed in from the Twilio API you’re working with (using GET and POST) and the callback method you call to return from the function (which can be TwiML, JavaScript, a string — or a string that you use to indicate an error).

You can use the Twilio Node helper library to generate TwiML for handling voice and messaging events programmatically, and you get the same debugger support that’s been in the Twilio runtime for a couple of years. “All the webhooks that Twilio apps are generating; sometimes they hit a server that’s down, so you need to be able to debug that. Functions has that debugger support out of the gate, so you can see what happened to my code, what went wrong?” Malatack said.

Functions also auto scales. A user gets 10,000 free function invocations a month and they cost $0.0001 per invocation beyond that — volume pricing will be available once Functions is out of preview. You can also store arbitrary content for your app in the Twilio Assets service.

Functions covers all the Twilio APIs, and developers can use the built-in got module to handle third-party REST APIs. That’s not the focus for Functions, Malatack explained, so the experience is fairly basic. “Our focus is on making it the best place to build for Twilio. But if you want to have, say, a Stripe webhook hit a Twilio function, technically that works and there’s no reason for us not to support that.”

You can hook your function up to Twilio phone numbers in the Twilio web portal, or you can use the URL shown in the console to call your function. There’s a handy Copy button that lets you test your function in a web page.

Functions code in the Twilio consoles.

Currently, you’re working with Twilio Functions in the browser rather than an IDE; “We’re thinking a lot about how do we integrate with your existing toolchain,” Malatack told us, so as Functions matures we’re expecting to see ways to build, test and deploy Functions from other developer tools.

Removing the Distractions

The serverless programming model is a logical next step from webhooks because you get the event-based programming without the overhead of hosting a web service, and Twilio isn’t the only one picking up this idea.

The new MongoDB Stitch service for MongoDB Atlas is labeled as a Backend as a Service, but you get pipelines for handling authentication, data access control and integration with communications, messaging and payment APIs (including Twilio’s) without spending as much time on coding and infrastructure for those tasks.

If you’re writing a software-as-a-service app that you’d like customers to be able to extend themselves, Auth0’s Extend service gives you a React embedded code editor lets customers create serverless node.js extensions. Similarly, Zapier’s Developer CLI tool lets you write, test and deploy Node.js apps as part of a Zapier integration flow if the inputs and outputs of the APIs you’re integrating need a certain amount of massaging or tweaking; again, that uses AWS Lambda to run your custom code.

Twilio Functions shows serverless is as much a programming style as a service, and you can expect to see the option of running functions without caring about the infrastructure showing up as an option in more places.

Every Twilio function has a fully qualified URL you can use to invoke it.

“Think about all the time and effort that is spent on things that are not your code and the experience you want,” Malatack pointed out. “Part of the reason why we see the amazing user experience we now have is that the abstractions keep getting better and better, so you can spend more of your time around ‘What’s the right outcome I want’ rather than all the things I need to do on the way to get there.”

Feature image by Shwetha Shankar via Unsplash.

A newsletter digest of the week’s most important stories & analyses.