Basically, everything after the domain should be consistent. If your assets are always loaded from a sub-domain (ex. CDN), it doesn’t matter which sub-domain, you can always handle that with a redirect (I’ll follow up on this below). So if you are serving a file at
assets.example.org/2019/07/example.png, you can setup a new domain or the same one at a new service, as long as you keep the file paths the same.
On the other hand, if you don’t like the old file layout and decide to change where things live, say during a migration, bad news bears, you have this whole other logic you’ve got to rewrite somewhere, potentially many somewheres.
But ya know, moving archives between services and keeping the file paths consistent, that’s pretty easy to do. Kinda presumed.
Hmmm. I’d consider how big the assets are, and where I’m storing them. Hugo modules allows you are arbitrarily pull in repos to build your site’s filesystem, so you could just do yearly or monthly asset repos. I’ve heard mention of size limits on MS-Git repos, so modules works with that paradigm.
Actually, modules and filesystem mapping is so awesome, I’d probably start with a yearly archive, and then break it down more if I need. Maybe I won’t.
I meant the show, specifically the pilot’s music video song. But if you are moving around between Seattle and Portland, congrats, you must be crushing it. I’m barely holding on here in Oakland.
Okay, earlier I said I’d follow up on redirects: they should not be used very often! If one is constantly redirecting and moving assets around to different domains, it creates more trouble than it solves.
In my hobby time I’ve been playing around with creating a digital asset manager interface-type themey thing in Hugo, using UUID to create HTML/API output for images and videos. And video archives gets big, fast. Still, date-based folders loaded on a CDN seems to be best config I’ve found.