0 voters
Apollo integration is coming close; what do you think you will once it’s ready?
For clarification: running any database means you would be happy to just connect your database(s) of choice, and work with them through Methods and/or some kind of nice wrapper. (I.e. MySQL, RethinkDB, etc)
What does “any database” mean? Is that some kind of solution with a rest API or methods fetching data?
Pretty much that - added a clarification to the top post.
Doesn’t Apollo include “the nice wrapper” option?
I do not think so, my understanding is that you would build something like an “application query,” which could/would be fed through various databases and data sources.
I’d suggest learning about GraphQL a bit - a GraphQL query is very similar to a method call, but with a bit more power to fetch nested data.
I hear ya - maybe I’m getting stuck in my ways at this point haha.
I actually really like the Mongo/LiveQuery stack… It’s covered all of my needs with no complaints so far.
Though, I would not mind good a RethinkDB integration just to get off oplog tailing. (edit: would like a lot - would be happy if it works with pub/sub and the rest were managed through methods. I know some people had set this up on their own.)
It does seem like there a lot more work in getting a GraphQL query to work compared to running a simple database query.
Maybe I am wrong, but I think a lot of stuff is being really over-engineered.
This is where I stand:
``> I’m happy with Mongo/LiveQuery for the most part (would love a performance boost, more scaling options would be nice and would like to at least have the option of easy-aggregation, aka JOINS),
``> it would be nice to run any database I want but don’t have the need right now (maybe if scalability becomes and issue),
``> I’ll consider Apollo after it lands and everyone has had a chance to judge its merits (but even still I won’t be in a rush unless there is a very compelling reason, also I don’t want to be roped into a service fee of some kind with Apollo), and
``> Open to new server side/database/middleware tech as long as it’s easy to integrate into my existing Meteor classic stack and offers clear benefits.
I’m planning for a combination of current live data mechanism and Apollo integration as a supplement in case of performance related problems.
We should care and empower livedata and current meteor staff.
@sashko incremental improvements aside, is there any plan to improve LiveQuery scaling/performance from MDG?
I’m sure LiveQuery is scalable and now we are not in the stop point
I’m actually thinking the opposite 
Agree with all the points here. I think Apollo also has a strong hype factor behind it because of GraphQL and React fans, and many are just looking for a Meteor-supported way to integrate other databases.
By the way what you work on?
What if LiveQuery had a feature for optionally refreshing subscription/publication in events from client,I don’t think about a Facebook like scaling but a bit more scalable for medium apps around 100k users by the help of galaxy multiple containers.
And about oplog, I know it is the bottle neck but isn’t there any possible contribution from MongoDb team for better reactivity support?
I’ve been doing that with methods + custom logic. Usually, I try to get an update and just patch the current data.
I know with subscriptions, you have an option to disable live updates. It would be cool if you could request the query to update, maybe you can, I haven’t looked into it too much.
At this point, I’m mainly relying on Methods plus local Minimongo collections for all my data stuff.
For LiveQuery stuff, pretty much the only company that is working on that is RethinkDB. From what I’ve heard, their whole approach was inspired by Meteor.
We worked on it before, with the result being these extra options: https://engineering.meteor.com/tuning-meteor-mongo-livedata-for-scalability-59327a144a9#.dl4cg6rsl
We’re not working on it more right now but we’ve heard from several companies that have come up with creative ways to scale it by redistributing load so that one server is handling many similar subscriptions.
Replacing or officially supporting Rethinkdb is the answer. I couldn’t agree more. The promise of meteor was dramatically simplifying client/ server communication with an optimistic UI. Therefore, I see the Apollo stack as regressive.
Rethink would solve the scaling issue. Their horizon project is awesome but young. Meteors maturity with rethink’s baked in change feeds is the answer. Rolling “MiniRethink” is far from trivial, but killing the scaling Monkey that plagues Meteor adoption would be a huge boon.
Note that this is much harder than it seems - rethink’s own framework, horizon, doesn’t support optimistic UI yet as far as I know.
Thanks for replying!
You’re absolutely right, it doesn’t. I’ve hand rolled an optimistic UI with MobX and Horizon.
The genius of your / MDG’s approach was mini mongo so you could reuse the queries. The difficulty of changing databases (or supporting others) with live query is high! I get it.
I’m developing an ambitious car dealership platform as a solo coder. I require an optimistic UI. Therefore, I need to stand on every set of shoulders possible.
I love Meteor, but I’m also not a CS Ph.d student… I’m scared that I don’t have the coding talent to architect a scalable Meteor application.
Apollo solves many great problems, but I don’t see that it advances the live query / optimistic UI issues.
I don’t think it’s mandatory for a RethinkDB to support optimistic UI. From what I’ve been hearing, many people actually prefer not to use it. If your app needs it, I think it’s better to do your own implementation for the specific place where you need it. That way, you can do your own implementation to get the exact look and feel you want.
Just saying because, if MDG is considering database wrappers down the line, it doesn’t all have to be reactive with latency compensation 
Looking at the results - it looks like we have a 50-50 split where some people are ready to jump on Apollo and others are looking to stick with the original ways.
I think that split is impressive, since Apollo was imposed by the vendor and has the React/GraphQL hype behind it. I think Meteor could benefit in huge ways from an alternative data layer.