[Poll] What do you prefer: Mongo/LiveQuery, Apollo, or just native DB support?

As for the case for database wrappers;

MDG’s most popular tweet may have been a pre-emptive announcement for SQL support. The stats are dramatically higher than other tweets. Perhaps supporting SQL would do more for their adoption than convincing us to use Apollo.

The story is similar with RethinkDB… I think pretty much everyone who is still in the Meteor camp wants it. The database solves Meteor’s number one problem which was scalability. However, there is no support.

From where I’m standing, it looks like customers are asking for one (or a few) things but are being offered something completely different.

2 Likes

I’m missing one important option in this poll:

  • I’m sticking with Mongo/LiveQuery and use Apollo where it’s a better fit

You can perfectly combine the two and put results from Apollo in a ReactiveVar/ReactiveDict/Minimongo so it works just fine with Blaze. This poll gives the impressions that theirs no way they will work side by side…

Have you tried Apollo with SQL yet? You might be surprised how simple it is. Yes it’s different then what you’re asking for, but from where I’m standing, that’s a good thing. People can have SQL support, right now, with a beautiful API and integrated in Blaze, React, Angular and more. Working nicely in Meteor. Or… we can wait for a Mongo-like integration with every database out their and we might have something nice in 2019.

In my opinion MDG made a good call here. It’s just hard to accept the changes all the time.

*indeed, he probably never said that but it fits anyway :wink:

3 Likes

That nice wrapper is called Apollo/GraphQL. So 48% + 22% = 70% would be happy with Apollo.

Yes, I just had to do this.

That’s why Apollo isn’t reactive by default, and doesn’t have automatic latency compensation :] I’m just saying in terms of bolting on another database onto DDP, it’s not that simple.

Meteor is pretty decoupled - the frontend systems are separate from the build process are separate from the data stack. Please feel free to build your own, or extend the current one to more databases! When we built the experimental SQL packages, it didn’t require any changes in Meteor core at all.

I’d hate to make it seem like we’re the gatekeepers to some technology you want and can’t have – in fact the package extension model is super powerful and you can do almost anything. There are a lot of SQL packages out there that many are successfully using in production. If there’s anything we can do to make your life easier when building a new and different data system, let me know.

We have our current priority, which is developing a set of GraphQL tools, which you can decide to use instead of Mongo/Livequery/DDP. If you are interested in building and maintaining DDP hooks for other databases, that sounds cool as well!

3 Likes

This article was suggested for me.

The article really helped my Apollo ignorance. The GraphQL subscriptions take away a lot of my objections.

1 Like

MDG is offering something other than what some in the community are asking for simply because they need additional revenue.

We only become customers when we purchase their products, not when we use their free framework/tools. The latter leads us into the former of course. But if the former isn’t enough, the latter must change.

Please Note: I hope the above sounds politically correct and abstract enough, if not, please PM me and I’ll make touchups as needed.

On the other hand, some may not be asking for what’s coming, but that doesn’t mean what’s coming won’t be good to start, and great in the long run – potentially better than what we have now. Too early to say either way.

Would be interested to hear more about scaling live query and how they did it.

1 Like

Would love to see Blaze support GraphQL support too

2 Likes

Well, for the record, I think the Apollo/GraphQL option is great for some cases, and MDG did good by jumping on the opportunity. The timing and positioning was perfect.

We can argue the advantages and disadvantages of GraphQL, or agree that just like everything else, it has its place but not for everyone.

However, I worry that Apollo is actually a pivot. These monthly download stats can tell you quite a bit:

  • Vue.js 127k
  • Meteor 32k
  • Apollo-Client 14k

My worry is that all the energy will shift, if not already shifted, to what will become a Facebook stack, and the slow demise of Meteor.

Good points. Could you please clarify this one? From what I’ve been with other developers integrating other data sources, it’s a matter of installing an NPM package and configuring it just like any other.

If Vue and Apollo are from NPM and Meteor is from… somewhere? Those can’t be compared at all. NPM download stats are incredibly noisy.

Sure. But then you don’t really get any of the benefits of using DDP to manage your data. But if you don’t need that stuff then it’s totally fine.