Week 6: Deployment

What is deployment?

Deployment is the process of publishing your code on a server so that it becomes accessible over the internet. If you develop a project, your computer can act as a server, but all user interaction might be locally limited. Production-level applications are all deployed on servers, enabling multiple users to access and interact with them.

How do servers (briefly) work?

Recalling back to our discussion on clients and servers in week 4, clients send requests to servers for data, and servers process these requests and send back data in the form of a response.

Formally, a server is a specialized computer that can accept requests made by clients across a network.

Servers are linked to a network via IP addresses. IP addresses are unique identifiers (similar to a home address), allowing distinction between servers. This IP address is where data packets are sent (from the client's requests). Learn more about IP addresses here (opens in a new tab).

From a client perspective, using IP addresses to access a server is impractical, since IP addresses are long alphanumeric sequences. This is where the Domain Name System (DNS) comes in. Domain names (such as acmucsd.com or apple.com) are much more human readable, and are mapped to IP addresses through the DNS. When a user enters a domain name into their client, a DNS resolution request is sent to a DNS resolver to find the corresponding IP address, to access the data in question (in our case, the user interface of apple.com).

Deploying a front-end with Vercel

Vercel (opens in a new tab) is a popular platform for deploying front-end interfaces and serverless applications–particularly those written with Next.js. A alternative option might be Netlify, but this guide will demonstrate the use of Vercel.

You can create an account with Vercel (use your GitHub to link all your existing repositories). You should now have the option of importing a project.

Next, you can configure certain settings. For example, if you have both a client and server directory in your repository, you'll want to change the Root Directory to point to the one with front-end code. You can also specify any build commands or environment variables at this stage.

If you want to change these settings later on, they can be found under the specific project settings page.

Finally, deploy your project! You should see this interface, where you can view active branches, the status, logs, and more.

Deploying a back-end with Render

After deploying your front-end, you'll also need to deploy your API. You could run it on your personal computer, but once your app begins to scale, your computer's hardware may not be adequate enough to handle the incoming load. When you use a service (we'll be using Render (opens in a new tab)), you can generally specify the computing capabilities of your server. More powerful configurations will scale up in price.

To get started with Render (opens in a new tab), create a new web service (opens in a new tab). Link it to the correct GitHub repository and give it an appropriate name. You can adjust configurations here, such as the branch you want to deploy from, runtime environment (e.g. Node, Python3), root directory (perhaps a server directory), and build commands (like using npm start or yarn dev to start your server).

Pro Tip: You can set up automatic deployments on pushes to the corresponding branch, removing the need to manually deploy every time you make a change!

Once this is specified, select an instance type. For small projects, the Free tier is more than enough. If you expect your app to scale, you may want to research how much compute your app needs!

Finally, add environment variables and adjust any other configurations you need.

What's next?

Congratulations––your application should now be accessible to users on the Internet! This is a great first step to building web applications.

In the future, you may want to consider scalability. Once your app starts gaining users and experiencing higher levels of stress, it might be time to include components such as load balancers. If your application continues to grow to support more functionality, it might be worth considering splitting your architecture into microservices. Each of these approaches have their own considerations, so make sure to do some research!