Closed Aupajo closed 9 years ago
That sounds logical, I was using Moneta and keeping a cached version of a meetup calendar response for 15 minutes. Quick and dirty solution really, but there are definitely better ways of doing it. Can we query meetup without being throttled, though a HEAD request or something?
My stuff is here - https://github.com/fourseven/almanack/commit/15ce3343f17062ec2113fdb49b3ddf6dea167d10
Can we query meetup without being throttled, though a HEAD request or something?
I wouldn't imagine so. Meetup would still have to perform a lookup to serve a cache header (etag/last modified) correctly.
Basic Faraday caching implemented.
Has the following limitations:
config.cache_responses
and config.cache_expiry
must be set before the Faraday connection is referenced and memoized for the first time.
In practical terms, this means these configuration options must be specified before config.add_meetup_group
or config.add_ical_feed
options are called.
I can see this being a gotcha for users. I'm strongly in favour of the idea that configuration order shouldn't matter, but that will require some tricky reworking to solve. In the mean time, it would be good to raise an error if these settings are called after the connection has been built at the very least.
So far, I've resisted depending on ActiveSupport
. I'm only loading ActiveSupport::Cache
, but should be easy to swap out for a smaller library.
@fourseven I saw you were hacking on caching, so I thought I'd open this issue to discuss options.
What I'd like to do is replace Net::HTTP with Faraday, and leverage Faraday middleware to handle caching, with optional persistence (preferably Redis, which is available for free on Heroku).