Version 2.x Discussion

[jpodwys]

Explanation

This is intended to be a discussion area for breaking changes that anyone thinks should be made to superagent-cache. Please also present ideas that are not breaking changes that, for whatever reason, don't make sense in 1.x. I will take these suggestions into consideration when thinking about coding version 2.0.0 of superagent-cache. No coding has begun for 2.0.0, so all ideas are welcome. As the number of compelling ideas presented increases, the likelihood that a 2.0.0 release will be made increases. If no or very few ideas are presented, I'll just stick with 1.x.

Nothing posted here is for sure--this is discussion only. Please comment on existing ideas to say whether you agree.

Breaking Changes:

• Making superagent and cache-module-cache-service peer dependencies. This will allow users to select their own versions and therefore not download an extra copy of dependencies in the event that their application needs different version of dependencies than the ones superagent-cache currently pulls in.
• Change .pruneParams to .pruneQuery and .pruneOptions to .pruneHeader or something similar.
• Consider making superagent-cache active when calling ._end() rather than when calling .end(). This will prevent the odd redirects behavior I currently have to work around.
• ._end naming collision #52

Non-Breaking Changes:

• Keep all cache repos (such as cache-service-cache-module and cache-service-redis) in minor release sync. This will allow users to be certain which versions of all repos will play nicely with the others. However, it could also require frequent, unnecessary releases that contain no changes. (This is potentially unnecessary if I go with peer dependencies.)
• Cannot release 2.x without more reliable tests and better test coverage, including tests that run in browsers.

Other considerations

• I'm wondering if I should try to keep major version numbers of superagent-cache the same as superagent. This, however, would mean that I can't make another major release until superagent hits 2.0.0, which I don't like.

[redben]

Honouring server http caching headers ?

[jpodwys]

@redben That's a great idea! This can be worked into 1.x without any breaking changes. I'll keep this in mind when I have spare time to add the feature. I've created a feature request issue and referenced you in it here.

[jacobbubu]

Add statistics of cache hit, missed, expired... to the API

[jpodwys]

@jacobbubu that's a great idea! Are you wanting it to do pretty much what the link below shows or a lot more than this, or am I way off?

https://www.npmjs.com/package/node-cache#statistics-stats

[jacobbubu]

Well, more like this one https://github.com/rjrodger/seneca-vcache/blob/master/vcache.js.

[jpodwys]

Thanks for the link! Because superagent-cache takes advantage of swappable cache modules, it makes sense that this sort of statistics handling would go in each cache module. If done that way, it would be accessible via superagent.cache.SOME_NAME at whatever we decided to name it.

In fact, if you're using the cache-service-node-cache module with superagent-cache, you can already call superagent.cache.db.getStats() which would return the object I linked above.

Similarly, if you're using cache-service-redis, you can access the underlying redis instance by calling superagent.cache.db and then issuing the INFO command. The return value will have a "Stats" section containing at least some of the data you want.

However, if you're using the bundled cache instance (cache-service-cache-module), then we'll need to add statistics to that repo because they simply don't exist.