File adapters in v6

[aaronpowell]

Right now, the only way to use file fields is to have them uploaded and stored on disk (unless you poke though the code enough and find the references to some "keystone-cloud" thing that I guess isn't announced yet 😝).

This makes it rather inflexible from a hosting standpoint, as it assumed that the disk is writable and persistent, neither is something you can asset in a cloud environment.

Is a reintroduction of the FileAdapter pattern from v5 on the cards for GA of v6?

[gautamsi]

you can use this for s3 - https://github.com/keystonejs-contrib/k6-contrib/tree/main/packages/fields-s3

[gautamsi]

you can have separate bucket for dev and prod using different env variables

[aaronpowell]

I understand that, but it's all still a workaround. Like, do you have shared buckets for all devs, or do you have separate buckets for devs? What's the retention policy on the dev buckets? Is there a cost involved in the storage, and how long do you maintain that for?

These are all the kinds of questions that have to be answered by a company/project if you're only option is to use fields.

[dmythro]

Thanks for the link! Just ran into this from research, as deploying K6 app into any "app" cloud would require some persistent object storage. I was looking at DigitalOcean. My idea is to utilise their App Platform, managed PostgreSQL and Spaces (S3-compatible object storage with a built-in CDN) for uploaded images/files.

Also I've seen @k6-contrib/fields-s3-images package from the same repo, which can also process images and store to S3 with different sizes (didn't check how it works though).

Maybe anyone has experience to advice, or a better idea? At least, this "combo" is not as cheap as probably could be :)
Didn't find anything better for the stack so far. I'll probably better check another discussion on that now.

In theory, this kind of app could also be deployed to a simple $5/mo droplet with local file storage & DB, but it will require some effort on manual setup. Like "old times website on PHP", lol.

[gautamsi]

Have used digitalocean droplets and with spaces, it seems cheaper than aws and s3 as this is predictable cost with lot of bandwidth which is sufficient for low to medium usage

[dmythro]

Thanks @gautamsi

[aaronpowell]

Because I thought I'd have an explore, I've created a fork with an implementation of file adapters, and I've refactored it to use that for files (but not images) - https://github.com/aaronpowell/keystone/compare/devcontainer...aaronpowell:file-adapters?expand=1

Due to where the keystone-cloud stuff resides, the implementation of a KeystoneCloudFileAdapter isn't part of the @keystone-next/file-adapters package, but I'm sure you'd get the idea.

Happy to collab on this if it seems useful (I might do images tomorrow if I get time)

[aaronpowell]

Main thing I couldn't figure out while making this sample is how to implement the 'delete file' when the user sends a remove request (although, I'm not 100% sure it's implemented anyway...)

[gautamsi]

don't think you can get this merged in main repo, you should try to refactor this in a separate field package to use in your project. you are welcome to create a field in the contrib repo at https://github.com/keystonejs-contrib/k6-contrib

[raveling]

Thanks @aaronpowell & @gautamsi

Changing our approach to files and images is a big design effort that we acknowledge needs to happen. However we cant fold this into a General Availability release for Keystone 6. Once we've got that out of the way we'll have more bandwidth to come up with a better story for files and images. Until then thanks for your patience.

[aaronpowell]

#6355 here's the draft PR where it can be seen properly (and how it fits into the larger part of keystone's codebase).

My concern would be that not having it considered as part of GA will make it a harder feature to retroactively add down the track. As mentioned above you can work around this using fields, but once you've got all that setup and deployed, would you really want to have the complexity of moving to the built-in file feature once it is flexible enough?

[raveling]

We spoke to this topic in the recent Q&A event:
https://www.youtube.com/watch?v=r1IJh-iHm1c&t=937s