swagger-js
swagger-js copied to clipboard
List cases where cacheing is good vs bad in the resolver
We need to establish a cacheing policy that is safe and explicit ( and tested )
- Don't cache any try-it-out or arbitrary requests
- Cache http requests within a single
resolverinvocation - Allow holding onto a cache across multiple
resolverinvocations ( ie: external cache management ).
ping @fehguy @webron @buunguyen please ensure the list above it accurate. Once it is we can implement the tests ( and the implementation too ).
Is this the list of "all cache mechanisms we need to support"? Or are we supposed to pick a single cache strategy that works?
How about a 4th option: cache within the same swagger client instance. If users need new cache, they can just create a new instance.
@buunguyen I believe all hold true, and yes - I also agree with cacheing per instance. The importance of this issue is to make sure these cases are tested and accounted for.
@webron this is P1. I don't know what to do about this. Is there a bug that this would fix?
There is a bug, as far as I know. @ponelat should be able to explain it.
We cache resolver requests for the lifetime of the browser page. That is the primary bug. We'd also like to invalidate pieces of the cache, but that's a nice to have... and we can already do that in some ways.
We also see this in failing tests... where we cache results globally ( there was an outdated PR that tried to fix that ). To solve it there, we can just dump the cache after test runs.
I don't think this is a high priorty, probably P2? @webron
I just touched on this issue in my $ref interceptor PR - and needed to flush the cache after each test run: https://github.com/swagger-api/swagger-js/pull/1161/files#diff-910eb6f57886ca16c136101fb1699231R497
A per-instance cache would fix this. I agree with @ponelat, this is probably better as a P2 item (@webron).