Whit’s Developer Magic Syncs Emma and Highrise APIs

Whit Nelson, one of Mightybytes’ developers, has been stirring the cauldron of API development recently to make magic happen.

He’s been working with APIs—Application Programming Interfaces—which open up the inner workings of a product (such as Gmail, Twitter, etc) so that developers can create new applications and services around them. Working on a simple project with an API can mean great improvements for the whole ecosystem of users and developers.

When Emma gave Mightybytes a sneak peek at their API, Whit set out to integrate it with Highrise from 37 Signals. The result would be efficient: When companies sign up users for their newsletters, their lists of contacts in Highrise would be automatically synced with it.

Whit, tell us about the project.

Highrise and Emma have separate but overlapping functionality. They can’t do what the other one does. Joining them is of value, so it’s a valuable tool to have them sync. There should be no need for GUI if this works. You shouldn’t need human interaction.

What were you looking to sync?

Contact information for people and companies. Emma is designed as an email marketing engine and Highrise is a customer relationship management application. Making sure that when someone signs up for the newsletter that they get dropped in your CRM is important. On the other hand, if you add contacts to Highrise, it would be nice to have them added to email campaigns.  Presently, none of this is automatic. I created a data services which pings both APIs to reconcile the records.

Have you done many projects like this one?

That has been an interesting challenge for me. I have never done a sync before. This is a whole new level of conceptualization. So found it useful to to think about it like someone who is doing this process manually, then implement that in the code.

What is your workflow like?

I created a third party application in Google App Engine, which offers a hosted service that works naturally in the google app marketplace. In App Engine, you’re forced into a different style of programming. You’re prevented from doing things that normally grind the server to a halt. For example, when I program in PHP, if I want to retrieve multiple phone numbers for each record, I could do that with a JOIN statement in the database that would cross reference every person with every phone number, which is quite server intensive. If I cross reference 10 people with 10 phone numbers, that’s 100 comparisons. If it’s 1,000 people with 1,000 numbers, you’re at a million comparisons. Google app engine won’t let you do that. You have to formulate a new way. You have to be very selective. Google designed it this way.

Have you run into any roadblocks while working on this project?

The reason I chose Google App engine and Python is because Python is one of the most elegant languages I have seen. It’s almost readable in English. For someone to be able to read it and get the gist, it’s pretty incredible. As a programmer, it means that a lot of the low-level gotchas in other languages aren’t there. It’s all been smoothed out. You just have to think about high level things. I can focus on what do I want this code to do.

What do you do to diffuse stress when you are programming?

You have to remember that these software projects are going to be break. If you think it’s going to work perfectly the first time, frustration will set in. So you need to think it’s not going to work so you can stay one step ahead. The computer only is doing what you tell it to do. It’s not out to get you. We tend to apply our own anthropomorphisms to this thing, but it’s only going to do what a human told it to do.

How do you feel about more companies and products making their APIs available?

It’s the right direction. The move from a closed universe of data into this “Build an API first, ask questions later” model, is right. People build APIs right now without really knowing how they will be used. That’s for other programmers to figure it out. It’s really exciting for new developers to know they have access to incredible services and servers that are doing great things and now it’s on you to figure out how to use these tools.

The next step would probably be a grander structure built on top of several APIs. At some point you need all this data to get smarter and more organized. It would be great to have an API of APIs that would offer data synthesis that we don’t have right now. I know this all very vague, but then again, if I knew what the next big thing was going to be, I’d probably be building it.