[Feature]: Implement a server-side portal - SE-738

[Tzal3x]

Description

The solution will have the core functionality of the service-worker, but this time on the server.

A similar implementation was done to branch gg/dirty/server-side-portal, using blocksite.net with vercel edge-middleware.

Benefits of this solution include:

• The ability for walrus sites to have their own business logic service-worker, independent of walrus-sites and sui.
• Monitoring of the whole flow of the requests.
• Updating already registered service-workers to client browsers is a pain. Now we would just update the server and everyone would be synced.

Note: We will still support the hybrid service worker solution, therefore we will need a common library that will be shared by both approaches.

Tasks:

• [x] #127
• [x] #139
• [x] #132
• [x] #130
• [x] #141

Component

portal

Code of Conduct

• [X] I agree to follow this project's Code of Conduct.

[giac-mysten]

Additonal advantage: the sites become crawlable by standard scripts without the need of a full browser.

[giac-mysten]

Maybe as a sub-issue: Can we have a combined portal that decides whether to serve the service worker or the content directly depending on the user agent/ability to install SWs?

This should be possible on the portal server by either:

• routing based on the user agent (e.g., iOS in-app browsers devices are served with the HTML content directly, other devices get the service worker); or
• having the portal return the initial page to register the service worker. If registration fails, the page refreshes and requests the server side version to be loaded (how to differentiate here? cookie?).

This would allow us to:

• maintain the portal servers relatively light weight, as only a fraction of the requests will need the full resolution; and
• support mobile wallets on iOS.

[Tzal3x]

Closed the PR to make multiple smaller ones.

[giac-mysten]

@Tzal3x can we close this issue?

[Tzal3x]

@Tzal3x can we close this issue?

Yes! Closing it now 👍