In practice, I'm generally using Redux for almost everything. Two areas I am not is specifically strings/language and sometimes with Forms. I use context for language, and may use state or context for forms.
One thing that is a side effect I explicitly do with language/strings is that the current/selected language as well as the current language strings are accessible as globals in the language/strings module(s). This is only so that they are accessible in error messages/conditions that might be in an Action or Reducer. It's "sloppy" but effective.
For the components, I use "useStrings()" which gets the current strings from context.
I also use the browser language events as well as an override in the UI that override is set in redux and those events update the current strings to use in context and globally.
I'm not seeing anything regarding access restrictions... I would emphatically *NOT* use this unless everything the account in use has access to is meant to be public, and has no write access to the database.
Cool.. would be cool if react components were supported... I've leaned so heavily on material-ui the past few years, I'd rather not go without it. Though bootstrap is easy enough to integrate with just the (S)CSS from source.
When creating a crypto key from a known value would use pbkdf2 @ 10000 or higher iterations for the encryption key from known key, MD5 is *NOT* sufficient.
When an IV or salt is used, it should be unique to each encode. Can be added to the encrypted output or stored separately... re-using the IV allows for a broader attack surface, especially if the encoded content is simlar, such as JSON encoded objects, etc.
Didn't notice it called out, but Brotli in time to compress is roughly the same as .gz, pest to use it for pre-compressed files at build-time, not dynamic compression at runtime (unless the server will compress/cache the results), not good for dynamic routes.
IMHO, this is emphatically *NOT* the most scalable app architecture... imo, feature oriented structures work far better. A given feature may have child features, may have action creators, reducers, components, data access requests, etc, etc.
Nested, mirrored trees organized by type is much harder to work with in practice as your related items are spread across several directories reducing the usefulness of having a directory tree for your files to begin with.
As to the mention of Axios... just wrap fetch for your needs directly.