Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.
What’s the Point?
February 12th, 2009
There are basically two targets:
- If you are needing a cache store that might potentially need to scale, you can use Moneta::Memory to start, and then scale up to Moneta::Memcache or Moneta::TokyoCabinet, etc. It’s certainly possible to do that right now, but you’d have to retool some of your code in order to do that. With Moneta, key/value stores are literally just drop-in-replacements for each other.
- More interestingly, libraries that want to provide sugar around key/value stores (e.g. Rails and Merb’s caching support) can use Moneta as their backend in much the same way as they use Rack to connect to web servers or use DataObjects to connect to backend databases. By providing a simple API, libraries can say “we support moneta stores”, and then any stores created by the community will just work. One interesting ideas that I heard from dkubb last night was moving DataMapper’s IdentityMap to be compatible with Moneta (pretty darn easy since Moneta’s API is a subset of the Hash API), and support plugging in other moneta stores. This would allow processes or even multiple servers to share an IdentityMap, providing a simple write-through cache. When potentially combined with something like Memcache, this could be a powerful combination.
- The bottom line is that by making key/value stores an abstracted idea, the community can build a slew of stores for Moneta, which will then work with whatever front-ends use them. The simplicity of the idea belies the potential power that comes from creating easy to understand APIs and letting the community at large take care of the actual implementaion.