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

Provide a better way for caching #2

Open
PikachuEXE opened this issue Jul 15, 2016 · 1 comment
Open

Provide a better way for caching #2

PikachuEXE opened this issue Jul 15, 2016 · 1 comment

Comments

@PikachuEXE
Copy link

Other solution like JBuilder and RABL has some caching function built-in

And they do make the caching key different so that it won't collide so easily

@binarydev
Copy link

I would actually argue against adding this feature.

As shown in the README, implementing your own caching with Rails.cache.fetch (or a DalliClient for example in a non-Rails app) is dead simple, and I don't see a reason to slow down JB's processing time by having it calculate what we can only guess is the best way to hash your specific collection or object to form a unique key.

If your Rails.cache.fetch key is colliding easily, you should try changing up how you generate your key, perhaps with a more dynamic approach. At the object level, using "--" is good enough to start with, and at the collection level, using "-" can also be good enough. A single SQL query to select the MAX(updated_at) of a table for the collection cache key can be 0.1-10ms on average depending on your infrastructure, maybe 50-100ms if dealing with higher than normal network latency, shoddy web hosting, or GBs worth of data rows in a single table.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants