How to Deploy a Full-Stack App to the Web

Software Development Aug 31, 2020

So, you have developed a fancy full-stack app you are proud of. Now it’s time to make it available to others, but... where do you start? Nowadays, there are many ways to deploy an app to the internet, and it can be overwhelming to analyse and learn each way. Furthermore, some tools are quite difficult to use, while others that are easier to use might not meet our app requirements.

Here, I’ll make a brief comparison between the tools and platforms I’ve used and learnt in the past, along with an explanation of their core features and the type of app which could benefit from them.

Okay, what choices do we have?

There are countless alternatives to everything you can do with a computer, and this isn’t an exception. Indeed, this topic provides enough material to write a book, so I’ll keep it short and sweet. We can classify these deployment options in two big groups: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS).

  • Briefly, PaaS gives you a… well, a platform, where you can deploy your app. By platform I mean a software running on one or more servers on the internet that you can operate and manage via a graphical user interface in your web browser. Most of them are free and easy to use and have good support in the open source community. They also count with premium features you can use by paying a little amount of money, although most of these features are too advanced and unnecessary for most apps.
  • On the other side we have IaaS. To sum it up, while PaaS gives you a piece of the cake, IaaS gives you the whole cake. They provide you with a virtualized infrastructure where to build your application architecture. You have the tools to manage the servers, network (including DNS) and all the stuff like if you own them. Now that I think about it, a better analogy would be that IaaS gives you the milk, eggs and flour, so you can make a cake if you want to.

As you can imagine, IaaS is a more powerful alternative, but a more difficult and expensive one too. Also, most projects will do fine with PasS, so I’ll centre my efforts on explaining those from now on. Even so, if you are curious about IaaS alternatives, I invite you to take a look at Amazon Web Services, Microsoft Azure or Google Cloud Platform. For personal or small projects a good, easy and cheap IaaS alternative could be Digital Ocean. Check it!

Let’s choose PaaS. Now what?

There are five PaaS providers I’d like to focus on. Those are Netlify, Vercel, Heroku, GitHub pages and Firebase.

Netlify: simple and powerful

Netlify is one of the biggest and most known PaaS providers out there. It’s widely used for lots of projects of any kind. We have used Netlify at Acid Tango in the past to deploy our corporate website, but as we are growing as a company, we want more control over the deployment process, so we have recently moved to an IaaS provider.

Netlify aims to provide an easy and effortless experience to building and deploying sites. The only thing you have to do is to provide Netlify read access to your repo in GitHub, GitLab or Bitbucket, and select the git branch, programming language and command you use to build your site. This is made via a user-friendly web panel that helps avoid mistakes or configuration errors. From now on, every push to the selected branch will make Netlify build and deploy the site.

Sites in Netlify are deployed to a global Content Delivery Network (CDN) for optimum performance and Service Level Agreement (SLA). They provide you a Netlify subdomain to access your site, but you can use a custom domain too if you have one. The most amazing thing with Netlify is that it saves a history of every built version, so you can, at any moment and effortlessly, deploy a past version with just one click. It doesn’t take more than ten seconds. You can preview your site in a draft URL before deploying it.

Everything mentioned above is included in the free plan, but with a monthly subscription, you can get access to Netlify analytics, authentication and other features. Overall, Netlify can suit most app needs.

You can check how easy it is to integrate with your git project in their Get Started guide, with some video examples.

Vercel: the new kid in town

Vercel works similarly to Netlify,but oriented to the JavaScript ecosystem. A git repo from GitHub, GitLab or Bitbucket can be connected with your Vercel account in a guided process. Then just make a git push to the selected branch to deploy changes. You can also set a preview URL to check your site before deploying it.

They also provide Quickstarts, basic site setups and boilerplates to start developing and deploying with Vercel: React, Angular, Vue, Gatsby … are some examples of templates they provide. Vercel is also the company responsible for developing Next.js, a React framework we use here at Acid Tango (indeed we don’t deploy to the Vercel cloud). They obviously provide a template for that framework, too, and because they are products of the same company the integration is really easy. So Vercel could be the appropriate solution if you are developing with Next.js

The main difference between Netlify and Vercel is that, while the first one only allows you to build and deploy static sites, Vercel lets you use Server Side Rendering (SSR) too. Using SSR has three main advantages:

  • First, as the rendering occurs on the server, it is safer for the client computers to load the site, because they don’t execute most of the JavaScript code.
  • Second, as the server does the rendering hard job, it will help low-specs machines to run your site smoothly.
  • And third and most important for business sites and applications, SSR gives you better SEO. As your site is rendered by the server, search engines crawlers can analyse it better. That is because crawlers cannot render JavaScript and therefore, they cannot interpret and inspect JavaScript pages that render on the client.

If you are curious about how it works and how easy it is to integrate with your current repository, here are their official guides for GitHub, GitLab and Bitbucket, with a focus on the deployment and rollback process.

