Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Services and related work #30

Open
tmaiaroto opened this issue Jun 12, 2018 · 0 comments
Open

Custom Services and related work #30

tmaiaroto opened this issue Jun 12, 2018 · 0 comments

Comments

@tmaiaroto
Copy link
Owner

tmaiaroto commented Jun 12, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant