Yay-PI!
Join us in making a better Emma experience for everyone
Last Wednesday, our new API officially entered private beta, swinging the doors open to early adopters. To prepare for the big day, we tech elves were busy getting the API to a state where, while still not bug-free, it would be functional. And now our adventurous beta testers are helping us identify remaining bugs and performance bottlenecks.
On top of the work to get the interface part of our API locked down (view the documentation), we have also been focusing on converting the application to use this new API. We are, to use a less-than-appetizing phrase, eating our own dog food. We’ve standardized the way data is handled by the system, so that when we build a new feature for the app, we automatically get an API version of the feature that we can open to the public. To those who have used our legacy web services offering, and have had to work with the limited functionality it provides, you understand how important it is to ensure that all users of Emma, be they via the API or the UI, have access to the most complete set of tools we offer. This also means the API calls our customers have access to are the same calls my coworkers and I must develop against. So, if a call doesn’t return correct data, or isn’t performant, we will feel the headaches just as you do. And nothing motivates a developer to improve their code faster than making them actually use it.
I hear some of you asking, “I only use the web interface and don’t really care about APIs or building my own Emma at home, so what’s it in for me?” Quite a bit, actually. However, if we’ve done our job right, not much that you’ll see. Not initially, at least. Redesigning the architecture has taught us a lot about the challenges of the existing system, and the new system avoids those altogether. From the way members and groups are stored to the way emails are sent and tracked, the new systems focuses on simplicity and extensibility. So, as we start to roll out the new Emma to all of our customers, you’ll go on using Emma just as you always do, only noticing that the app is more responsive, and that your mailings are delivered even faster. The real fun will happen later as our new system design will facilitate the addition of new features, something the current design makes more difficult to accomplish at the pace we’d like.
So far we’ve only invited about 25 people into the private beta, but it is already yielding some fantastic feedback, uncovering bugs and giving us a slightly different point of view on what some of our power users need in order to integrate Emma into their own application. If you’re interested in joining the private beta group and test driving the new API, or the updated Emma built on top of it, please visit the beta tester signup form.
4 comments
Leave a comment

Paul Provost commented:
Nice, but will this include 2 way sync to Salesforce that I was told would be ready around July 2010?
Hernán Ciudad commented:
Hi Paul! That’s a great question. We currently have contractors working on a Salesforce AppExchange app that will provide some two-way sync functionality between Salesforce and Emma using the new API. Once the coding work and testing is complete, we also have to get it approved by the folks at Salesforce. We’re so sorry to keep you waiting, but we’ll keep you posted as we get closer to releasing this. Let us know if there’s anything else.
Mark commented:
I’ve beta test your new API and it was super-easy to get started with. I’m really looking forward to the day it’s ready.
I’m working on upgrades to my company’s web application, and I’m curious when you say that you’re developing your web app based on your new API, does that mean that your web application is making HTTP requests to your API as opposed to directly communicating with your database through your Python (or whatever) code?
I’m curious because it seems like that adds an extra layer that would slow things down. Can you interact with your own API without making HTTP requests?
Hernán Ciudad commented:
Hi Mark! Glad to hear you’re enjoying working with our new API. We’d appreciate any feedback you have on changes to the existing set of calls, or new calls you’d like to see added.
We do indeed make calls from the application to our API over HTTP. However, they are all made inside the internal network, which has been designed to minimize impediments between the API and any internal systems that require access to it. So, performance really has been comparable to the more traditional method of just having the application servers talk directly to the database. The only real bottlenecks we’ve experienced have been either unoptimized database queries pulling data in the API, or app code that inefficiently processes the data returned by the API, both of which we are busily trying to remedy before we do a public release.
I hope this information helps. Thanks for your comment and make sure to keep in touch about your experiences with the API.