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

Add support for interceptors #4

Open
1 of 2 tasks
dicko2 opened this issue Nov 3, 2020 · 0 comments
Open
1 of 2 tasks

Add support for interceptors #4

dicko2 opened this issue Nov 3, 2020 · 0 comments
Labels
enhancement New feature or request

Comments

@dicko2
Copy link
Contributor

dicko2 commented Nov 3, 2020

Feature request

Type

  • - Enhancement - completely new feature
  • - Improvement - make what we have better

Is your feature request related to a problem?

There's two use cases for interceptors that were left out of the initial library migration.

  1. Measurements
  2. Caching

Describe the solution you'd like

For caching the idea is that with an attribute you can specify to cache the response of a method, and give it parameters about local vs remote cache, time out, etc. This makes it very easy for developers to implement caching. This was left out of the initial implementation because of some tight coupling in the original code with couch base.

For measurements it's a form of auto instrumentation, so it will automatically measure the times of method calls in the class.

Additional context

I think there's an argument against implementing both of these. But happy for someone to prove me wrong.

The original requirement for these features came from a monolithic application that was incredibly complex.

Take the example of a aspnet app 3 tier design using repository pattern.

Http req/resp <-> controller <-> service <-> repository <-> database/external 

The argument against the cache is that you should be caching your requests or repositories, which would have a different implementation. If you have to cache mid way down your chain, at the service layer in this instance I think you have a problem, the reason we did it is because we had an large amount of services needed to serve a single complex request, and in changing things it was hard to think or understand the system holistically. In a better world your systems are smaller so you don't need this.

And in this better world of non-monolithic systems your auto instrumentation (measurements) can be done in the same place too (http request and external calls). And we have libraries like application insights that can do this for us.

So I don't believe either of these are the responsibility of the ioc container. But again happy for someone to prove me wrong.

@dicko2 dicko2 added the enhancement New feature or request label Nov 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant