What the Avocado API Can Teach Developers About Scalability and Innovation

This guest post comes from Chris Wetherell, CEO of Avocado Software, and Mike Maelzer, Avocado’s lead engineer. You can follow them on Twitter @cw & @maelzer.

Every day, tens of thousands of API calls result in a virtual hug or kiss sent through Avocado, the multi- Platform couples app. For messages and other media, it’s dozens of times more, resulting in millions of calls a day to the Avocado API... and growing. So far: No major service disruptions, no server explosions, and hardly any pulling of hair out from our heads.

We think we’re building a new layer of the internet, one just for couples, and we intend to set a standard for the kind of service we provide: fast, reliable, and easy to scale both within and across platforms. We believe the only way this can be done is via open development, a robust public API, and a supportive third party developer network. But mostly, we’re bullish on APIs.

Eating Our Own API

The quality of our API is directly related to the fact that we use it ourselves, and we treat ourselves just like a third party developer. (We’re better if we walk a mile in the shoes of our developer community.) We even use developer tokens for our separate clients (web portal, iOS, and Android). Sure, we could have used one token for the whole system, but we wanted to break it out to track usage numbers and have the option of temporarily shutting down a client in the unlikely event that something goes horribly awry (knock on wood). As a result of our standards, third party developers can easily recreate anything Avocado itself does.

The API was the absolute first thing we built. It was around before we even named the product. An API means quick iteration during a product’s earliest stages, and it’s an aid to creativity. It allowed us to think about what we call “practical innovation.” We can innovate in the client, but the path of least resistance is to work with the existing API we’ve built rather than refactor the whole system. This leads to us using our creativity to build stuff that's more likely to ship to users. That plus building the web app allowed us to arrive much more quickly at what our entire company was going to be - the long term vision. We’re an API first company.

If you’re going to build something that you think will eventually grow a large feature set and will outpace the growth of your company, but you don’t yet know what all those features are, the API-first mindset is the way to go.

Scaling Business & Servers Faster

Courting engineers by making something fun and easy to develop on is just smart, basic business for startups. We personally know a number of developers that use Avocado due to the fact that we have API. It allows passionate users more control.

With Avocado’s public API, we can emerge on less popular platforms faster. One example is “Lovocado,” created by a third party developer for the Windows Phone.

Since our API is built on the well-established REST design model, it's easy to hook up almost any type of client - be it browser, mobile, or desktop - and begin creating and consuming content on Avocado. Our REST API consumes and sends data in the ubiquitous JSON format making data exchange simple in today's software development world. Most mobile (and desktop) frameworks provide built-in libraries for interacting with JSON data, allowing developers to focus their efforts more on the creative side of displaying and manipulating the data they receive from Avocado. In the browser, it's even easier as JSON is actually derived from JavaScript.

On a horn-tooting note, we scaled this system quickly and fairly easily a few months back.

But Then, the Downsides of Scaling

Being popular comes with a unique set of problems. It’s not as easy to change direction once you have people dependent on your API (see: Twitter developer community). Changing our routes, the name of a method, a URL or what the url accepts would break a third party app until the developer could ship a new version. Avocado’s developer community is still fairly small, so we’re lucky that we can make such changes without millions of people being affected.

Another downside: Conflicts between mobile vendors can potentially slow or complicate your API development. A mobile vendor could change how a device or OS works and make it difficult to support a broad feature in your API (iOS 7 issues, anyone?). Maybe this encourages you to delay a feature until the most popular vendors can have the same experience. As we've seen, some media uploading calls can run into problems if trying to support the many flavors of Android, iOS, and web browsers all at the same time.

Although we won’t go into it in depth here, we should note two other common problems cited when discussing API scaling with third party developers. First, questions of security: If you don’t set limits, a malicious third party developer on your platform could take down your servers with a sudden, massive influx of API calls.

Second, having third party developers adds a new level of customer service. They’ll come to you with issues they find, and your engineers need to have the bandwidth to respond to them quickly.

APIs Guide Innovation Closer to the User

If we have satisfactory API development, we can focus on solving other problems. We push innovation further along the Stack, not in the API but in User Experience. For example, Avocado established generic "activities,” which are basically chat messages, but ones that allow for flexible types and a different kind of rendering. As a result, it was easier for us to consider an "anniversary card” when a couple joins Avocado. Or send a message when the phone was "hugged.” We simply reused the existing API which led us to focus on making individual experiences look and feel better.

Creating an API also gets you further along the path of allowing users to do such things as exporting their own data, which is exactly what we’ll be doing with our paid service. Having the API makes exporting data a lot easier to keep in mind while building. If we build a feature that a third party app can use, then we basically made the ability to extract that content.

There should be a rule that if you increase the amount of innovation thinking around your product, you increase the amount of inspiration that your team finds in what they want to build. Similarly, if we can inspire innovation in third party developers who go on to create product improvements and unique mashups, we’re guaranteed to inspire our own team. Innovation is infectious.

Be sure to read the next Best Practices article: Simple and Effective Ways to Avoid the Honeypot