Skip to content
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 API data #3

Closed
2 tasks done
marnen opened this issue Apr 2, 2020 · 11 comments · Fixed by #16
Closed
2 tasks done

Cache API data #3

marnen opened this issue Apr 2, 2020 · 11 comments · Fixed by #16
Assignees
Labels
chore Engineering task with not much direct user value
Projects
Milestone

Comments

@marnen
Copy link
Owner

marnen commented Apr 2, 2020

We'll probably cache API data for 24 hours.

@marnen marnen created this issue from a note in Development (To do) Apr 2, 2020
@marnen marnen added the chore Engineering task with not much direct user value label Apr 2, 2020
@marnen marnen added this to the MVP milestone Apr 2, 2020
@marnen
Copy link
Owner Author

marnen commented Apr 3, 2020

See also #10.

@marnen marnen moved this from To do to In progress in Development Apr 3, 2020
@marnen marnen self-assigned this Apr 3, 2020
@marnen
Copy link
Owner Author

marnen commented Apr 3, 2020

I'll go with Redis Cloud for right now as planned, though I suspect Google will be a better idea (if nothing else, their free tier gives more space). But the Moneta gem should mostly let us abstract that difference (famous last words, I know).

@marnen
Copy link
Owner Author

marnen commented Apr 3, 2020

Since we're doing Redis Cloud for the moment, I guess I'll set up a local Redis instance.

@marnen
Copy link
Owner Author

marnen commented Apr 3, 2020

Even better if it works: https://github.com/iainbeeston/faraday_api_cache. If not, I'll fall back to using api_cache manually.

@marnen
Copy link
Owner Author

marnen commented Apr 3, 2020

Well, that gem hasn't been touched since 2014, but it looks like https://github.com/sourcelevel/faraday-http-cache is maintained. Trying it.

@marnen
Copy link
Owner Author

marnen commented Apr 3, 2020

Nope, that doesn't support current Faraday. Something probably does, but I'll use api_cache manually if I have to.

@marnen
Copy link
Owner Author

marnen commented Apr 4, 2020

Looks like the version at sourcelevel/faraday-http-cache#116 should support current Faraday. Let's see if it works...

@marnen
Copy link
Owner Author

marnen commented Apr 4, 2020

I think I should first create a Faraday::Connection instance that underlies all API requests, then I can add caching to that.

@marnen
Copy link
Owner Author

marnen commented Apr 4, 2020

Unbelievably, it's hard to get the URL from a Faraday request before I make it. Considering switching to a different library (HTTP-rb?) so I can have more control of what requests I'm making.

@marnen
Copy link
Owner Author

marnen commented Apr 4, 2020

Incredible. HTTP allows you to build a request and see its URL, but then not fire it as far as I can tell, or to fire it but not see its URL. WTF? Anyway, rest-client may do the trick.

@marnen
Copy link
Owner Author

marnen commented Apr 4, 2020

It didn't, but after all that, Typhoeus will. Plus it may be nice to run 30 requests through the hydra at some point.

marnen added a commit that referenced this issue Apr 4, 2020
marnen added a commit that referenced this issue Apr 4, 2020
marnen added a commit that referenced this issue Apr 4, 2020
marnen added a commit that referenced this issue Apr 4, 2020
@marnen marnen linked a pull request Apr 4, 2020 that will close this issue
marnen added a commit that referenced this issue Apr 4, 2020
@marnen marnen closed this as completed in #16 Apr 4, 2020
Development automation moved this from In progress to Done Apr 4, 2020
marnen added a commit that referenced this issue Apr 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Engineering task with not much direct user value
Projects
Development
  
Done
Development

Successfully merging a pull request may close this issue.

1 participant