Echo JS 0.11.0

Something to note: Other than local/development, and even for testing, don't put your production configuration into .env files... either generate it from a template in your ci/cd pipeline, manually generate it and/or use the actual environment to specify said settings.

Another aside, I really tend to prefer the URI syntax for connection strings, this allows for a single setting to contain protocol, user, password, host, port, database and additional options.  While it's a more complex string, it's fewer things that need to be set in terms of environment variables and secrets and the more applications/services you are setting up the more you will appreciate the convention.

This is just my $.02, but class-based models are just burdensome in practice and tends to come from a different mindset, usually those who are very experienced or comfortable with Java or C#. I'm not a hard liner either way, there are times where class syntax is incredibly useful with JS, usually where you need to bind context to events, however this is more of an exception to the rule so to speak and being pragmatic over purity.  For most logic work, functional workflows will be easier to comprehend and maintain over time.

While you can use this approach, I find that in practice, it's generally better to use plain/simple objects without any magic, and use immutable function libraries against those plain objects (and/or arrays of plain objects) for workflows/pipelines.  If you're using TypeScript, you can still do interface definitions for expected properties and the shape of said objects.

Once you go down the path of getters/setters you open yourself up to a level of mutation that's hard to account for in terms of testability and reliability.

JavaScript has a wonderful flexibility in terms of object construction with functional composition.  And while not strictly a functional language with full immutability features, the closer you stick to these conceptually, the less variance and trouble you will have in practice.

In case you need to do totp tokens (google authenticator compatible)...

https://github.com/google/google-authenticator/wiki/Key-Uri-Format

This library seems to introduce its' own complete CSS instead of re-using the SCSS that Bootstrap from source offers.

Don't use bootstrap this way... It's *REALLY* easy to use Bootstrap's SCSS from source.. Include bootstrap as an npm dependency, have your scss file set whatever font/color settings you want to use, then include the scss from bootstrap proper.

Not really a fan of ORMs at all... would rather use joi for validation, and libraries that use plain objects to represent data...

Cool, but what does this really do/offer over react-redux's useSelector?  I mean, you potentially have access outside of context, but you can do that with React's Context as well as Redux.

Really veers off-topic.  Do you guys appreciate this kind of content?  It seems to be higher quality than most similar content I see, usually very spammy, which is why I didn't just delete it.

Like too many articles, this conflates/confuses a couple of things... Material Design is the design guidelines by Google[1].  Material-UI[2] is a React library of components that implement Material Design.

That said, Material-UI is the single best component library, with React that I have ever used or experienced.  In practical use, I will almost always defer to the design guideline and component defaults and/or examples and try to use the components with minimal modification.  There are a *LOT* of components that follow the theming and it works great.

I will say some of the commercial (and free versions) of "templates" that use material-ui are very bad in terms of code structure and layout.  They often break the approach setup in the framework (using a function for jss that receives the theme and adding additional properties to the injected theme).

1. https://material.io/
2. https://material-ui.com/

Really like this library overall... while it may seem weird using abstractions for browser API use, the abstractions are clean and the use is really close to what one would hand-craft anyway.

Used Twilio a couple times for things like this, Nexmo seems to be a hair less expensive, but not sure how responsive Nexmo is vs Twilio.