Echo JS 0.11.0

OT: but letting it stand as it's a good explanation and is broadly useful even in JS circles.

----

I have one difference of opinion on SOLID, if you're writing projects in JS with JS Modules... the D (Dependency Injection) may not be necessary.  You can use module substitution techniques for testing, and unless you absolutely are supporting multiple concurrent types of modules with your application, wire them directly to keep the code more simple and easy to reason with.

Time and time again, I see DI libraries for JS that really aren't needed and only serve to add unnecessary complexity.

----

On BDUF, it doesn't need to be Waterfall... If I'm creating a package for a library/service, I will often start on the README.md first and include the documentation on how to use the library *BEFORE* I start writing code.  This lets me think about the abstractions for that library and how it will be used in practice before I paint myself into a corner.  It can also help with TDD and some test-first approaches.

I tend to only really use this approach for libraries that can be abstracted away from the rest of an application.

Interresting approach(es)... for recent applications, I've been using Koa, just because the middleware and context handling are much better than everything else.

I create an EnvironmentContext on startup that contains my settings (based on environment variables), configuration (based on application configurations) additional services (database client, redis client etc) and a general logger (bunyan, with console and optionally ES and Seq sinks).

The AppContext extends EnvironmentContext and my first middleware (begin-request) adds the environment context, adds methods for RequestInfo and ResponseInfo and wraps the logger methods to include RequestInfo for each log statement, and the final output being the general error logging middleware then the response middleware (which doesn't output, if error middleware already did).  I also add additional providers for easy apiResult and apiError responses as well as for Role based authentication (Jwt bearer tokens).

It works pretty well... made the switch to TS to make context handling easier... I also have it generically typed Context<TBody, TParams, TQueryString> so that I can have typed instances in my route handlers.

Each of my route handlers returns an array, so that it can include parameter/body/query validators (Joi or Yup), with the Role validation where all the routes are mounted.

Hoping to get permission to put the Configuration Service, which only delivers build configuration(s) output on Github in the next month or so.

Decent start on these things... might be worth digging in a bit deeper in a few areas.

I would suggest taking the next steps, which would be adding unit tests with an effort for high (>80%) code coverage, I find Jest is easiest to configure, and has some nice integrations for React apps.  This will help you to understand how to make your code more modular/accessible.

From there, would create Dockerfile(s) and docker compose files to make it easier to stand up an instance for local testing/usage.  You could go another step and setup an integration test project to work with this using puppeteer or Playwright.

After that, would circle around and look into Redux patterns as well as possibly GraphQL services.  Once you've started writing tests for your applications, it's much easier to see how helpful Redux as a control flow pattern can really help.  There are other options, but I find Redux + thunks extension cover most of the bases for most applications, and allow for horizontal feature growth without blowing out complexity.

updated title.

It's a little more wordy than it needs to be.  The "title" example is contrived and doesn't need useEffect.  Multiple calls for useEffect should be avoided, in fact too many hook calls in components can be detrimental to performance in general, for some things, it should be closer to the top level and integrated with Redux, or whatever you use for state management.

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.

No access security restrictions, don't put this on anything where all data in the database is meant to be anything other than publicly accessible.

updated to target url, and blocked gitconnected.

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.