HomeEventsAboutGet Involved

AppCues' Serverless Stack

Appcues’ Serverless Stack

The first line of Appcues code was written in late-December 2013, amid the heyday of javascript’s renaissance. As a frontend engineer, I’ve always dreamed of a single language, no backend setup that let me build things quickly, and Appcues was the perfect chance to try it.

Our Stack

Here’s what we ended up with:

  • Brunch for the static build process.
  • Firebase for the database + API.
  • Keen for analytics and reporting.
  • Divshot.io for hosting (previously on Github Pages).
  • Wercker for continuous integration.

We also use a lot of compiled languages, mainly because of the productivity gains they offer. Currently, the languages we use are CoffeeScript, Sass and Jade. If you dug into our repo, you’d see stuff that looks something like this:

Quick Overview of Appcues

Appcues is a third-party service that lets product marketers design and publish in-app tutorials without code. Our platform helps hundreds of thousands of people learn how to use software every day.

Tech Stack Goals

When researching the best stack for Appcues, I kept these goals in mind:

Goal #1 was to have no middle layer, not even a node server. Middle layers are great for processing data, but they also require more overhead. That’s more code, more servers, mo’ problems.

Goal #2 was to find something incredibly cost efficient. I wanted us to get to 100 customers before paying anything and without losing performance.

Lastly, goal #3 was to have an efficient workflow. I wanted to focus on writing code and nothing else. If that sounds familiar, it’s because HubSpot has a similar setup. I simply set out to emulate the best parts.

These goals helped me come up with the no backend stack we have today.

The Advantages

Overall, our no backend setup has paid off significantly. We’ve been able to build a scalable software company with only ¾ of a javascript developer (I have other responsibilities too) and $0. By writing straight to the database, we’re able to cut out a huge amount of engineering overhead without compromising on performance.

Firebase and Keen have pretty generous free plans, and we were able to bring on several hundred users before paying for either service. It really let us test those services and made sticking with them an easy choice. Tools like Brunch, Divshot and Wercker let us focus on just writing code instead of fiddling with our own custom tooling.

The Disadvantages

The main disadvantage of outsourcing our backend to Keen and Firebase is that we have far less control over it. We have limited insight into our performance and aren’t able to run low-level operations. In addition, we had to adopt each vendor’s recommended schema and be very conscious about how we structured data.

Ultimately, we were OK giving up that level of control and were bolstered by Firebase’s SLA guarantee and Keen’s track record. Plus, the gains in productivity far outweighed the lack of control.

No Backend In Practice

The two core pieces of our system, a Backbone app and our SDK, talk directly to Firebase APIs and render tailored content to their users in under 200ms. When users interact with that content, we store those events in Keen.

This architecture has scaled really nicely. We’re doing about 100 req/sec and currently manage how more than 350,000 people use products like HubSpot, Nanigans and Wistia—all without a single line of server-side code. As it is today, the system can easily double its load without incurring any extra costs or code changes.

Like our stack, our development workflow is optimized for speed. Every commit is automatically built and tested in Wercker, and everything in the master branch is instantly deployed to development and staging for review before going to production. This lets us safely ship code every day, often several times a day, to hundreds of thousands of people.

The Future: Servers (Reluctantly)

As we grow, both in scale and a team, we’ll start taking ownership over more of these outsourced systems. We want to do more advanced reporting, store even more data, and do asynchronous processing on the data we currently have. All of those things will require servers.

We’re already beginning to put layers between and around our current stack. Serverless or not, we always prefer finding the clever solution instead of the settling for the “standard” choice.

Advice for Entrepreneurs

If you’re starting your own company, using a BaaS platform like Firebase can really help you get an MVP quickly. If it makes sense for your business, put more thought into your setup and configure your system for scale from the beginning.

By using Firebase, we were able to build the first paid version of Appcues in three weeks and start signing customers right away. Out of the box, we had a fast, real-time, collaborative platform that looked great, and that gave us a competitive edge. Plus, it literally cost us nothing.