-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache support #47
Comments
this issue was actually raised from another company too, they could not use unirest-node bcz of no cache. |
Thanks. Our current stop-gap solution is to call unirest, but wrap every call in a special handler to decide whether to make the call, cache the response, etc. Some built-in support would be amazing. |
This is not something that is within the scope of the library, this should be done outside of the library (a plugin would be fine, separate repo). |
This is the correct way to do it, as it is a per case basis, not everyone will have the same requirements or situation as yours. Hence why being a plugin would be a better solution for this situation. |
Fair point @nijikokun. About a "plugin", I can imagine two different approaches:
This is pretty much what we currently do, but it quite painful to implement if you want caching across the board. If we want an easy drop-in solution, we could create a library that wraps var proxy = new InMemoryProxy();
proxy.get('http://awesome/api')
.set('Accept', 'application/json')
.end(function(res) {});
This would let unirest.get('http://awesome/api')
.set('Accept', 'application/json')
.through(myProxy)
.end(function(res) {}); |
Also minor comment on |
Plugins could be hooked like middleware, global plugins, and local plugins, On Wed, Feb 11, 2015 at 4:39 PM, Romain Prieto notifications@github.com
|
👍 on plugin, which could be as simple as |
Closing since this was agreed to be a plugin |
Hi @Nijikikun, I'm happy to help write the plugin... is there a plugin interface / system already? I thought that was the current blocker (e.g. no |
I think I will open an issue to address perhaps a plugin specification, that way we can come up with something, I haven't had time to think about as of right now. Working on a new release with all these backlogged items |
Hi,
It would be great if
unirest
had support for a pluggable cache, just like the browser's local cache.I see many packages on
npm
that support specifying aTTL
for each request - but I'd much rather take advantage of HTTP and actually read the response headers, and cache the response in memory for the appropriate amount of time (eitherexpire
, ormax-age - age
).In a sense, this is very similar to a reverse-proxy. Do you think this could be part of
unirest
? Could it be some sort of plugin, where every request/response traverses the proxy and it decides whether to call the backend or returned cached data?If the interface is nice & clean, I could imagine several implementation of that proxy, e.g. in memory, backed by Redis... Ideally they would each have smart limits depending on their constrains (memory limit, number of responses, LRU....).
Happy to help implement this if you think it would be useful.
The text was updated successfully, but these errors were encountered: