cdn
cdn copied to clipboard
dadi
Asset revisions
I propose we introduce an asset revision identifier in the new URL syntax, allowing for a site to refer to a specific git revision of assets. This would solve the issue of syncing backend/frontend deploys (if cdn is updated automatically the backend could refer to any version it wants), as well as removing the need for cache busting (as the paths would change when the version changes). Finally it would make it possible for different projects/subsites to use different asset versions if needed.
I can see two ways of doing this
- Either the revision is "per-repo" and refers to the sha of the latest commit of the repository that feeds the cdn
- Revision per file, meaning when a deploy happens only files that change will have their paths changed.
The second alternative (per-file revision, using its checksum), while more difficult to implement the frontend/backend integration, but would provide clear cache performance benefits over repository-wide revisions (only files that change would be "invalidated").
I've had a think about this and had a chat with Jim about it. I'm going to give it further thought and have a play around with a few concepts and see if I can hash out a basic working model. ⏳
I've had a go at this on per commit level, where every version of a file would be available via the commit sha of the commit that version was added in. This is just a bash script for now but it could form part of a publish step for the CDN perhaps?
https://github.com/adamkdean/sha-test
Improvements could be made – like for example, this only works for files present in the files/ subdir when the script is ran, however, that could be a good thing, delete a file from files/, run the script, and you've now unpublished a file.
Thoughts? 💭
Some food for thought in regards to how this might look from a client standpoint - S3 supports this kind of behavior, you can read the docs here. Aside from the obvious implication of using CDN when it's backed only by S3, we could use a similar methodology for other adapters (disk, etc) of keeping items under the same name and using another parameter to ask for particular hashes.
Clients can ask for an item just by it's name (and get the current version) or at a particular hash, and get the consistent version for as long as it's kept.
I think per-file is obviously preferential here, but the only obvious way I see of handling that easily is to let CDN do it's own git pulls/clones for assets which it could then handle versioning on (probably just use the file/commit hashes as in Adam's example above).
~~Would this belong in https://github.com/dadi/cache now @jimlambie?~~ ignore me
Clients can ask for an item just by it's name (and get the current version) or at a particular hash, and get the consistent version for as long as it's kept.
@dark12222000 I definitely think this is the way to go. If you think about it, docker does the same, if you pull example/name then you get :latest, but if you provide the tag, you'll get it, even if the tag is a sha. So long as the contract remains the same, the implementation can be provider specific.
