search

MystenLabs / walrus-sites

Walrus Sites: Decentralized Websites using Sui and Walrus.
https://docs.walrus.site/walrus-sites/intro.html
Apache License 2.0
10 stars 7 forks source link

feat(portal): fallback to 404.html blob if available #86

Closed jeka-kiselyov closed 3 weeks ago

jeka-kiselyov commented 3 weeks ago

Works great overall. Very smooth.

One improvement I'd like: custom 404 blob for a site, something that would be returned for the site if there's nothing found for the path.

Take a look at the sample site I deployed: https://1e1maorotlxkr4feuf7m9jqliu9j12dlr8lxvt28u23f3lur5s.walrus.site/

Everything just works, out of the box, awesome, I was like going to cancel my Heroku plan.

The only thing is that if you navigate to links from the page with history api:

https://1e1maorotlxkr4feuf7m9jqliu9j12dlr8lxvt28u23f3lur5s.walrus.site/ -> https://1e1maorotlxkr4feuf7m9jqliu9j12dlr8lxvt28u23f3lur5s.walrus.site/capsule/0xfd72e8611ed8ebfa2f93acf9640bd8a5096923880feeeae7fabc96d4f6cffab2

it shows the page, but shows 404 if you do refresh. Which is expected, and we can use hash-navigation as a workaround, but would be 100% super if it would support common pattern for SPA - serve specified .html file for any path. (just custom 404 would be great for some cases too).

Adjusted service worker quickly to check if there's '404.html' blob in the root near 'index.html' and serves it on 'Not found' if it's there.

jeka-kiselyov commented 2 weeks ago

@mlegner Thank you!

@giac-mysten Thanks! Yeah, possible option would be to cache everything just on the firrst call of fetchPage with specific objectId, so you already know which blobs are there - and it would be blazingly fast. But... invalidation, that's a tough part. Maybe there's some place where Sui Object version just get updated and it may be used for the quick reference to check in a single RPC call.

It's like the new universe you are building here. Huge space for experiments and improvements. Great.

giac-mysten commented 2 weeks ago

But... invalidation, that's a tough part. Maybe there's some place where Sui Object version just get updated and it may be used for the quick reference to check in a single RPC call.

exactly! I think something like this could work. On the other hand, asking the Sui Object version or asking the full Sui Object are probably tanking the same amount of time (i.e., the network RTTs to the full node. The objects are quite small).

I think the 80/20 towards much better performance is (i) always fetch the Sui object from the full node, and (ii) always cache the Walrus blobs. Since these are immutable by definition, until the Sui Object does not specify a new blob ID we can keep serving the cached one.