Deploying an AngularJS App?Posted by Itay Herskovits on Mar 30, 2015
Once you’ve finished developing your web application (or even before, if you have something you want to show off), you’ll need to deploy the project onto a web server that can be seen by others outside your local environment. While as recently as 5 years ago this was often handled in-house by a dedicated DevOps team, services such as Amazon AWS and Heroku allow you to outsource this portion of the technology stack. Additionally, if you don’t need an interactive server component to your application, you can make use of additional services like Docker. Below we’ll cover some of the decisions you’ll face during deployment, and provide some guidelines on choosing the right service for your application.
Static or Dynamic?
One of the first questions you’ll need to answer when researching deployment options is whether your application is static or dynamic. Each type of website has different needs, and as such not all deployment solutions may work for a given web application. Below we will look at the terms static and dynamic as they pertain to web development, and provide guidelines for determining which category your site falls in to.
A static website, despite the name, does not mean that the website content does not change. In this sense, a static website is any kind of website that can run on top of an unmodified server. In essence, if your client-side application code never calls back to your server (within certain limits), then you can really deploy on any platform that offers hosting. It is the activity on an application’s server that makes it static – the front end code can be dynamic and communicate with any number of services, but so long as it does not perform any complex work on your web server itself then your web app can be considered static. Some examples of this type of web application are a simple personal home page, an online games portal that doesn’t save data to the server on which it is hosted, or an AngularJS app that performs multiple calls to a RESTful API provided by another service.
Using Grunt to Create a Deployment
If you followed the advice in our article on seed projects, odds are a build-and-deployment system have already been installed on your development machine. Most of these seed applications use Grunt, which is a task runner that allows you to automate all of the common functionality associated with building, testing, and deploying a project. Grunt is built off of a grunt file, which defines the automatable tasks in your application (see a sample grunt file here). Once you have Grunt set up correctly, building a distribution for your Angular application can be as simple as typing “grunt build” from the command line.
Choosing a Hosting Provider
Once you’ve determined whether or not your web application is dynamic or static and developed an associated deployment file via Grunt (or some other service), you finally need to choose a web hosting provider. There are a number of options available that offer a wide array of services for website hosting – from hosting solutions as simple as 1and1.com or GoDaddy.com to full-blown server deployments with associated data centers. With static web applications, a simpler service is all that is necessary – you don’t need a heavyweight server to provide content, nor a database to interact with your application in any significant way – but with dynamic web apps you need to choose a provider that can handle both serving the content and processing the responses from your application. Below we will look at three of these providers – Docker, Heroku, and AWS – which are typically used for dynamic web applications.
Docker is a relatively new web deployment platform, with official version 1.0 being released in June of 2014. Docker is a container-based system. In essence, it abstracts the concept of a virtual machine (an emulated computer running within another computer) into a series of “containers” running on top of an operating system. Each of these containers performs the same functions as a virtual machine, but share resources of the underlying OS. This approach allows for a smaller footprint for each container, but it does introduce restrictions – all containers running on a Docker instance, for example, must share the same type of operating system. If your web application’s architecture is one or more VMs using the same basic OS functionality, Docker might be a worthwhile solution.
Heroku is a cloud-based scalable server that, if you are willing to adopt certain conventions in your application, provides a server solution that allows you to focus on your application’s code rather than infrastructure considerations. In essence, it abstracts away the operating system (by preventing file handling) and database scaling considerations (by enforcing Postgres as a standard), and allows you to focus on the true bottlenecks in your code – server-side code performance and database structure and usage. If your application can get by without accessing the file system, and if it can use Postgres as its underlying database, then Heroku is a good choice for a hosting solution.
Where Docker limits applications to a single OS, and Heroku limits your application’s use of OS features and database provider, AWS – short for Amazon Web Services – is a cloud-based hosting provider that essentially allows you to customize every aspect of the machine your application is hosted on. You can choose any run-time environment supported by AWS (such as .NET, Ruby, Java, Node, and so on), and choose your own database provider, and AWS handles the infrastructure end for you. AWS provides scaling of your server and data architecture, and charges you based on resource usage. This is by far the most flexible option of the three, but also the most complex to manage. If you have specific server usage needs, or a non-standard application architecture, then AWS is a good choice for a hosting environment.
Whether working in AngularJS, Rails, or even .NET, deploying your code to a publicly-accessible server is a vital step in ensuring your application is viewable by the world at large. Choosing a deployment provider – such as Docker, Heroku, or Amazon AWS – relies upon two things. First, you need to know the features your application needs to run, from accessible data store to custom server components. Secondly, you need to know exactly what your selected provider offers – each provider offers a different approach to deploying your application’s code, and can provide a lot of assistance (such as with Docker’s application engine) or no assistance at all (like Amazon’s bare-metal approach to server management). There is, as usual, no “right” choice in this respect – you’ll need to evaluate each provider in order to determine which best fits your application’s run time environment – but using the above steps to nail down some of the specifics of your application will greatly ease the deployment process.
Get a free hosted AngularJS backend with features such as user management, social signin, payment integration, security and more – GET STARTED NOW.