hfour / h4bff Goto Github PK

This should enable us to stop worrying about publishing and respecting semver.

https://github.com/Updater/semantic-release-monorepo

While writing the "Thinking in H4BFF" article, I realized there is no standardized way to get an identifier of the current user in the plugin. It might be nice if we provided this interface built in.

It would have to be configurable by the app though. Something like

this.getSingleton(UserProvider).setProvider(ctx => ctx.getService(MyUserAuthService).id);

Plugins will use this.getService(UserId).userId to fetch the current id, which will simply call the provider.

This will just provide a common unified interface so that you don't have to configure the user provider for each individual plugin. It will still allow you to build or use multiple user authentication implementations, so long as they set up the provider.

Concern: we might need to standardize the userId type to always be an uuid, or at least a string.

The PG pool opens connections towards the database. When the app is killed, or when a script finishes, these aren't gracefully terminated and we get these messages:

db_1          | 2019-03-12 12:55:42.030 UTC [9527] xxx@xxx LOG:  could not receive data from client: Connection reset by peer
db_1          | 2019-03-12 12:55:42.030 UTC [9528] xxx@xxx LOG:  could not receive data from client: Connection reset by peer
db_1          | 2019-03-12 12:55:42.033 UTC [9529] xxx@xxx LOG:  could not receive data from client: Connection reset by peer

This isn't causing functional problems, but it's not ideal either.

There are other examples where we want to react to the termination of the program -- maybe stop accepting new requests and wait for active ones to finish?

What would be the correct way for the framework to support graceful shutdowns?

• Define app.start() method
• Add onStart hook that lets plugins set things up at app.start() time
• Reserve the loading phase for non-sideeffecty things like registering environment variables

We can extend the plugin interface in a backward compatible way to support several application phases:

1. Support app.initialize(). Once all plugins are loaded, the initialize method can be called. This method will in turn call every plugin which returned a method called initialize from its construction function. The method can return a promise.

2. Support app.terminate(). Similar to initialize but it will shut all plugins down. Analogously to initialize it will call a termination method on all plugins that have one

My main doubt about this design is how to make it clear which things go where, especially the config vs initialization phases. Perhaps we could support passing an object to load() in addition to a function - if an object is passed, it has to at least have an initialize method (that can return a promise), and it can optionally have a configuration getter that returns the env variables specs (once loaded it will be replaced with a cached property) as well as a terminate method (that can return a promise)

In order to add features such as logging and tracing, it would be nice if h4bff supported interceptors for the locator.

Motivation:

Lets say you would like to implement an XRay tracer that will give you a listing of all the service method calls for a request. You've made a tracing proxy that wraps a service method calls with the right xray xray logging calls. How to apply it to all service instances?

Sketch API / motivation

app.addServiceInterceptor((ServiceClass, oldGetter) => { 
  if (ServiceClass.traced || TracedClasses.has(ServiceClass)) { 
    return xrayProxy(oldGetter(ServiceClass)); 
  } 
  else { return oldGetter(ServiceClass); } 
})

This would wrap all services annotated with a "traced" property (or those explicitly added to the "TracedClasses" map) with a tracing proxy. Its sort of like a middleware system, but not to be confused with middleware - MW pertains to individual client requests (one per service context) while interceptors are for each service instantiation.

The locator should implement the current parentApp lookup logic via parentLocator. This is to avoid duplication of that implementation for services and singletons.

see:

https://github.com/hfour/h4bff/blob/master/packages/core/src/index.ts#L93

space for final design.

I noticed that RequestContextProvider.withRequestContext always creates new service context when invoked. This could be an issue when having nested calls, because of the multiple service context that will be created, which will lead to multiple transactions etc. I guess, we should reuse the same service context all the way.