How Nylas built an API empire from open-source roots

Published in

GET PUT POST

9 min readMay 5, 2017

Welcome to GET PUT POST, a newsletter all about APIs. Each edition features an interview with a startup about their API and ideas for developers to build on their platform.

This edition, I spoke with Michael Grinich, CEO of Nylas. This company exposes RESTful APIs to abstract away the pain of email and calendar data. We cover everything from the company’s open-source DNA to challenges scaling MySQL. Enjoy!

What is Nylas?

Nylas is a developer platform for building on top of email, calendar, and contacts. We enable these apps through the Nylas Cloud API and Nylas Mail.

The Cloud API is a REST API for accessing data in a mailbox, calendar, or address book. It’s middleware that abstracts the difficulties of MIME, IMAP, SMTP, and Microsoft Exchange. Nylas Mail is a desktop app that functions as a primary email app, a replacement for services like Gmail or Outlook that’s built to be extended.

The desktop app is built in JavaScript, which lets folks build powerful, rich add-ons suited to whatever their use case is. For example, we have a great Salesforce plugin that transforms email for salespeople by turning it into a battle station and bringing their data together. Also, developers have built plugins to integrate GitHub, Slack, Evernote, Trello, and Todoist.

All the different products that touch email and calendar can now be integrated with each other.

How far along are you in this mission?

We’re less than 15 people, about three years old, and serve over 50 million API calls per day. We run across hundreds of servers in AWS and store terabytes of data.

For our Cloud API, we replicate the mailbox, and translate it to a more modern format, which requires storing all of the data server-side. At this point, we have dozens of terabytes in MySQL. It’s a challenge to manage that and build a performant API on top of it.

Can you name some products that are built on Nylas?

One example is an app called Lever, which is a new recruiting tool for HR professionals. Lever allows recruiters to send emails from within their applicant tracking system. It also facilitates calendar invites for interviews.

Another example is Pipedrive. Pipedrive is a next-gen CRM that helps sales teams facilitate deals, structure that process, and create reports.

Tell me more about your stack.

The stack is similar to early development I did at Dropbox. We have one large application service that powers the custom sync engine service. That’s what connects to the mail providers (Gmail, iCloud, or an Exchange server) and deals with protocol negotiation, authentication, and data exchange.

The majority of the codebase of that system is written in Python. We use SQLAlchemy as an ORM to talk to MySQL.

Of course, there’s an API server that can take a web request, translate it into an actual database query, and then serve the data. That stack is Python, running off EC2 with MySQL and S3. We knew that if we partitioned the data correctly, we could afford to scale it to millions of API requests.

Any big lessons as you’ve scaled?

When we launched our desktop mail app, we scaled about 20x in 3 weeks, which required rewriting the entire infrastructure layer.

Slow queries became really important because we’re trying to squeeze out every drop of performance for each EC2 instance. Any perturbation across a small fraction of DB queries will create a significant change.

We use a technology called ProxySQL. ProxySQL is a reverse proxy for MySQL that reads queries and directs them to the right machine based on a set of configurable rules.

As we scaled the SQL/query layer, it ended up being the right abstraction for us because the application is so data-driven.

Companies often roll their own ORM, validate data there, and abstract away the database layer entirely. We started doing that at the SQL layer because of performance issues and the need to closely tune our database.

It turned out to be a nice, generic interface for scaling. We’re able to horizontally scale the datastore and we have a clean sharding mechanism. It’s better to find a simple solution that can scale, so you can spend your time building the application and making the product better.

We’ve avoided auto-scaling as long as possible. We have tools to easily add capacity to provision up and down, and configure and reconfigure boxes. Auto-scaling can introduce many non-deterministic issues when something goes wrong with the system. We don’t want to deal with that. We want to know the state of the system immediately.

How did you get started?

We knew developers wanted to create new products on top of email, but the energy required to build on top of it was so huge that nobody did it. Our idea was to build a layer that simplifies email and makes it easy to work with.

We built the first version of our sync system and API and open-sourced it about 2 years ago. We launched that within 6 months of starting the company and originally didn’t have a hosted service. At that point, the company was the developer documentation and the open-source codebase. We were at the top of Hacker News for a couple of days because we tapped into the pain from so many developers who’ve touched the email system.

We spent the next 3 months building the hosted version of the service. Even though the code base is open-source, running it at scale is a challenge. The advantage of starting with open-source is that developers can download the code, start using it immediately, and not have to trust us with their data.

