What does Vercel do?

Vercel builds a frontend-as-a-service product—they make it easy for engineers to deploy and run the user facing parts of their applications.

• Applications have two parts: the frontend and the backend (have I mentioned this before???)
• The frontend is usually deployed with the backend on a single server (or set of servers), which means infrastructure to set up and manage
• Vercel lets teams deploy their frontend stupidly easily, separately from their backend
• Deploying with Vercel gives you nice features like deploy previews, functions as a service, analytics, and more
• Beyond just the frontend, Vercel has been adding cloud-like features like storage and databases

While how you deployed your frontend was nobody’s business a few years ago, tools like Vercel are now (maybe?) the standard for how teams get their frontends up on the web. The Technically website is even built with Vercel!

You may notice unusual enthusiasm for this product from me in this post, but it is not sponsored—I’ve just been using the product for years and really like it.

What does deploying mean? Why do I need to do it with my frontend?

The frontend of your application is the part that your users see. But it’s actually a bit more than that. Your typical frontend codebase does a bunch of things:

• Builds the visual element of what you’re seeing on a web page, with HTML and CSS
• Handles interactivity and animations via JavaScript
• Makes calls to internal and external APIs to fill pages with data (like a user profile page)

Frontends are usually organized as a series of files representing which pages exist, what their structure is, and accompanying JavaScript for handling interactivity, logic, and API calls. We’ve used the analogy of the front of the house (yes, chef) vs. the back of the house, and this sort of works. The FOH is the customer’s interface to the back, making sure orders get to the kitchen, the right food gets back to the customer, etc. 

Deeper look

Some engineering teams stick to what’s called a monorepo, where all of the application code—the entire frontend and backend—are all in one giant repository, i.e. one master folder. Others have separate repositories for the frontend and backend, and others yet several repositories for different parts of the backend. Which setup teams choose depend on their priorities and how complex their application is.  

Deeper look

However you want to understand the frontend, the important takeaway here is that the frontend code needs to sit somewhere. Developers build the frontend on their laptop and need to put it up on a server somewhere so users on the web can access it. So how do they do that? There are a few options:

1. Put it up on a dedicated server, separate from your backend
2. Put it up on the same server as your backend
3. Put it up (with or without your backend) on a PaaS like Heroku, Railway, Render, etc.

All of these options require a good deal of setup and configuration. The basic requirements include setting up authentication / networking to your local setup and (possibly) the backend server(s), caching your frontend across the world so it’s close to your users, handling DNS so you can have a nice URL to access, and plenty of fun other stuff. I’m not trying to scare you here with terms or concepts you don’t know, there’s just a lot to do.

Vercel, and products like it, are specifically built for deploying frontends and making all of the above work as easy as possible.

The basic Vercel product

Vercel makes it as easy as possible to deploy and use your frontend. Like any software project, I have my frontend code for technically.dev in a GitHub repository. All I need to do to get it up and running on the web is create a Vercel account, give it permissions to my technically.dev repository, and configure the domain name. Boom, your site is live: