If you mean as in not backed by an actual MongoDB database, then it won’t be consistent between instances if the servers are scaled-out (multiple instances).
If you just want to use a single server instance, or aren’t concerned about consistency, then it works fine - just use unmanaged collections, as these aren’t backed by MongoDB.
That’s a pretty neat idea. I’d been using node-cache, but of course that’s only a key-value store. My app hasn’t need to scale out yet, but I’ve abstracted away my use of node-cache to a package so that I can easily switch to something like redis if I ever need to.
edit: Minimongo on the server would be great if you could somehow use it with redis-oplog?
Yeah, actually this could be really, really useful for something in my app, but it would mean cache invalidation would get really tricky if I ever needed more than one instance…
I think I’m gonna need to do some benchmarks… I have a feeling node-cache is probably faster for writing/reading, but using minimongo would mean I get all the benefits of mongo querying. Right now I do a lot of iterating over values stored in node-cache.
You could do invalidations with publish/subscribe to the cache from a DB (by DDPconnect to localhost: say CacheServer to MainServer). And make publications to Webclients directly from the CacheServer.