Initially, we had no users and therefore, no feedback loop. We had ideas, but it’s easy to get caught up in ideas without knowing if good decisions are being made. We hired someone to build a variety of apps including virtual clones of the Gmail mobile app, Snapchat, and a Tinder style app that was really email under the hood.

What did you learn from the open-source version of the API?

Our goal was to stress test the concepts behind the API, not just performance or technical implementation. We ended up making many changes to the developer docs and tweaked the abstraction layer based on feedback. It’s dangerous to launch an API with no products already built on top of it.

There are several changes that we made after launching — two of them stand out.

First, one of the goals of the platform was to unify multiple providers into one consistent interface. Our idea was for developers to connect an email account, without worrying if it’s an Exchange mailbox, or a Gmail mailbox, etc. The problem is Gmail is different from other services because it uses labels instead of folders. This created a sticky situation to unify email labels across the different systems.

To solve the problem, we launched with tags. We thought tags were simple because it functioned as a unifying layer, but it was thorny for developers to learn a new term. We deprecated tags after about a year and now expose both folders and labels.

Second, when developers build a product on top of an email box, they want to subscribe to updates. The developer want to trigger some action when a new message comes in or when a thread starts in a user’s mailbox. If developers are building anything for the end-user visible part of the product, these updates need to be real-time.

We built something called the delta endpoint to expose list of changes. This was a streaming endpoint that sent JSON objects to describe changes to the data. This was powerful, but it didn’t match the expectations that today’s developers have for building systems. Most developers hadn’t worked with such a real-time streaming data-source in their applications.

Eventually, we built a system to send webhooks instead of streaming. This was one of the top requested features and really accelerated the growth of the platform.

How does Nylas make money?

Right now, the company has two paid products: Nylas Mail and Nylas Cloud API. Nylas Mail is something that is still in the R&D phase. We make the majority of our revenue through our API business.

The business dynamic with an API platform is different than selling an end-user product. There is a longer integration and sales timeline, but much lower churn and higher contract values than with traditional infrastructure software.

How do you balance revenue with open-source work?

We’re an open-source company first and we’ve open-sourced the majority of our code. The core pieces of the codebase are publicly available on GitHub.

In terms of making product decisions, oftentimes people misunderstand how an open-source team is structured. We still write the majority of the code that goes into the app. There are many people that contribute smaller changes and build plugins, but we still need full-time engineers to make big improvements.

In many ways, the management of a remote part-time open-source team is much harder than a relatively small team of full-time engineers. When people get active for a while on an open-source project, we’ll try to hire them full-time.

At Nylas, we value the input of the community. We want other people to engage with it. Open-source adds this foundation for transparency and alignment with developers. It creates many discussions that wouldn’t happen otherwise.

If you go to our GitHub project, we have about 800 issues that are currently open, and several thousand that have been closed. The majority of these issues are conversations and ideas that people have for building new capabilities and new power into the email experience.

That level of engagement and depth of conversation has helped us steer product development decisions. We know what people need next because they can share their opinions in public.

What are some applications that people should build with Nylas?

There’s a lot of opportunity in themes. Nylas Mail is built in JavaScript and the actual rendering layer is HTML/CSS. We’ve built this powerful system for extending the interface and changing how things are rendered (e.g. drop shadows, borders, windowing, and positioning).

One thing that we’d love to see built is a neural net on top of email to help users compose messages. Developers can use the amazing data available from mailboxes. For example, analyze the Sent Mail folder and train a model to come up with suggested responses.

Another important app is structured data extraction. Email is the richest, most personal data source that individuals have and that data is completely unstructured. A big step forward would be automatically pull out key pieces of data like travel itineraries or action items.

Many apps would benefit from hyper-personalized direct marketing. Instead of a message being broadcast to everyone, customers can talk directly with a reps on the marketing team. This facilitates a higher-fidelity relationship.

Previously, if someone spent $20,000 at Nordstrom, they would probably get a concierge service, but we want to enable apps that allow any business to offer this service at scale. Imagine using a customer’s inbox to send them recommendations for hair and clothing styles.

We provide tools for communication, like a connective fabric for workplace apps. Email and calendar is evolving away from a single product (Outlook) to being a feature of all products at work. Nylas is powering that transition for hundreds of apps.