Deploying a Web App, an API, and a Website under the same domain

In this post, we look at how Altostra makes it simple to deploy multiple web facing components under the same domain.

Shlomi Borovitz

Published in

Altostra

5 min readOct 6, 2020

Originally published on Altostra.

Background

Managing websites and application that are accessible via our domain can be tedious — It requires managing multiple records and understanding what each record points to.

In this post, we explore how Altostra can simplify the process.

What you will need

Certificate

An Amazon Certificate Manager (ACM) certificate that identifies you as the owner of your domain. You can either request a certificate directly from ACM, or import an already existing certificate into it. For more information, read the AWS docs.

Route53 Hosted Zone

An AWS Route53 hosted-zone that corresponds with your domain. Altostra creates the DNS records for you, but you do need to have a pre-existing Route53 DNS Zone to host them.

A hosted zone contains records that define how internet traffic is routed for your domain and its subdomains.
For example, in the example.com hosted zone, you can create records for example.com and www.example.com that route traffic to a web server, CDN or a REST API endpoint.

For more information about how to configure a hosted-zone for your domain read the AWS docs.

Building our domain

We create a project and populate it with the following:

A static website
A web application that has:

Statically served client application
REST API that serves the logic of the application

A domain to host the website and application

The static website comes included and configured in an Altostra template — so we can use it jump start our project.

Setup

We begin by creating a new project from the `static-website` template.
Using the `alto templates` command, we can see which templates are available to us, then using the alto init --template static-website we initialize a new project from that template:

$ mkdir static-website
$ cd static-website$ alto templates
✔ Getting project templates
Available templates:
* static-website
* ...$ alto init --template static-website
✔ Getting template 'static-website'
✔ Initializing project$ npm init -y; echo node_modules > .gitignore$ git init
$ git add -A .
$ git commit -m "Initial commit"

Architecture

Since we are starting from the static website template, we have to add a domain, another CDN and another bucket, and an API with a few endpoints.

We configure the domain to use a parameter named DOMAIN as the domain name.

We also add functions to be called by the API endpoints, and a table to retain some application data.

Configuration

We need to configure our domain to meet our requirements.

Starting with the Domain resource, we configure it to use parameters from the environment it’s deployed too.
We enable the *Register in DNS* checkbox and save. Without this, the DNS records are not created and only the configuration for the other resources is applied.

The connection to the static website CDN is already using a certificate parameter CERT_ARN, so we only need to set the host name to www to make it accessible via www.<our-domain>.

Similarly, we will set the host name for the application files CDN to app and the API’s name to api.

Setting the environment

Our project is parameterized so that we are able to deploy it to different environments where each environment provides its own configuration values for the project parameters.

We can set the parameters explicitly for every deployment using configuration-set file, but this is error-prone and can lead to misconfiguration of deployments.

Instead, we will set the configuration in the environment, thus sharing the configuration with other deployments in the same environment, and allowing us to seamlessly deploy the same image to different environments, each having appropriate configuration.

Using Altostra Web-Console, we edit our environment configuration to include DOMAIN AND DOMAIN_CERT parameters with appropriate values.

Web site content and functions code

For brevity, we skip the process of adding the web content of the website and the web app, and also the source code for the functions. We touched on the subject of static websites in previous posts, you can find these on our blog.

Deploying

In order to deploy an Altostra project, we need to create an image.
We can then deploy that image to an environment of our choice.

We create an image named v1.0:

$ alto push v1.0
✔ Validating tag name 'v1.0'
✔ Checking user credentials
✔ Loading project
✔ Validating project file integrity
✔ Loading project
✔ Getting build repository
✔ Updating project file
✔ Validating image availability
✔ Packing files
✔ Getting repository information
✔ Uploading project parts

Now, because we don’t have an existing deployment of our project, we need to create one.

Assuming an environment named Demo already exists, we create a new deployment named main from our image by running the following command:

$ alto deploy main:v1.0 --new Demo
✔ Processing request
✔ Deploying projectDeployment status of deployment main:┌─────────┬───────────────────┬─────────────────────────┬────────┬─────────────┐
│ (index) │       User        │          Date           │ Image  │   Status    │
├─────────┼───────────────────┼─────────────────────────┼────────┼─────────────┤
│    0    │ 'Shlomi Borovitz' │ '10/4/2020, 1:14:23 PM' │ 'v1.0' │ 'Deploying' │
└─────────┴───────────────────┴─────────────────────────┴────────┴─────────────┘

Finally, we upload our site content by running:

$ alto sync main --all --public
✔ Checking user credentials
✔ Loading project
✔ Validating buckets
✔ Getting repository information
✔ Syncing files to site-files

And invalidate all CDN caches by running:

$ alto invalidate main --all
✔ Checking user credentials
✔ Loading project
✔ Getting build repository
✔ Validating project
✔ Validating CDNs
✔ Invalidating CDN caches
✔ Invalidation process is in progress. This may take a while.

Conclusion

In this post we saw how Altostra can help you manage multiple websites and applications under a single domain, automating the creation of all the underlying cloud resources such as custom domains, DNS records and policies.

You can also deploy with different domain names per environment by providing the domain names and certificates as environment configuration to be applied during deployment.