So with workers I can just check if banner in R2 with id 542 exists or not and if it doesn't exists serve the default one.

But with public bucket the only solution I can see is that I would need to store default banner under each ID.

So both options have pros and cons and different costs. One consume more storage and another one more requests.

depends on how it's being used

if you're running client side code, you could see the error when you try to request banner 543 and it doesn't exist, and fall back to a default banner

or, you can take care of this condition upstream

not really sure what your use case is, but an example I've encountered before is the Discord API - if a user has an avatar, the API returns a hash which can be used to compose a URL to access the avatar image, but if the user doesn't have an avatar, it returns

null

, which signals to the client that it should use a default avatar instead

I'm pretty sure this is generally the standard practice, since, speaking from personal experience, loading a default avatar for every user is both a waste of space and an absolute nightmare for maintenance (consider what you'd have to do if you wanted to change the default avatar)

Thanks

Will probably just use workers for this.

Hello people. I have a general question about R2, CDN, Pages and Functions. I want to have prerendered HTML somewhere, not decided yet whether it should be R2 or Pages, but leaning towards R2 since it should be possible to generate an additional page and add it to an existing bundle without reloading everything. Or use Pages Functions with D1 to generate HTML on the fly on the edge (with ejs or whatever templating mechanism), since both Function worker and DB should be close to the user. so the latency to get data from DB -> generate page and then return it to the user will not actually hit my origin server, since there is no origin server. The pages are 90% static, some elements should be dynamic and currently I handle it with HTMLRewriter available in workers. Which one is a preferred way and has less pitfalls?

D1 is quite slow.

I would recommend you to store HTML and serve it from KV + Cache API.

D1 is still in alpha, so figures

True

Is 'Sip by Sip' migration still going to be a thing? I've seen teh link to join waitlist in the blogpost, but takes me to the "R2 Migrator" page, which has nothing about such a migration, just the option to start a 'bulk' migration.

one should note - D1 is quite slow for now (it is in alpha, after all, so I don't think one should base decisions on current speed figures). I suspect we'll see some major improvements between now and GA. Also, it depends on whether the speed difference actually matters for you - I'm using D1 for a testing branch of my site, and the site really isn't any slower or less responsive. Note if you use KV, you have to deal with the consistency issues, and the fact that you have to implement all of the database logic yourself. Sounds like a good solution for you would be to have the site stored on pages, and then use a pages function to return the dynamic data as JSON. Then, you can use a little bit of client side code to grab the dynamic data from your function endpoint, and put it into the client-side document.

that would be bad for SEO, it is safe to assume your page is going to be scanned fully by search engine if it gets full HTML. It is still unknown if generating content on the page after the

documentReady

event affects SEO in a negative way, even if we say it doesn't (google did mention something like this), how does a search crawler know that a page has finished generating SEO critical content? It is non-deterministic. So, I would like to generate HTML in full before sending it to the client. My first thought was to use pages and adjust deployed HTML as anything changes (a post is edited, or a new one is added), but it is impossible atm with pages, you have to redeploy the whole thing.

in my experience, this isn't usually a problem for modern web crawlers, as long as you start your fetch request right as the page loads, it'll let it finish. It may not be truly deterministic, but it's good enough for most web crawlers to be able to figure it out. Either way, if you want your site to be SSR, I'd store the posts in R2, and have a worker load the appropriate R2 object and insert it into the template.

@GeorgeTailor that was supposed to be a reply to you, guess I missed the button

rclone did not migrate the metadata from b2 to r2 and for s3cmd, currently struggling to even configure it for s3 just getting a "ERROR: Test failed: 501 (NotImplemented): ListBuckets search parameter delimiter not implemented"

I am not sure how that would work, as there are tons of stuff you should change depending on the content, for example, title, a plethora of meta tags, in some cases

application/ld+json

for rich content and the page content itself. Also, many services use link-preloading, they don't load JS and don't execute it just to make sure the link preview title is correct.

btw, R2 is not global, is it? It does not replicate its stuff around different DCs?

obviously it's not a one-size-fits-all solution, and if you need to do complicated things like that, you're more likely to need to invoke a worker to render every single request

I don't know, I always thought this is the minimum every site should have to be good at SEO xD

No, buckets are only in a single location, but presumably your requests will be cached

As for the cache, it cannot be purged it across all workers, right? From what I read each worker at a specific location will have its own cache. When I change a post, I would expect the cached version be purged from all of the workers

You can use the Cache Purge API for that

could you post a link to the docs about this? I only found one for CDN, not for the workers