I don't think there's any reason the same codebase can't support different trade-offs here.
Maybe I'm just looking at the past through rose-coloured glasses, but it seems to me that was the norm before we standardized on distributing apps as an entire stack through a docker-compose.yml file.
Your app depends on redis for caching. If no redis instance is configured, go ahead and just instantiate a "null" caching implementation (and print a warning to the log if it makes you feel better) and carry on.
You're using minio for object storage. Is there any reason you couldn't, I don't know, use a local folder on disk instead?
Think of it as "progressive enhancement" for the ops stack. Let your app run simply in a small single node deploy, but support scaling up to something larger.
IMHO, redis is either used as a key value store (which can easily be replicated in application code) or as a central storage to synchronize tasks (like counters).
For the first case, dev should just build on SQLite or use application code. For the latter case, choose a single storage engine and use it for everything (Postgres?).
I don't think there's any reason the same codebase can't support different trade-offs here.
Maybe I'm just looking at the past through rose-coloured glasses, but it seems to me that was the norm before we standardized on distributing apps as an entire stack through a docker-compose.yml file.
Your app depends on redis for caching. If no redis instance is configured, go ahead and just instantiate a "null" caching implementation (and print a warning to the log if it makes you feel better) and carry on.
You're using minio for object storage. Is there any reason you couldn't, I don't know, use a local folder on disk instead?
Think of it as "progressive enhancement" for the ops stack. Let your app run simply in a small single node deploy, but support scaling up to something larger.