At the top of your stack is the web server in which you host your web application in. This is a live, production system that is likely exposed to the internet, thus one that is at most risk. It should be judiciously kept up to date.

Ideally, your release pipeline resembles the one described in Chapter 3, Prepare Angular App for Production Release, where your frontend application is served by a containerized low-profile instance. This can be the minimal-node-web-server that I publish and maintain or an Nginx-based instance. In either case, an upgrade is simple by changing version number listed next to your base image:

Dockerfile
FROM duluca/minimal-node-web-server:8.6.0
WORKDIR /usr/src/app
COPY dist public

It is always a good idea to specify the version number of the base Docker image you're using. Otherwise, it will default to a latest behavior, which in this case may mean an odd-numbered release that is not suitable for production. That said, minimal-node-web-server follows layers upon layers of the best security practices that reduces the attack surface and makes it incredibly difficult to mount a successful attack to compromise your web app. In line with this theme of security best practices, minimal-node-web-server would never push an odd numbered node version as the default behavior.

If your content is served through an installation of a web server like IIS, Apache, or Tomcat, you must follow and track security bulletins for these technologies. However, most likely another person or department altogether will be in charge upgrading this server, which may result in delays resulting from days to months, which is forever in internet time.

You're at the highest risk, if you're serving your static web content, like your SPA, through the same application server that also implements your backend APIs. Even though your architecture may be decoupled, if upgrading any tool or application in your dependency trees has side effects on any other part of your application, it means there's significant friction in your ability to secure or improve the performance of your frontend application.

A truly decoupled architecture will also allow the frontend to scale at different rate than your backend infrastructure and this can have great cost benefits. For example, suppose that your frontend serves lots of static information and rarely needs to poll the backend. At times of high load, you may need three instances of your frontend server to serve all the requests but only a single instance of the backend server since the calls are few and far in between.