MongoDB as a storage backend

[LeaVerou]

From @brundonsmith on May 18, 2017 3:28

When I first started playing with this I quickly thought, "this is amazingly powerful syntax; even as a professional web developer I'd consider using this for projects". Then it occurred to me that it would need to be possible to hook up a custom API for storage, which, I can see by a comment on the Smashing Magazine article, is apparently possible. But then I thought, "well, maybe all I actually need is a database". Since the data is already JSON, might it be possible to create a MongoDB storage option? That way it wouldn't require any custom code to hook up to an API, it would just work.

For clarity, the use case for this would be having multiple users, each of whose data is private to the other users. Github and Dropbox allow user permissions for editing, but all data is necessarily public.

Thoughts? Is this on the roadmap? Is it even feasible?

Copied from original issue: mavoweb/mavo#189

[LeaVerou]

From @aolko on May 18, 2017 11:49

Arango ~> Mongo #3

[tomByrer]

I was going to write a mega-list of additional options (GraphQL NATS, Dgraph, etc), but perhaps it is better to think of Mavo's architecture first?

Does Mavo have a 'state management' like Redux/Mobx/Flux/VueX? I looked around docs & source, & couldn't find anything except 'store' functions that seemed more like simpler load/save stuff. I'm wondering if a stage management library would already have data connection libs written for it, so add 1 Mobx (forexample) & get a bunch of backends for free/cheaper?

[mdxprograms]

I feel like mavo should stay simpler. Let the plugins do the work. I don't think Mongo should be core but a plugin. I think it follows an easier integration when actually needed and keeps core minimal.

[brundonsmith]

I definitely agree that it's important for Mavo to be watchful of feature creep. The thing that makes this little library special is its simplicity; if we kept adding features until it could be used to make production web apps, we'd just end up with yet another React clone that has an idiosyncratic syntax.

Given the above, it may be that supporting private data for multiple users is itself beyond the scope of Mavo. To which I'd say, yeah, that's fair. Even then, though, I think something like Mongo would be a natural fit as a storage option since it's already just JSON. It couldn't be that different from saving to a JSON file on a Dropbox.

I'm not yet familiar with the exact architecture of Mavo in terms of plugins, but that may be a good middle ground.

[LeaVerou]

We are definitely interested in multi-user apps, and indeed, those are currently Mavo's Achilles heel. Once Mavo can do granular permissions and incremental saving, the range of apps it will be able to make will explode, so I'm really excited about these directions.

That said, this is definitely not going to be in Core. Mavo is designed to be extensible exactly so that it avoids feature creep.

It couldn't be that different from saving to a JSON file on a Dropbox.

The main difference is incremental saving: Currently Mavo writes the entire file back. However, that should be relatively straightforward to implement, since there's an unsavedChanges flag for every node with unsaved changes.