Skip to content

Add support for interceptors  #4

@dicko2

Description

@dicko2

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions