Introduce support for Server-Side rendering

[lschoett]

New Feature Proposal

Description

For some scenarios and supporting older browser version, Server-Side rendering could bring benefits.

Background

Certain older browser might not fully support all features provided by Piral. Another benefit could be improving the overall performance e.g. by adding caching for the rendered pages.

Discussion

One downside of using the Server-Side rendering is that the backend will require more resources for rendering and exposing the content.

[FlorianRappl]

Current options spectrum regarding rendering:

1. CSR, leave everything as-is
2. "shallow" ("level-0") SSR that places the feed service response in the delivered code
3. "level-1" SSR that places the (JS-bundles from the) pilets from the feed service response in the delivered code
4. "level-2" SSR that pre-evaluates the setup methods of the pilets; the initial state is already delivered and the pilets are all bundled together with the main code (setup will not be run again)
5. "level-3" SSR that does not stop at the setup method - actually the whole thing is rendered and hydrated from there again

They are not only sorted in terms of "SSRness", but also in terms of complexity (on our side and on the infrastructure of the user for providing / setting up SSR).

For the 0.9 version we will most likely go until "level-1" SSR.

[FlorianRappl]

We just published a sample at https://github.com/smapiot/sample-piral-ssr.

I think overall we are quite far, but I would like to also introduce these convenience functions. Most likely we will create a dedicated package called piral-ssr or piral-server for it.

This package will be free of any dependencies to Express or a specific HTTP requester - so all this would still need to be implemented, however, most of the (Piral-related) work should be done by this package.

[FlorianRappl]

This is now available as a preview with the package piral-ssr-utils.