By default, Angular CLI supports setting the deploy URL of the application with the
build command parameter
As this is only supplied as a build-time setting, the required flexibility for the Intershop PWA cannot be achieved.
For example, if the Intershop PWA Docker image is deployed in multiple environments in an Intershop CaaS context, every environment would have to build a new PWA.
Therefore this functionality is not used out of the box.
However, it is possible to dynamically configure the deploy URL as a runtime setting for the SSR container.
To solve this problem, individual problems had to be solved:
The Angular CLI build process inserts references to the initial bundles (
runtime) into the
index.html relatively when called without
--deploy-url, but uses a static deploy URL if requested.
runtime bundle loads lazy loaded chunks relatively if no
--deploy-url is passed, and via deploy URL if built with the
The CSS bundles contain absolute and relative references to resources in the
The PWA code itself contains relative and absolute references to the
assets folder (i.e. images).
The solution can be schemed as follows:
ng buildprocess has to be triggered with a placeholder for the deploy URL.
assetsfolder are transformed into absolute URLs pointing to the deployment URLs.
This way, setting the deployment URL becomes a runtime setting and can be changed without rebuilding the Intershop PWA.
The PWA client-side application has to be built using
ng build ... --deploy-url=DEPLOY_URL_PLACEHOLDER, which introduces a placeholder for all deployment-dependent functionality.
This placeholder is then dynamically replaced by the SSR process using the environment variable
DEPLOY_URL (i.e. by setting it at the SSR container).
DEPLOY_URL is supplied, the fallback
/ is applied.
This placeholder can also be replaced statically when no SSR process is used in the deployment by running the script
npx ts-node scripts/set-deploy-url <deploy-url>.
<deploy-url> is supplied, the fallback
/ is applied.
For consistency reasons the build process must always follow this pattern, so that all references to the
This build process is also provided in the Docker images as default solution.
With this new feature, some complex deployment scenarios can be solved with the Intershop PWA out of the box.
If you want to deploy all static resources of the Intershop PWA to a Content Delivery Network, you can use the above build steps to set the deploy URL via script in the build output.
Delivering resources via a CDN significantly reduces the load on the PWA if certain pages can also be stored pre-rendered or if the experimental Service Worker support is used.
Consider the following deployment scenario:
You want to use the Intershop PWA as part of a bigger portal to provide a shopping experience.
However, not all of the product pages are to be handled by the PWA, as you want to use a different integration from the portal that is already available.
Most likely, all product pages have a similar URL pattern and should be available from the same domain for SEO reasons.
This scenario would mean that the portal and the Intershop PWA would share routes similar to the Hybrid Approach.
To set this up manually, a lot of rewriting for static PWA assets would have to be set up in the portal's reverse proxy, so that Intershop PWA client applications can boot up correctly.
By setting a deployment URL, only the incoming routing for server-side rendering would be targeted at the portal's reverse proxy.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.