MongoDB 3.6 looks really promising

announce
1

I just noticed this thanks to @hwillson in another thread but thought it deserved it’s own.

The new features coming in MongoDB 3.6 look great and could make a huge difference in Meteor. Check it out here.

@mitar has already created a feature request to support the notifications API, which could be a massive win for Meteor apps. So go upvote it !!

Would it be feasible for Meteor to have support in place for when it’s released at the end of the year ?

14 Likes
2

I couldn’t agree more.

Also the better array handling. Update multiple documents in an array is now simply not possible. This is something that I’ve been waiting for, for a long long time.

https://jira.mongodb.org/browse/SERVER-27089

3

For that, there is FR here: https://github.com/meteor/meteor-feature-requests/issues/125

5 Likes
4

These changes in the Mongo driver: Wire Protocol Compression, OP_MSG, Sessions, Retryable Writes, Causally Consistent Reads, and Notification API coming to Mongo via 3.6 will surely solve scalability issues in Meteor if implemented correctly.

5

So does the Notification API mean that we can get reactive aggregations in Meteor then?

2 Likes
6

That would be great but it looks like you can observe changes on a collection only.

1 Like
7

I think the Notification API would be a huge win for apollo-server. Scalable subscriptions without Redis :sunglasses:

5 Likes
8

Meteor needs to be updated to 64 bit before Mongo 3.6 support can be added? Is there a spot where we can get updates on this effort?

Also, what changes need to be made to Meteor for it to take advantage and utilize the new Mongo 3.6 feature set? And is there a spot where we can track this effort too?

1 Like
9

Sure is!

5 Likes
10

easier to implement subscription too I’d think?

11

I feel obliged to comment on this thread…

Want.

13

Approach or implementation? Because rethinking the approach is already done in the Apollo work. But for those (like me) who like the existing approach, I am more interested in improving the implementation of the existing approach, and not rethinking it.

4 Likes
15

Do you have any examples of potential issues with the current approach? I can think only few:

  • performance/scaling (hopefully change notifications fixes that)
  • memory footprint (more control over control box caching could solve this)
  • limitation to MongoDB (Apollo is working on that)
  • some people want deep-field diffing (that is mostly just a question of trade-offs and somebody proposing a good implementation)
  • resolving of conflicts with something like operation transform (I have never really seen that this would be needed on a database level, but maybe having something out of the box to support collaborative fields might be interesting)
  • having more control over write and read concerns

Anything else?

16

IMO, the first 3 points are the key. And change notifications addresses the first one directly, and will enable more effective horizontal scaling of Meteor server (which will indirectly help with the second point). Together with the retryable writes expected benefits and the better array handling targeted for Mongo 3.6, that will mean that Mongodb will be better suited for more use cases than currently, also helping with the third point. Address the first point with notifications API and provided Mongodb delivers as expected, that will take Meteor/Mongo apps well into the twenties…

3 Likes
17

Meteor 3.6 does look good. It’s like a whole new product!

The data-loss problems have been fixed in Mongo 3.4, but Meteor 1.5 is only on Mongo 3.2, so

distributed Meteor apps can still lose data!

An upgrade to at least 3.4 would be great!

1 Like
18

@trusktr Have you heard wether or not 3.4 will drop in 1.6?

19

@aadams Mongo 3.4 is held up by meteor/meteor-feature-requests#152. We’ve been working out the best approach for removing 32-bit Meteor support, and have a plan of attack in place (based mostly on these items). That work will be done off of the 1.6 release branch, but it’s a bit early to tell if it will be included in 1.6. Release 1.6 already includes a significant amount of changes, so Mongo 3.4 support will likely come in a future 1.6.x point release.

6 Likes
20

Oh my, this is lovely. I remember how Kadira used a separate Mongo cluster just for realtime metrics, because Node.js wouldn’t be able to keep up with a massive oplog. The notification API would be a great way of scaling Meteor without such painful architectural choices.

1 Like