Sam Breed

Product Developer, Investor

What is Front End Infrastructure?

Unpacking the evolution of web app devlopment

First posted on

Last updated on

Note: This was an unpublished drafted from October 2020 that I wrote as I was winding down my role at Credit Karma. Part of the motivation for building this wiki was to get incomplete thoughts like these into a space where they can grow.

I was recently asked to give an overview of “Front End Infrastructure” for someone trying to navigate the industry. After giving my typically rambling-but-accurate impromptu answer, I reflected a bit about how to define this pocket of technology that I’ve been operating in professionally for the last ten years.

To start, both “front end” and “infrastructure” are loaded terms.

Table of Contents


Front end” conjures up whatever comprises the UI layer of an application, be it a website or a native app. In a large organization, it is maintained by specialists who conjure up the right incantations for each platform. Platforms are important, and today there are 3 to care about: the web, iOS, and Android.

Infrastructure” is the “thing” that runs the piece of software which you don’t have to care about. It is the layer of abstraction in the software stack that is manged for you. It could be a group of servers in a network, or a VM instance running on server, or a pod in a Kubernetes cluster, or serverless function behind an API gateway. Infrastructure is the boundary between what you need to know about to build an application and what you don’t. Everything responsible for running your code that you don’t need to worry about counts as infrastructure. It is prebuilt and generic; fit for myriad use cases, one if which is yours.


Front End Infrastructure” can cover:

You only need to consider a fraction of this list if you only have a one front end app. But when you start needing different categories of front end apps (admin tools, marketing sites / blogs, native webviews, SPA’s, etc), you’ll definitely encounter all of the above.


Here’s a big, dumb list of questions you might be forced to think about at some point:

With one app, lots of these are a single decision point. But with many apps, decisions will get re-made with divergent outcomes, leading to a patchwork of incompatibilities and inefficiencies. Even worse, a wrong turn at the highest level can represent years of technical debt.

The decisions get more important as the size and scope of your front end grows, with compounding effects on three axes:  developer productivity, performance, and reliability.

Developer productivity




Thankfully, most of these concerns are covered quite well by the current crop of “last mile” hosting services like Vercel, Netlify, or and meta frameworks like Next.js, Remix, and Sveltekit.

But the list above can’t be addressed by a framework alone, even if it does come with sensible defaults. CSP is a good example of a gap in coverage from the major frameworks, where inevitably CSP needs to be handled with some level of custom code. When security moves away from being declarative and into something that defined at runtime for each route or class, your surface area for bugs and attacks gets a lot bigger.