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
There's two use cases for interceptors that were left out of the initial library migration.
Measurements
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.
The text was updated successfully, but these errors were encountered:
Feature request
Type
Is your feature request related to a problem?
There's two use cases for interceptors that were left out of the initial library migration.
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.
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.
The text was updated successfully, but these errors were encountered: