Nest: Feature Request: Ability to configure excluded endpoints for Cache Interceptor

[jamshally]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

The Cache Interceptor applies to every Get endpoint in a Controller with the @UseInterceptors(CacheInterceptor) applied to the Class.

Where the Cache Interceptor is configured globally, it applies to every Get endpoint in the entire application.

Expected behavior

It would be convenient to be able to configure Cache to be globally on, but be able identify specific Get endpoints where it does not apply.

What is the motivation / use case for changing the behavior?

I would like the convenience and consistency of a globally applied cache for read requests - with the ability to identify endpoints that are not cached

[kamilmysliwiec]

Hi 🙂
It should quite easy. Simply extend CacheInterceptor:

@Injectable()
class HttpCacheInterceptor extends CacheInterceptor {
  trackBy(context: ExecutionContext): string | undefined {
    const request = context.switchToHttp().getRequest();
    const isGetRequest = this.httpServer.getRequestMethod(request) === 'GET';
    const excludePaths = ['path1', 'path2'];
    if (
      !isGetRequest ||
      (isGetRequest && excludePaths.includes(this.httpServer.getRequestUrl))
    ) {
      return undefined;
    }
    return this.httpServer.getRequestUrl(request);
  }
}

Perhaps, we should provide an example in the documentation

[jamshally]

@kamilmysliwiec - thanks for the reply and example.

For me, I think it will be easier and more maintainable to create a NoCache decorator, that can be applied to the desired endpoints (and honored by the HttpCacheInterceptor).

LMK if this is something you would be interested in for the NestJS common library, and I can have a go at creating a PR for this.

[kamilmysliwiec]

I'm somewhat afraid of new decorators, to be honest. Looking forward to hearing what the community think about this particular use case 🙂

[marcus-sa]

I have no problem with new decorators and features, as long as they're not in the core package.
Be careful the common package doesn't get bloated with useless features for a lot of people, instead it should belong in their own official package, such as @nestjs/cache

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.