Heroku: computational power

Heroku is a hosting platform where you can deploy not only websites, but web apps, APIs etc. They support many languages (JavaScript, Ruby, Python, PHP…). Like Netlify and Vercel, it has git integration, with the aim of making the process easy and painless.

The main difference between Heroku and the two above is that, instead of providing you a transparent hosting service that works out of the box, Heroku gives you computational power. What does that mean? Heroku offers an amount of RAM and a number of concurrent processes for your application, to be run in a containerized environment that they call dynos. They also provide other different services like relational databases. You might be thinking that this business model appears more like the IaaS approach, but that’s not entirely the case as you can’t get low level access to the infrastructure behind. Not a ssh connection into your dyno nor a terminal to access it.

Something to consider is that free dynos stop after half an hour of inactivity, and they go into a kind of sleep mode. As you can imagine, if the dyno is sleeping and gets a request, it first must boot up before serving it, so the first request will take a bit longer. Because of this “restriction” it might not fit the needs of all apps, but it does a good job if the project you are deploying is a non-real-time API or other app type in which eventual longer response times don't make any difference.

If you want to check dynos specs and features, take a look at the Heroku Dynos page.

GitHub Pages: basic hosting for basic sites

The easiest one. You should consider this if your site is fully static and its repo is hosted on GitHub. To enable it, just go to the repository settings (general tab), select a branch to deploy and set it. Once enabled, the branch selected will be served as static files over https.

GitHub pages are so simple that it only allows you to deploy static files and set a custom domain, but it’s a very easy alternative if you just want to promote yourself with a simple static portfolio, or if you want to host your GitHub project documentation. Also, you have the confidence of knowing that GitHub servers aim for the best SLA possible.

Starting with GitHub pages is easy, as you can see in their official guide.

Firebase: all the Google’s power

If GitHub is the easiest and simplest way to go, Firebase is on the opposite side. It doesn’t provide out-of-the-box git integrations, but its features are many and full of possibilities. They provide hosting, non-relational databases, analytics, user authentication, forms, mobile push notifications and so much more. I know that here, at Acid Tango, we have used it in some projects, but I have never used it professionally, only for personal side projects.

Firebase is more a set of tools rather than just another hosting platform. It’s a product of Google, so you can expect the same kind of UX you get on every Google web app (like Gmail, Drive, Docs ...) while using the admin panel. Also, as a Google product, it has a great integration with Google Analytics, Android, and the JavaScript framework Angular, but besides that it works with every web app (not matter the technology behind) or even iOS apps too.

The Firebase feature I like the most is its Realtime Database, and its newer version, Cloud Firestore. Firebase provides these non-SQL databases to be used by your app. If you use the official JavaScript library to interact with them, you can subscribe to changes on the databases using Observable from RxJS, so every change in the databases will be reflected in milliseconds in your app interface. This model based on subscriptions works very well for other features, such as users' authentication.

If you want to see the Firebase potential applied to real projects, take a look at the Firebase uses cases page. If you prefer to see their products instead, you should visit their products page.

Let's wrap all this up: what is the right choice for my project?

At this moment I’m getting out of coffee, so I’ll be brief. The best choice is up to you. You know better than anyone what your application does and what it needs. I hope the information I provide in this post helps you draw your own conclusions and make an informed decision. If you still have doubts or don’t know what deployment system fits better for your needs, that is what I would do:

  • If you expect your app to grow fast and you think it will need some scalability or custom infrastructure architectures, forget about these options and go for an IaaS instead.
  • If you just want a place to deploy your static site for easy access and maintenance, and if you use GitHub as your git repository, go for GitHub pages.
  • If you have a more computation-oriented application instead of a website or web app, and if you don’t care that your app goes to sleep after a period of inactivity, give Heroku a try.
  • If you want to deploy your website or web app in a reliable and well documented platform, with the ability to add add-ons if you need them, go for Netlify for static sites. Go for Vercel if you are developing with Next.JS or implementing SSR.
  • Finally, if you are developing a mobile or multi-platform app and just need a backend service, if you need some utils to integrate authentication or real-time databases into your project, or just want to play around with the bunch of features Firebase provides for free, try it. I bet you have a Google (a Gmail) account. If the answer is yes, you already have a Firebase account.

Bonus: setting deployment secrets

Sometimes, your application needs some configuration that you provide via environment variables. These configurations, occasionally, include sensitive data such as API keys or passwords that cannot be written to the code and must be provided in runtime. Those are called secrets.

Secrets management is easy in all the platforms I described. Both Netlify, Vercel and Heroku allow adding secrets directly via their admin dashboard. Firebase allows setting secrets via their Firebase functions. Finally, secrets on GitHub Pages make no sense since only static files are served (there is no runtime).

Aitor Alonso

Computer Science Engineer. Full Stack Developer at @acidtango. Python, Node.js, TypeScript, React. DevOps soul.