# Efficient Front-end Development at Coursera

7 November 2014

As a front-end developer, you find yourself mucking around in the browser. A lot. Whether its ironing out interaction flows, figuring out transition durations, or making sure your API calls are valid, the browser is your battleground; anything that takes you out of that is a distraction.

As such, I took a look at what it might look like to develop on the Coursera front-end without having our hefty virtual machine running… and made some really interesting revelations about the impact of being able to do so.

## How I did it.

With my virtual machine turned off, I needed a solution to two things:

1. Something to serve our static assets (HTML, JavaScript, and CSS) to the browser.
2. Something to proxy our API requests to get the data we needed to construct the client-side application (class information, user models, that sort of stuff).

Without the webserver that our virtual machine normally hosts, we turned to the lightweight Express.JS to serve all our compiled assets. Express proved to be extremely easy to set up, and I was able to get our static assets properly hosted at localhost:9000/static in no time at all. One down, one to go.

The second problem was a little more cumbersome. I needed a fast, efficient way to resolve our API requests with the data required to construct our single page application, which could include things like course information and student information. I didn’t want to have to burden developers with having to generate this data, so I took a look at our existing data sources for ways to construct the application. We came up with two different ways to address this problem, depending on our development needs.

For our first approach, we found a solution that worked well if you just wanted to see the UI and quickly iterate on the frontend. As part of our testing suite, we generate mock data in order to simulate models that had already come back from the server. Since we use Require.JS, we were able to take advantage of the map config in order to reroute requests for data to the mocks that we had generated for testing. And because we test almost everything, it was incredibly easy to map our data resources to the mock data. This worked really well, and in conjunction with the Express.JS server we had a complete solution to the problem of running Coursera without a virtual machine.

For our second approach, we realized we had an existing service powering all the APIs we wanted: our staging servers. Thus, we enabled a proxy between our Express.JS web server and staging instances of Coursera. This allowed us to continue running the front-end on our local machines but use backends running on beefier servers. This solution allows us to iterate on the front-end quickly while still having the persistent data we need for the full interaction flows that our product supports.

## Revelations

After doing this process, I realized a couple of important things that I hadn’t really envisioned from the outset, added benefits to being able to develop against a lightweight server.

1. Validate mock data

We create a lot of mock data to get proper test coverage for all of our client-side code, but you can imagine that in the pursuit of those green checks, some data falls through the cracks. Some of the mock data had essential fields omitted, some data was too expansive, and some was just plain wrong. Being able to construct the entire application in the browser, just like a client would, makes sure that our test data is actually worth using in our test suites.

2. Increase battery life

Don’t discount this one; no one gets bothered more by a hot (or dead) laptop than a developer in the zone. Virtual machines are usually the culprits when it comes to shorter than normal battery life, the absence of which means we can work where we want, in the places we are most productive.

## The Future of Front-end Development

As front-end developers, we should focus on the front-end. Courser.JS gives us the ability to do just that, making our front-end development process faster and more efficient. But being able to run our applications more easily also greatly lowers the barrier of entry when it comes to contributing to front-end code; think about the technical designers and marketers who want to get down and dirty in the code and want to see how the application looks and feels without having to figure out all the odds and ends of a virtual machine. Running front-ends without backends allows us to focus on the work we’re doing, in the medium that it runs in, in the most efficient way possible.

Product Engineering