When it comes to application deployment, there are a myriad of tools that can be explored and leveraged. With a field as non-static as software development and deployment, however, it is vital to consistently survey the tools on the market to optimize your projects.
Perhaps one of the most potent and swift tools to use in website deployment currently is Vercel
Vercel totes a multitude of benefits such as free domain names, automatic deployments, a marketplace, serverless functions, and the ability to connect teams. In my opinion, it is one of the easiest and non-taxing platforms to deploy a website.
As adumbrated by medium.com,
By connecting the GitHub repository in the Vercel you can simply deploy the master or main branch to the Vercel domains.
Functions as a Service Architecture
What exactly is meant by functions as a service architecture? Searchitoperations explains it quite well.
Function as a service (FaaS) is a cloud computing model that enables cloud customers to develop applications and deploy functionalities and only be charged when the functionality executes. FaaS is often used to deploy microservices and may also be referred to as serverless computing.
Essentially, in layman's terms, the functions as a service architecture is a format in which you can create an application that enables you to sell its individual functions.
When leveraging the function as a service architecture, developers do not have to worry about things such as server allocation and backend services. This is because the serverless provider takes care of all these extra tasks. Thus, all you have to do is write the code for your application and you can let Vercel handle the rest.
There are numerous other pros to using this architecture as well. They are outlined by CloudFlare as follows:
Improved developer velocity
With FaaS, developers can spend more time writing application logic and less time worrying about servers and deploys. This typically means a much faster development turnaround.Built-in scalability
Since FaaS code is inherently scalable, developers don’t have to worry about creating contingencies for high traffic or heavy use. The serverless provider will handle all of the scaling concerns.Cost efficiency
Unlike traditional cloud providers, serverless FaaS providers do not charge their clients for idle computation time. Because of this, clients only pay for as much computation time as they use, and do not need to waste money over-provisioning cloud resources.
Thus, now you may start to get an understanding of why microservice software engineering is so vital to learn currently. With architectures such as function as a service lowering the amount of resources that must be consumed, it is a no brainer that companies are enticed by this advent. After all, who wouldn't want to save money and lower the stress on developers at the same time?
Specific Development Challenges that can be solved with leveraging this architecture is outlined quite well by Michael Potter of Redhat.
- Limited deployments: Monoliths, not always but typically, opt for long sprints between deployments. This reduces the risk of new features introducing regressions to its extensive feature set but makes it more difficult for teams to plan and launch new features.
- Feature collision: Every feature in one bucket sometimes introduces regressions to other functionality (you'd be surprised how often this happens). This is why core teams try to limit the number of new features they introduce concurrently.
- Limited technology stack: With monoliths, you have to work with the available tools. Integrating new technologies within the monolith is often a significant lift. Also, introducing new technology to the monolith means more responsibility for the team dedicated to ensuring uptime.
- Ownership: When you have large teams supporting a monolith, the responsibility for a feature may bounce from one developer to another. This sounds good on the surface but often leads to developers having to maintain product features they aren't entirely familiar with.
Getting started with Vercel
Before we go ahead, you can view my live vercel demo.
To demonstrate how to get started with Vercel, we are first going to be working with it locally and then we will go over how to deploy your own repository. In particular, pay attention to the contrasts between Vercel and GitHub and how relaxed the deployment functions.
To start, clone this repository to your computer.
CD into your cloned repository and run vercel dev
Open the repo in vscode and make a file called .env in the root. Add this to the contents of the file.
This is an "environmental variable" file. This is a common thing on these sorts of service to keep security sensitive variables out of version control.
Once you are done, save and then run npm install. Next, we are going to run the following command: vercel dev
This should build your site in a local host
Thats it! It is very simply to deploy.
What exactly is vercel dev? The vercel website explains it quite well.
Single-Command Local Development
Typically, developing a website or application involves a series of steps:
- Cloning repositories
- Fetching packages
- Synchronizing and matching ports
- Downloading the right runtime for each programming language > And so on... >Even for modern projects, we often need to look up the README.md file for instructions about installing dependencies, and then tell a package manager to run developer scripts.
Vercel gives you a different contract. It is always Vercel dev.
Running the command "Vercel dev" will build your application swiftly and with ease.
Deploying publicly
Before we start, you can look at my public Vercel repo of the demo we just worked on.
Head over to vercel.com and get your GitHub account connected.
Go to your dashboard. Select new project
Import the repo that you want to deploy. Adjust the build settings if needed. My project builds out of a folder named "public" so I needed to let Vercel know.
Now select deploy and your site should be running!
**Here is one of my 11ty sites deployed on Vercel and GitHub Pages.
_Vercel was 100x time easier than getting the GitHub pages to function correctly. _
There are other CD/CI pipelines on the market that can be used as well. For instance, services such as monorepo enable you to easily generate a version controlled repo that contains a lot of projects. However, Vercel is in my opinion better than this service as monorepo often contains logically independent projects that have to be run by different teams/organizations. As stated by semaphoreci.com,
Doing CI/CD with a monorepo is a challenge. By default, every code change would launch a pipeline that would build, test, and deploy every single project included in the monorepo. This is time-wasting, costly, and a risky.
How Shoelace uses Vercel to deploy builds per branch
Now we are going to be looking at how Shoelace leverages Vercel to deploy builds per branch.
Start by cloning this repo and then getting it linked to your Vercel account. Follow the same procedure aforementioned.
Note that shoelace is building out of dist
In Vercel, the main branch should essentially be perceived as the production. Every time a pull or merge request is made to a specific branch, Vercel generates a unique deployment. This enables a developer to view these changes in a previewed environment before merging this with the rest of your branches. Now it may start to become clear why shoelace leveraged Vercel in particular, as it enables this large stack of components (see image below) to be deployed and previewed in specific/separate branches.
Shoelace also configures Vercel directly by leveraging the vercel.json file. This file as stated by vercel,
The vercel.json configuration file lets you configure, and override the default behavior of Vercel from within your project. This includes settings for:
cleanUrls
trailingSlash
redirects
rewrites
headers
You can find my other 11ty deployments with vercel here:
It is clear that microservice architecture is the future and Vercel is certainly playing a role in this revolution. Thanks for reading my post!
Top comments (0)