Separate the building of browser and server code in pre-rendering script

🚀 Feature request

Separate the building of browser and server code in pre-rendering script

What modules are relevant for this feature request?

• aspnetcore-engine
• builders
• common
• express-engine
• hapi-engine
• module-map-ngfactory-loader

Description

Currently when running ng run myApp:prerender, it consists of building the server and browser code. When the server code is done, the build script will move on building browser code for each route.

In most CMS scenario, the code base is the same. Only the data in database or the deletion/additional of route are needed. It will be faster if there exists something like ng run myApp:prerender --only route, only building the routes from existing server code.

[MarcoGlauser]

We adopted the file to this for Angular 10.1 https://gist.github.com/MarcoGlauser/80fd3d91529f4ab4c1f9e2e39875f324

The main difference is that we don’t pass the html content of index.html as a parameter and instead read the contents of the file during the process. This adds some overhead and might not work for some edge configurations but should work for most projects.

We transpile it during the build process. To do it manually, this should work

tsc prerender.ts

Once transpiled, we call it with node.

node prerender.js index.html dist/{myproject}/server/main.js dist/{myproject}/browser /route-to-prerender-1 /route-to-prerender-2

To run it concurrently, you can call it with a routes.txt file and xargs:

cat routes.txt | xargs --max-procs=4 node prerender.js index.html dist/{myproject}/server/main.js dist/{myproject}/browser

This process works well for us, but chances that it breaks with future Angular releases are very high. Make sure you have the same version of the server and browser target, otherwise you’re in trouble.

[wagnermaciel]

Context

When I was working on the design doc for this with Vikram we talked about adding an option like this but decided against it to avoid developers accidentally prerendering an outdated build. We were especially concerned with this happening if we ever coupled prerendering and ngdeploy - meaning a developer could accidentally deploy the incorrectly generated pages.

Implementation Details

If we look at line 162 of prerender/index.ts, we can see that we use the output of the browser and server builds to locate a couple of files like the base index.html and the sever bundle. That’s the only major complication I can see here. We’d still need to find a way to provide that information to the _renderUniversal method.

Conclusion

If those concerns don’t bother us enough, and if someone is willing to put in the work to figure out a neat solution for this, I think these changes are worth looking into. Especially because more than 90% of the time it takes to prerender comes from building the browser and server bundles.