Working on OkCupid "in production" with Webpack and localhost
Let's be honest: you should probably be working now. If you're anything like us from a year ago, you ended up here while waiting for your dev machine to start up, or for Webpack to build files for you to try out.
For me, waiting a mere five extra seconds for a page load was enough to push me to Hacker News "for just a minute." Then, 20 minutes later, I had forgotten what the hell I was doing.
Here's how our frontend dev environment is set up now, which has made development more responsive, more accessible, and more fun to work with.
How we worked a year ago
When you visit an OkCupid URL, the OkCupid web server (
okws) generates HTML and sends it to you over the internet.
Each dev has a local machine running a development build of
okws runs on Linux, and the templating files need to be in the same directory as the
okws files. That means each frontend engineer on a Mac (read: all of us) needed a separate development machine on the same network.
- A developer connects to their dev machine through AFP, which mounts the
- They cd to that directory.
- They start the Webpack watcher.
- Webpack reads in the source files over the network.
- Webpack saves the compiled files to the right directory on the dev machine.
Every file we compiled (including all dependencies in
node_modules) had to make a cross-office trip from our dev machines to our local computers.
Sometimes, if you refreshed the page before Webpack finished compiling, you'd have to refresh the page again to see your changes. Refreshing a page twice to see your changes in 2015 is only slightly more advanced than getting it faxed to you.
How we work now
There were two root problems with our old setup:
- Storing source files on our dev machine means a lot of network round-trips during compiles.
- Webpack only compiles files. We have to (gasp!) manually reload pages.
The first problem was "easy" to fix. it didn't matter where our source files were, since
okfrontend, cloned on our Macs.
The second point wasn't a problem, per se; it was just something we shouldn't have to deal with. I would enviously read articles about other teams using webpack-dev-server to locally-build their single-page apps.
If you've never used webpack-dev-server, it's a miracle: it keeps file references in memory, so your rebuilds are faster; it reloads the page for you on changes; and if you change CSS or React components, it'll reload those assets without even reloading the page.
At first, I thought webpack-dev-server would only work for single-page apps: it serves up a single static HTML file that points to your compiled JS files. But those compiled JS files have URLs just like anything else. There's no reason we couldn't point our servers to those URLs.
Then, we used webpack-dev-server to compile serve those files from localhost.
Since we weren't making those round-trips over AFP anymore, our initial build times cut in half (from 90 seconds to 45 seconds). Not perfect, but much better than before.
An unexpected side effect of this setup was that developers could now work from anywhere in the world, without even needing a VPN connection. As long as they had staff credentials and a local checkout of
okfrontend, they could start up Webpack and instantly see their changes. And they could do it on the live site!
- Build times went from "interminable" to "still long, but better."
- Working out of the office went from "absolute torture" to "a pleasure from the start".
If you want to help us fix problems like this, we're hiring Senior Frontend Engineers! And if you don't, feel free to send us your feedback or ideas!
Thanks to Melissa Huang, Jessie Walker, Michael Geraci, Dale Markowitz, and Ben Brittain for giving notes on this post.