Sacha Greif

Hmm, I don't know if it makes sense to migrate to something like Loopback. I feel like at this point we'd be more or less rewriting the entire framework from...

> Imo Vulcan should provide components that depends only on apollo. So we can choose whatever ui library and platform we prefer(next, fusion, cra, gatsby ecc) That's an interesting idea...

@gaurav- I think those are all great ideas, and if I was starting Vulcan from scratch today I might go that route. But at this point I just think the...

That article is pretty lazy, since it brushes over half of the MEAN stack (Express, Mongo, and arguably Node) and just tells you to use a third-party service as your...

@jay-jlm Migrating away from Meteor is not currently on the roadmap. I think it'd just be too much work at this point and would kill any momentum Vulcan currently has....

I started working on this here: https://github.com/VulcanJS/Vulcan/tree/connectors The idea is that instead of calling `Movies.find(...)`, you'll call `Connectors[database].find(Movies, ...)` where `database` defaults to `mongo`. In the future, we'll be able...

@sorenbs currently it would be a Mongo selector but eventually it could become a generic selector object that works for multiple databases. I guess that's actually another place where we...

Interesting. What's the difference between `update` and `patch`?

OK. And I'm assuming `params` in `get(id, params)` or `update(id, data, params)` is just some kind of options object? Yeah that seems like a sensible API to me, I'll go...

ok so this gives us: ``` Connectors.fooDB = { get: async (collection, documentId, options) => { return await ...; }, find: async (collection, selector, options) => { return await ...;...