Route-based rendering modes for organizing different applications of a single website

[abflow]

As a website may be composed of multiple types of applications (landing page, blog, PWA, store, api, etc), it might make sense to be able to choose between different modes of rendering or not rendering (API, SSG, SSR, SPA, Islands, etc.) according to different website routes.

For example, one may have the following pattern on a domain:

'/ '      -> landing page as SSG
'/blog'   -> partially hydrated blog with islands
'/app'    -> PWA as SPA
'/api'    -> non rendering route with an api

Each route may have different rendering requirements and also may talk to a different server on the backend or different cloud infrastructures.

Via Rollup, Vite allows to split the build output for multi-page applications.

Would that be possible to leverage that mechanism, maybe with a rollup plugin, in order to create the output for different rendering modes based on different routes in solid-start?

[nksaraf]

I think this is definetely in the future of SolidStart. We haven't started effort on this but the pieces are there. We will start will giving you the ability to prerender pages in SSR mode..

[abflow]

@nksaraf I'm quite interested personally in local SSR mode, using Service Worker for rendering. This pattern could be named "SWR".

[ryansolid]

Yeah this takes a little consideration, because once you load a page and go to navigate to the next there is the question of if you ever want to do a full page reload and what the gap is. Part of what we are thinking about is static routes are great for landing on them but afterwards doing more MPA navigation may not be desired. Then when you start thinking about SPA vs Islands not sure that needs to be a distinction if client-side routing is involved. Like you might want characteristics but that probably isn't necessarily even at a route level. I think caching might be the most interesting question. Because it isn't limited to just API requests, it could extend to server rendered HTML partials.

There are some assumptions the different approaches make that might suggest the need to a full page reload on the boundaries. But I wonder if this exploration will serve to streamline as much as categorize.

[abflow]

The caching strategy is really important and so is the SEO strategy in the design decision as well, when it comes to routes. One identifies caching, SEO, performance, state and cost of operation as major topics into the design process.

It is a quite complex equation the developer has to navigate into when performing design and architectural decisions.

But one thinks routes are a nice abstraction to build upon because urls really are at the core of the web platform.

[abflow]

Service workers are also scoped to a particular path, and in fact, some edge providers (Cloudflare, Deno Deploy) replicate the service worker functionality into the cloud.

So there are two kinds of client-side routing: the browser (main thread) one and the service worker one. They offer different functionalities. As service workers are kind of a proxy, one can delegate as much or as little server functionality to the local environment as one wishes, including the whole rendering part of the application.

[abflow]

It is true that not all functionality needs route level design. In the local client environment, it can clearly be separate with Service Workers on one side (when one needs route level management) and Workers on the other side (which can benefit from cross-route access).

At the end of the day, the design decision has mostly to do with ergonomics and user experience, as well as discoverability and replication (like sharing the state of an application between multiple clients).