Greetings from Brian Levine, Twilio Developer Evangelist

Greetings from Brian Levine, Twilio Developer Evangelist

My first Twilio project

A couple of years ago I posted a for sale ad to Craigslist.  I wanted to include my cell number, but had concerns about posting my personal number on the Internet.  This situation led me to an idea for a phone privacy website, where users could obtain a new “proxy” number, which would forward back to their cell phone.  By posting the proxy number to Craigslist, no personal phone numbers would be revealed online, and I could build cool call management features around the proxy number.

I signed up for Twilio and spent a weekend hacking out the site, which is now called PhoneDynamo. It was my first Twilio project, and I imagine my experience was similar to other new developers. The notion of interfacing my web app with the phone system seemed natural, but I knew nothing about how to do it, and I wasn’t sure how my app server would communicate with the call in progress.

On the Twilio site, I read the Hello Monkey Quickstart Guide, reviewed the docs and just got down to coding. In just a couple hours the core functionality was completed. I couldn’t believe how little time it took and how the natural I took to the API.  There is something really special about the first time you pick up the phone and hear your app talking to you.

My role as a Developer Evangelist

I am thrilled to join Twilio as a Developer Evangelist, and it’s my job to empower you (the developer) to build great things with Twilio.  Having been there myself, I know what an implementer goes through learning Twilio.  I understand that some people are new to REST.  For me, I had trouble understanding the optional StatusCallback, and how to account for call activity inside my application.  My goal is to help you stay focused on the fun parts of development (building!), by helping you understand how Twilio works and fielding any questions you have along the way.

Twilio and your Application Architecture

A great way to learn Twilio is to just go ahead and create a quick page or two to experiment with the API.  For many integrations, a couple of simple TwiML scripts might be all you need to accomplish your goal.  In other cases, you might want to take a more holistic look at your application to plan your Twilio integration.

For example, I have heard from many developers that their application needs to be able to send many API calls to Twilio. However developers are concerned about site speed.  Their website must remain fast, and not keep users waiting for page loads when communicating with Twilio.

Impact Dialing requires the capability to dial a tremendous number of simultaneous calls, while keeping the website page loads fast.  To address cases like this, where your application needs to make large numbers of API calls to Twilio, it can be useful to plan for a middle tier in your architecture specifically tasked with managing the Twilio integration.  By implementing your communications with Twilio asynchronously from your customer facing web requests, you can leave your customer web requests humming along and your users happy.  For Impact Dialing, this architecture allowed us to keep up a great call volume with Twilio, and also scale our application tiers separately according to our needs.

Your Twilio ideas

I would love to hear about your Twilio ideas!  I’ve worked on a good range of Twilio integrations, including a corporate phone system, an OpenVBX plugin, an iPhone app, even LOLCODE.   If you have a new concept, development question, or other feedback, I’m here to help.

You can contact me by sending an email to brian@twilio.com, or find me on twitter. I’m looking forward to making your Twilio experience the best it can be!

Do you want to work at Twilio?  We’re hiring for many positions.  Check out our opportunities here.