athal7 / thermos Goto Github PK

Hi!

I came across this gem while looking up possible names on rubygems.org 😅

And I thought: awesome! A Rails cache warming gem that is up to date and not abandoned, but...

Maybe I don't get the overall intent, but what I am looking for is an even simpler API that would allow me to refresh model partial fragment caches upon changes.

Some model concern that could simply be included, optionally register which partials/views are dependent on it and refresh the cache fragments for them.

class Post < ApplicationRecord
  include Thermos...

  keep_warm_for "posts/_post", "users/_posts"

  ...
end

Would something like this be doable with Thermos?

Would be really cool if we could declare dependencies as nested associations for those far reaching models.

E.g.

Thermos.fill(key: "api_categories_show", model: Category, deps: [:category_items, products: [:variants, prices]])

I think right now it looks for any reflection that is for the model in question.

The current test cases don't cover this since it would require a second cache for a model that has a dependency for an association not a dependency of the first cache model

e.g. if different caches are desired per experiment or for a specific person / authorization, is that something that can be handled within thermos? Or is is necessary to do conditionals outside of the cache definition

If we are updating a model in a transaction. Say, the update is performed, saved to DB, but then the DB transaction is rolled back, thermos still regenerates the cache even if the transaction is rolled back.

In most use cases, the cache regeneration block would perform a db query and would not be receiving the changed data from the DB. So, that operation would not result in a cache entry with invalid data being generated, but only a small performance hit

Relying on an instance variable of the module seems less than ideal

Maybe put more information on beverage off the bat

in case the param uses a slug instead

e.g. for expires_in

Some caches may take a while to rebuild, and services such as heroku kill any processed that run over 30 seconds

It will be better to do this in the background for performance concerns on write