You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea of "Services" are really just handler dependencies that get injected, but also can be configured. This configuration happens with a closure that receives context and the event. So it allows for a great deal of flexibility with what gets injected into a handler.
Currently only the Cognito service (which is a more involved "helper" of the sorts) is used. The ability to add custom services is sorta there -- there's a Custom field on the Services struct, but it's not fully implemented. That is, nothing will get configured.
For example, look at what happens with the Cognito service:
if sCfg, ok := a.Services.configurations["cognito"]; ok && a.Services.Cognito == nil {
cognitoCfg := sCfg(ctx, evt).(*CognitoAppClientConfig)
cognitoCfg.TraceContext = a.TraceContext
cognitoCfg.AWSClientTracer = a.AWSClientTracer
The current Lambda context and event are given to the configuration function (held on
a configurations map). This allows the Cognito service to use that context and event to configure itself.
Currently, users could write some sort of configuration "New()" function and run it in each of the handlers they wish to use context and event data from...But that's not so much dependency injection. That's taking the event and instantiating a new service after the fact. We can make it a little cleaner. Not saying it's the only way it should be done or could be done...But it provides another option that may become more important when it comes to use 3rd party packages.
First off: Refactor the check for cognito service configuration. That should be in its own function that not only checks for that, but also other services.
Second: Also take into account Custom user services.
The following is how the Cognito service gets configured: AegisApp.ConfigureService("cognito", func(ctxcontext.Context, evt map[string]interface{}) { ... })
That should already work well for every other service in the future as well. Custom services should be something like ConfigureService("custom.myservice", func...)
That function adds to the configurations map which gets used in the base aegisHandler(). It just needs to work for more than just the Cognito service now.
So the groundwork is all in place. There's a clear path on how to implement these things, it just needs to happen. It was never really added. Though the intent for custom services was always there.
The priority? That really is hard to say, because there are ways to use and configure services for your handlers already. Just do it inside the handler. This is mostly an enhancement and quality of life improvement that allows you to write less code (or potentially share more code with others).
The text was updated successfully, but these errors were encountered:
The idea of "Services" are really just handler dependencies that get injected, but also can be configured. This configuration happens with a closure that receives context and the event. So it allows for a great deal of flexibility with what gets injected into a handler.
Currently only the Cognito service (which is a more involved "helper" of the sorts) is used. The ability to add custom services is sorta there -- there's a
Custom
field on theServices
struct, but it's not fully implemented. That is, nothing will get configured.For example, look at what happens with the Cognito service:
The current Lambda
context
andevent
are given to the configuration function (held ona
configurations
map). This allows the Cognito service to use that context and event to configure itself.Currently, users could write some sort of configuration "New()" function and run it in each of the handlers they wish to use context and event data from...But that's not so much dependency injection. That's taking the event and instantiating a new service after the fact. We can make it a little cleaner. Not saying it's the only way it should be done or could be done...But it provides another option that may become more important when it comes to use 3rd party packages.
First off: Refactor the check for cognito service configuration. That should be in its own function that not only checks for that, but also other services.
Second: Also take into account
Custom
user services.The following is how the Cognito service gets configured:
AegisApp.ConfigureService("cognito", func(ctxcontext.Context, evt map[string]interface{}) { ... })
That should already work well for every other service in the future as well. Custom services should be something like
ConfigureService("custom.myservice", func...)
That function adds to the
configurations
map which gets used in the baseaegisHandler()
. It just needs to work for more than just the Cognito service now.So the groundwork is all in place. There's a clear path on how to implement these things, it just needs to happen. It was never really added. Though the intent for custom services was always there.
The priority? That really is hard to say, because there are ways to use and configure services for your handlers already. Just do it inside the handler. This is mostly an enhancement and quality of life improvement that allows you to write less code (or potentially share more code with others).
The text was updated successfully, but these errors were encountered: