Scaling On The Cheap

ayasin
ayasin
Oct 20, 2015 · 7 min read
Image for post
Image for post

“Planning is bringing the future into the present so you can do something about it now” — Alan Lakein

I’m going to take a break from my Tech Hiring and Team Building series to write a more technical article.

I co-founded a company. We had no investors. We weren’t looking for investors. Ideas are cheap, and valuations on ideas are cheaper. What we had was an idea and a need to keep our servers up on a shoestring budget. This article is the first in a series of how we did that and how you can too.

Start on the right track

“It does not take much strength to do things, but it requires a great deal of strength to decide what to do” — Elbert Hubbard

When you start something new, there’s nothing bad, no cruft, nothing you need to explain away or be embarrassed about. On the other side there are so many possibilities it can be overwhelming. It’s a time when you make decisions that can either pay massive dividends or cause a systemic failure that’s basically unrecoverable without redoing everything. This is where you need to start thinking about scale. This doesn’t mean prematurely optimizing the login flow, or buying a huge server. It means thinking about architecture in a way that let’s you avoid future pain at little upfront cost. That said, you can follow this advice at any time. Maybe it can help, maybe you’re too far down another path, that’s up to you to decide.

The first commandment

Our server has 2 parts: the static side and the API side. It’s worth considering keeping these in 2 separate repos (that way they CAN’T mix).

It’s worth noting that “on an individual request basis” does give you a bit of flexibility. It’s totally ok, and often preferable, to render your static html from templates at build time. This allows you to avoid repeating common snippets like headers and footers, analytics code, etc.

The static site

The API server

Out of the dark ages

A million render engines

Once the JSON payload comes back from our server, we cache and render that on the client. It’s important to note here that our app is a single page app (SPA). Though you don’t have to do a SPA to use this technique, if you need multiple pages that need to access the same data (or you need to support rapid back and forward button navigation without abusing your server), you can cache your JSON responses in localstorage (unless you need to support IE 6 or something, in which case you need to be looking for another job not reading this blog post).

Collecting dividends

Duplication of code is significantly reduced.

The more painful it is to do the wrong thing, the more likely we are to do the right thing

When we’re writing pages that get generated on the server you may find that some bits of code that do basically the same thing get sprinkled all over the place. This isn’t through any coding malpractice, it just happens because people are in a hurry and assume something isn’t already done elsewhere. The API layer reduces this because creating an API has a much higher “activation energy” (the amount of energy it takes to get started doing something). Before we go to add a new API (having to come up with a name, add the boilerplate, properly categorize it, etc) we’re very likely to see if an existing one works for us.

Everything is a first class citizen

Mobile app first? Web first? Neither. Everything first.

Because we’re not directly accessing our backend while rendering our website, anything our web client can do, our mobile client now also has access to! Additionally if we’ve designed our API with some care (sadly, a topic beyond the scope of this post), we can even easily bring on 3rd party partners with whom we may share data.

Reduced attack surface

Because we’re eliminating a sizable chunk of code (template, embedded HTML, HTML generation engine, whatever) on the backend, we reduce the ways in which it can be attacked. It’s easy to ensure that each new API validates its inputs, because these don’t get added that often, and because they tend to be pretty small relative to an entire page render with lots of embedded HTML, etc. Additionally if some strange bit of data causes the render to crash, this happens in 1 browser rather than affecting lots of otherwise unaffected clients.

Your CDN can do its thing

Image for post
Image for post

Here’s one of our actual traffic spikes. The orange is the traffic our CDN serving from its cache, the blue is what we served from our web server. That difference is about 100K requests. That’s 100K requests that required no server resources from us.

You’re probably never going to be better at serving pages than your CDN. If you are, you’re either a multi-billion dollar company, or you need to get a new CDN. Because all your pages are now static, your CDN can provide DDoS protection and absorb the load when you’re getting hammered. This also means you’ll save money because you need a less beefy box. If you notice abuse of your API server, you have more options. Just as an example, you can temporarily add a slight delay to responses. Nothing a user would notice (perhaps 50–100 ms), but something that will slow the attacker down significantly while costing you next to nothing (assuming you process your requests in a non-blocking manner). This is possible because a legitimate user isn’t looking at a blank page while you’re dealing with malicious actors. They’re seeing a partial page which, at the very least, is letting them know you’re loading their request. Your CDN may even be able to cache some of your API responses short term.

So what’s next?

About Me

If you enjoyed this post, I’d really appreciate a recommend (just click the heart below).

Image for post
Image for post

Published in #SWLH (Startups, Wanderlust, and Life Hacking)

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

The Startup

Medium's largest active publication, followed by +752K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store