[SOLVED] Is there an existing way to use Memcached instead of MongoDB as Meteor's datastore?


#1

I’m curious to know if there’s an existing way to use Memcached in place MongoDB for Meteor’s data store. The reason for this would be so that it is temporary, not persisting when a Meteor instance exists.


#2

The Meteor solution is to use Redis rather than Memcache. Redis is supported by MDG, and you can find example apps, and both redis-livedata and miniredis repositories in the main meteor github account. Long story short… Redis and Memcache are similar technologies, with Redis being a bit newer and more node-centric. But for non-persistent caching datastorage, Meteor’s got a solution ready for that.

https://github.com/meteor/?utf8=✓&query=redis


#3

@awatson1978 Thanks a ton! What I was hoping for was that the Meteor.Collection API wouldn’t change, so that those codes would stay the same, and that behind the scenes things would save to the (alternative datastore).

This question relates to my other question: Any suggestions on best way to extend Collection and Cursor?

I’m hoping there to extend Collection and Cursor so that external endpoints will be checked when/if things aren’t found in MongoDB, but then later we’d like to switch to something like redis, and so I was hoping the Collection and Cursor API would stay the same.

Using Mongo, the call to something like myCollection.findOne({_id:123}).fetch() would internally check Mongo, if the item is not found then it would then query an endpoint to get the data, put it in Mongo, and finally return the document.

So it seems like if I want to use the current Redis tool I’d have to learn how that works first then extend/modify those functions instead.

I was planning on extending Meteor.Collection so that it could be instantiated with an endpoint URL like new Meteor.EndpointCollection('http://path/to/cats').


#4

But yeah, I think it’s a nice concept for the original Collection and Cursor API to stay the same, and for the magic to happen internally (independent of the datastore), because then backend guys can hack around, and front-end guys wouldn’t have to worry about having to rewrite their model code.