Helper for fragment caching server rendered react components about react_on_rails

[andreasklinger]

We add the hash of the webpack main.js and the hash of the serializers to the cache checksum

    def fetch_component(name, args, options, &block)
      Rails.cache.fetch [webpack_checksum, name, Digest::SHA1.hexdigest(args.to_s), options], &block
    end

    def serializer_checksum
      return @serializer_checksum if @serializer_checksum.present? && !Rails.env.development?

      digest = Digest::SHA1.new
      serializer_files.each { |f| digest.file(f) }
      @serializer_checksum = digest.hexdigest
    end

    private

    def serializer_files
      Dir.glob(Rails.root.join('app/serializers/**/*.rb'))
    end

    def webpack_checksum
      return @webpack_checksum if @webpack_checksum.present? && !Rails.env.development?

      @webpack_checksum = Digest::SHA1.file(Webpack.local_asset_path('main.js')).hexdigest
    end

better ideas welcome

[justin808]

@andreasklinger Looking at the code, I'm guessing that you include the serializers because your "args" are not the JSON props (Hash or String) being passed to the component. Any chance that you could elaborate more on your inclusion on the serializers and if there were any performance hot spots in computing the digests.

[justin808]

Hash Speed

Interesting discussion here:

1. http://stackoverflow.com/questions/3665247/fastest-hash-for-non-cryptographic-uses
2. http://programmers.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

 Name            Speed       Q.Score   Author
 xxHash          5.4 GB/s     10
 MumurHash 3a    2.7 GB/s     10       Austin Appleby
 SpookyHash      2.0 GB/s     10       Bob Jenkins
 SBox            1.4 GB/s      9       Bret Mulvey
 Lookup3         1.2 GB/s      9       Bob Jenkins
 CityHash64      1.05 GB/s    10       Pike & Alakuijala
 FNV             0.55 GB/s     5       Fowler, Noll, Vo
 CRC32           0.43 GB/s     9
 MD5-32          0.33 GB/s    10       Ronald L. Rivest
 SHA1-32         0.28 GB/s    10

xxHash

Possibly xxhash could help?

• https://github.com/Cyan4973/xxHash
• https://github.com/nashby/xxhash (C version with Ruby Wrapper)
• https://github.com/justinwsmith/ruby-xxhash (Pure Ruby version)

Background articles

• http://api.rubyonrails.org/classes/ActionView/Helpers/CacheHelper.html#method-i-cache
• http://www.nateberkopec.com/2015/07/15/the-complete-guide-to-rails-caching.html
  Redis is probably the best store for a distributed cache.
• https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works

Rails Source Code References

• How cache keys are created in active_support/cache.rb
• Implementation of view caching: actionview/helpers/cache_helper.rb
• Where Rails source uses Digest::MD5.hexdigest on view partials in actionview/digestor.rb

@andreasklinger

1. Did the hashing come up as any performance bottleneck? Rails source uses md5, google search reveals that fastest might now be xxhash.
2. Look at your code again, I'm guessing that the "args" are whatever makes sense for your caching and not necessarily what's used for computing the props.
3. It's clever how you preserve the cache if your main.js stays the same along with all your serializers.

[justin808]

We'll add a view helper method for creating a cache key in the near future. This will be a nice addition for this gem.

[lfittl]

@justin808 You are correct that we choose to use the args vs the serializer output because of the slowness of computing the hash (I'm the one who wrote that code, its been a few months though).

This was especially obvious when you assume that both the cache output and the pre-render output are cached (based on the same initial serializer input args), in this case you'd want to minimize overhead.

However I think it'd be fine to re-evaluate the use of a hash method here - I think we tried sha1sum of the JSON serializer output at one point, but using the original arguments was the easier choice.

[justin808]

@robwise @alexfedoseev @dylangrafmyre This "issue" is relevant for our upcoming incorporation of fragment caching. We should aim to create a generic helper function, possibly part of our upcoming "React on Rails Pro" premium subscription.

[justin808]

This will be solved by the hashes of the files from webpacker. The key is that the JS bundles will have to be separated, and the cache call will requiring specifying the dependent bundles.

[corsonknowles]

What's the status on this? I am investigating memory issue (~leak) in our app coming from gems and have narrowed it to either this or Delayed Jobs

Reference: https://github.com/ASoftCo/leaky-gems/blob/master/README.md

[justin808]

@corsonknowles A helper for caching is definitely doable. We haven't had enough users like you asking for it.

I'd be happy to work with you on this if you like.

I don't have any comment on the memory leak other than tons of apps are live on React on Rails and nobody is blaming it.

[corsonknowles]

Thanks! Our memory issue spontaneously resolved during refactoring to move to Rails 5.1.4, but it was almost certainly related to Delayed Jobs and not server rendering.

[mapreal19]

what about having the react component helper to support caching (passing cache: true)?

cc @robwise @justin808

[robwise]

I think it's a good idea, that way checking the server bundle can be done automatically under the hood if cache: true and prerender: true are both passed.

[justin808]

Caching is a part of React on Rails Pro. Contact [email protected] for more info.