I do use a separate context for Theme (via Material-UI) as well as my localization (strings). I still use Redux as it solves more than just simple isolated/specialized state. When you need/want more bits to state that don't fit well in an isolation model, doing what Redux does with context directly becomes more burdensome... not to mention the developer tooling around Redux is very good.
Understanding when to use environment variables (particularly for talking to other services in a system) vs. options or feature flags isn't always the most clear separation even for some experienced developers.
I can say on the config changing... for myself, usually only load at startup in a containerized service, or loaded via script from config/api service at startup for web-client.
What I'm using is pretty much wrapped around this: https://www.npmjs.com/package/@tracker1/config-merge
Supports rollup merging a configuration project including support for multiple language/strings variations. I no longer use it out of the box cli, but am using the library directly either in the api or a dedicated config service. Mostly configuration options as the software I work on gets deployed to different clients with slightly varying configurations.
I also inject CLIENT_* environment variables as part of a script output, that is the first script loaded into the web page, with a `__BASE__` global variable... in the application, I have a base.js that will do some normalization for access/testing, and also a language context in react that will set the current language/localization strings for use in the application.
I wish I could share more than the base library... trying to convince work to let me publish the config service and a docker image for said service...
Probably the main thing I would change would be to just use pbkdf2 as the hashing algorithm for passphrases. Mostly because it's in the box for node 12+ and also because it's expressly spelled out in the NIST security guidelines. I do use 100k iterations for salted passphrases, and 10m iterations for derived keys for other system encrypted data.
Also worth considering, is that login entry is an easy target for DDoS, so ip/user limiting mitigations are a good idea in practice, redis (sorted sets) is a really good option for this.
In addition, an invalid login attempt should usually have a random 2-3 second wait before returning the failed result, this will (usually) slow down any brute force efforts and mitigate timing attacks.
Not a fan of DI/IoC frameworks for JS in particular... it's not needed in most places and easy enough to wire directly in others. For testing, module intercept/mocks are readily available.
Kind of an advertisement for Ably's paid SaaS, added "(Commercial Service)" tag to the title.
I don't think anyone is under the impression that Jamstack can't do dynamic content. The point of Jamstack is to move away from heavy, large, opinionated frameworks. Especially as most browsers now support echmascript modules as well as the dynamic import method.
I'm thinking a loader shim could get us very close to a similar experience for Svelte with say the Svelte Material UI component library[1], redux and a decent client side router. I've seriously been wanting to play more with these lighter weight toolkits.
I think React + TypeScript is probably better for many web based applications, but a lot of sites/apps don't need that level of overhead, especially with single developer or small team scenarios. Aside, never thought I'd warm up to TypeScript at all.
1. https://sveltematerialui.com/
Three things...
1. When reading/writing text files, should explicitly specify the text format ('utf8' or 'utf-8').
2. You can use the `require` function to read/parse JSON files directly.
3. You should consider pretty-printing your JSON output when writing the file. `JSON.stringify(input, null, 4)` where the second parameter is an optional object serialization method, and the third is a space indentation for pretty printing, usually 2 or 4 when specified.
Came to say largely the same... about half of the great developers I know started by solving a real problem personally, they learned programming enough to solve their own problems, and it was years later they learned some CS or more structural knowledge.
In the end, creating software is a skill of learning and forgetting as needed at a reasonable pace. Very few problems are hard engineering or cs problems.
I haven't done anything myself... mostly moderate posts etc, and did get a docker/compose setup easier to get started with, but haven't had time to circle back around.
I'd been wanting to try taking the time to make an api compatible version in Node or Deno, only so it was in a language/platform I'd be better able to participate in future development/enhancement on.
Again, keeping the API the same, and the same database and data structures to start with. I'm no expert in lamernews... I only did enough so far to make it easy to spin up via a docker-compose.yml file and some minor changes to support environment variables for a couple config bits.
Three things... 1. When reading/writing text files, should explicitly specify the text format ('utf8' or 'utf-8'). 2. You can use the `require` function to read/parse JSON files directly. 3. You should consider pretty-printing your JSON output when writing the file. `JSON.stringify(input, null, 4)` where the second parameter is an optional object serialization method, and the third is a space indentation for pretty printing, usually 2 or 4 when specified.