Imagine running an Europe-wide shop with Intershop, where the website is available in 16 different countries with different languages and a varying selection of products, but only little modification of the website appearance over all.
This would be set up by having 16 channels with one headless application each on the ICM side.
In a setup before the PWA 0.9 release this would have lead to a deployment with 16 PWA instances combined with one nginx for caching each.
Of course, a fail-over setup would increase the number of required deployment containers even more.
Therefore, starting from version 0.9, the PWA features means to dynamically configure ICM channel and application to determine the correct REST endpoint for each incoming top level request.
The aforementioned scenario can now be run with just one PWA instance and a reverse proxy running in front, implementing this dynamic configuration.
Warning
Refer to Multi-Site Configurations for an explanation of what is possible with multi-site configurations and how to define them.
To set ICM channels and applications dynamically, you have to use URL rewriting in a reverse proxy running in front of the PWA instances.
The values have to be provided as URL parameters (not to be confused with query parameters).
nginx URL rewrite snippet
rewrite ^(.*)$ "$1;channel=inSPIRED-inTRONICS_Business-Site;application=-" break;
The above example configuration snippet shows an nginx rewrite rule on how to map an incoming top level request URL to a dynamically configured URL for the downstream PWA instance.
It shows both the PWA parameters channel
, application
and their fixed example values.
The parameters of each incoming request are then read by the PWA upon initialization and used for the composition of the initial HTML response on the server side.
Afterwards they are propagated to the client side and re-used for subsequent REST requests.
In the source code of the project we provide an extended nginx Docker image for easy configuration of multiple channels via sub-domains.
These steps should give an overview of the internal workings:
The browser requests the page by URL from the reverse proxy. Nginx appends URL parameters to the incoming request URL for channel, application, etc depending on the incoming domain.
PM2 runs Angular Universal pre-rendering for the requested URL (and theme). Angular Universal dynamically configures itself with the incoming parameters.
The requested page is filled with content retrieved via ICM REST API for this dynamically configured channel.
The configuration parameters are persisted for the client application via state transfer. Afterwards, the response is delivered to Nginx.
The response is delivered to the browser.
The initial page response is displayed to the user and the Angular Client application is booting up in the browser, configuring itself with the transferred parameters for channel, application, etc.
Once booted up, additional REST calls are directed to the matching ICM endpoint for the configured channel.