avaq / node-server-skeleton Goto Github PK

Particularly bootstrap is very ambiguous an currently serves a conflicting purpose with the /services directory.

The main activities in bootstrap right now are:

• Adding services to the momi state.
• Generating monads that embody the app runtime.

These are basically ordered IoC resolution instructions.
Perhaps this would be better named /di, /ioc or /providers.

Meanwhile /services doesn't provide the actual services in all cases.
For example /bootstrap/app.js provides the app service, but is not in /services.
While /bootstrap/token.js provides the token service, but is exposed by /services/token.js as two functions rather than the factory-style object creation that is eventually done in bootstrap.

Having the factory part of things delegated to bootstrap makes the distinction between /services and /util very small. The main distinction being whether you're allowed to directly require them or should use the service locater pattern.

Now consider this use case.
An application wants to use port binding as it's access control mechanism.
Say 9000 for it's read API endpoints.
And 9001 for it's write API endpoints.

In the current setup you would end up with a lot of duplication of the /bootstrap/app.js, /bootstrap/http.js and /bootstrap/https.js code.
I believe this may justify a /factories directory and include putFactory & getFactory methods similar to the service location setup.

My initial proposition would be:

• /providers - the bootstrap replacement, may add services or factories to the state, and generate monads.
• /factories - dedicated factories folder to make DRY providers
• /services - the services that will be loaded as-is
• /util - code that is impractical to offer through services
• ❌ bootstrap.js - this virtual means the same thing as index.js so I think index.js will serve this purpose just fine.
• index.js - will do the "bootstrapping" of all the providers

Allowing stuff like Winston to be bootstrapped in different ways, depending on environment.

The only way to extend a session is to refresh the authorization token using a refresh token. However, it is good practice for a client only to store the refresh token if the user opted to be remembered on the client. When the authorization token expires without the client being allowed to refresh it, the session may expire while the user is in the middle of something.

Allowing sessions to be arbitrarily extended using just the authorization token is problematic though, as it would defeat the point of not storing refresh tokens.

Callbacks with keys parsable to integers may be reordered.

https://bugs.chromium.org/p/v8/issues/detail?id=164

and semver.satisfies accept integers as ranges.

One that could replace the use of debug and util.log and have adapters for logging into the cloud.

For stuff like user invitation and forgot password. These elevated tokens should have shorter life-spans.