Variations
In this lesson, we'll look at some variations to the approaches we've discussed already in this chapter.
We'll cover the following
Asset server #
The example uses a Node project for the shared assets. An alternative option is an asset server that stores the assets. Since the assets are static files loaded via HTTP, an asset server can just be a simple web server.
Over time, the assets will change. For the asset project from the example, a new version of the asset project would have to be created. The new version must be integrated in every microservice. This sounds like unnecessary work, but this way each application can be tested with a new version of the assets.
Therefore, even with an asset server, a new version of the assets
should not simply be put into production, but the
applications should be adjusted to the new version and also tested
with the assets. The version of the assets can be included in the URL
path. Thus, version 3.3.7 of Bootstrap might be found under
/css/bootstrap-3.3.7-dist/css/bootstrap.min.css. A new version
would be available under a different path
– for example, /css/bootstrap-4.0.0-dist/css/bootstrap.min.css.
Simpler JavaScript code #
The JavaScript code in the example is quite flexible and can also deal with the failure of a service. A primitive alternative is shown in the SCS jQuery Project. In essence, it uses the following JavaScript code:
Get hands-on with 1200+ tech skills courses.