Angular OAuth with Docker and hashed routing

Usually for an SPA you use path based routing and the web host needs code to serve the default document regardless of the physical path.

DEFAULT DOCUMENT SERVING

As an example, this is for a Node.js Express web host, where the get statement handles not found paths like /callback by serving the index.html file:

const spaBasePath = './';
const spaPhysicalRoot = './';
express.use(spaBasePath, express.static(spaPhysicalRoot));

express.get('*_', (request, response) => {
    response.sendFile(
        'index.html',
        {root: spaPhysicalRoot})
};

DOCKER HOSTING FOR WEB STATIC CONTENT

It is common to use an API gateway like NGINX as the entry point to APIs. If you use container-based hosting for web static content, you can add an extra hostname to the gateway for the web origin. A deployment expressed in Docker might look like this and would work for an Angular client:

services:
  apigateway:
    image: nginx:latest
    hostname: apigateway-internal
    ports:
    - 443:3000
    volumes:
    - ./default.conf:/etc/nginx/templates/default.conf.template
    - ./example.ssl.key:/usr/local/share/certs/example.ssl.key
     - /example.ssl.crt:/usr/local/share/certs/example.ssl.crt

  webhost:
    image: mywebhost:latest
    hostname: mywebhost-internal
    environment:
      PORT: '3001'

The routes in the default.conf.template file might look like this, to forward requests from the gateway to the web host. The resolver makes the hostnames work on a development computer.

resolver 127.0.0.11;

server {
    server_name www.myapp.example;
    listen      3001 http2 ssl;
    ssl_certificate     /usr/local/share/certs/example.ssl.crt;
    ssl_certificate_key /usr/local/share/certs/example.ssl.key;

    location / {
        proxy_pass http://mywebhost-internal:3001;
    }
}

Although it is useful to put together Docker deployments during development, production deployments tend to work differently. I describe a couple of common options next.

CLOUD NATIVE HOSTING

In real world cloud native deployments of static content you use platforms like Kubernetes and provide an ingress route. Certificates and hostnames are expressed in a parent resource. Typically the gateway loads certificates issued (and automatically renewed) by a component like cert-manager.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: webhost-route
spec:
  parentRefs:
  - name: kong-gateway
    namespace: apigateway
  hostnames:
  - www.myapp.example
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: webhost-svc
      kind: Service
      port: 3001

CONTENT DELIVERY NETWORKS

Personally, I prefer to use a content delivery network for the web side of the architecture since it has global performance benefits. For example, in AWS Cloudfront you can use a viewer request function like this to serve the default document for unknown paths:

function handler(event) {
    
    const request = event.request;
    const requestUri = request.uri.toLowerCase();

    const extensions = [
        '.html',
        '.js',
        '.css'
    ];

    const knownExtension = extensions.find((ext) => {
        return requestUri.endsWith(ext);
    });

    if (!knownExtension) {
        request.uri = `/index.html`;
    }
    
    return request;
}

PORTABILITY

As you can see, Docker and Angular can play nicely, though I also found techniques to serve web static content for a web application tricky when I first ran into them. They are not always explained well.

Regardless of technology preferences (Angular, React etc) or hosting preferences (cloud native, CDN), the techniques I describe are portable. You should be able to follow them and keep your future technical options open.