You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if we could choose between different drivers to store the uploaded data.
Files are a special case when it comes to backups, they need to be processed incrementally, with some CPU/load cost on production sites. Storing them on the DB will hit the DB and take away valuable (internal) bandwidth and doesn't help with caching.
Each mechanism has pros and cons. What I would like is implementators to be able to choose what fits for them.
One example we have at Theke: We use DigitalOcean which provides the Spaces tool. It allows storing digital assets in a very cheap fashion. And you can enable a Space to work on CDN mode, meaning it will generate a static URL for retrieving your digital asset.
It is not only cheap, but also reduces the server overhead (leveraging on DO's infrastructure instead) and also lowers the backup strategy mess for us.
There are other providers (e.g. Azure, etc) with their own protocols. But having the code refactored so there can be many implementations using different providers/protocols, while keeping support for the current local files dir would be great.
I picked the S3 protocol because that's what we need, but happy to discuss others, or come up with a good design that allows easily implementing any required protocol by interested parties!
The text was updated successfully, but these errors were encountered:
It would be great if we could choose between different
drivers
to store the uploaded data.Files are a special case when it comes to backups, they need to be processed incrementally, with some CPU/load cost on production sites. Storing them on the DB will hit the DB and take away valuable (internal) bandwidth and doesn't help with caching.
Each mechanism has pros and cons. What I would like is implementators to be able to choose what fits for them.
One example we have at Theke: We use DigitalOcean which provides the Spaces tool. It allows storing digital assets in a very cheap fashion. And you can enable a
Space
to work on CDN mode, meaning it will generate a static URL for retrieving your digital asset.It is not only cheap, but also reduces the server overhead (leveraging on DO's infrastructure instead) and also lowers the backup strategy mess for us.
There are other providers (e.g. Azure, etc) with their own protocols. But having the code refactored so there can be many implementations using different providers/protocols, while keeping support for the current local files dir would be great.
I picked the S3 protocol because that's what we need, but happy to discuss others, or come up with a good design that allows easily implementing any required protocol by interested parties!
The text was updated successfully, but these errors were encountered: