Yes, since that is around time when 1.8 came out. Why should there be an update when there wasn’t a major release since?
Would very much love tight Typescript support
I’d love to see MongoDb multi-document transactions support. This is critical for small (and big) companies like us. I don’t understand that no one else is asking much for it.
Can only mean that that companies have turned their back to Meteor with MongoDb.
4 Likes
Do you mean a
MongoDB ACID transactions? That’s already being asked and it’s supported I think.
Yes, and It’s not supported, please see the thread
I did look at the thread you started and it seems that it does work using MongoClient instance, so as far as I can tell yes you can use it, but I guess you want it through meteor/mongo. Also, if big/medium size companies are using/waning it, I’m not sure why none of them contribute a PR for it, after all it is open source.
2 Likes
I can tell that it does actually works correctly, you just need to access the rawCollection and mongoInternals for the mongodb client.
I havent had any issues with it.
1 Like
We are investigating ways to make it possible to move some parts of Meteor core onto npm without making the installation process more complex.
Is there any update on this? I think i read somewhere that this won’t be possible in the near future due to how tinytest works and all internal package tests relying on it (can’t find the thread/issue though - it was a long time ago, when this first appeared on the roadmap in 1.3).
Wondering if the solution - refactoring tests to jest - used by aldeed in https://github.com/meteor/meteor/pull/9603 (fun fact, this pr has it’s 1 birthday in two days) as https://github.com/reactioncommerce/random is the way to go? For me the biggest pain point with meteor still is testing and especially integrating meteor in test-tooling when meteor is just a tiny part of the big application picture (we spend hours mocking/stubbing but still the meteor part is the least tested in our application).
1 Like
There are features in Meteor’s package system that makes a move to npm less than optimal. Modern builds would not be as efficient, unless some of the features of atmosphere were ported - such as delivering uncompiled sources, and probably also separate entry points. Meteor devs have been reluctant to extends npm this way (or maybe npm is not really set up for that, I don’t remember). We’d also lose other features like including non-js automatically, auto configured build plugins, etc. Unless something has changed I’m not aware of (very possible) I’m not sure I see how to move to npm without losing some of the benefits of modern bundles, and a few other things.
1 Like
I’d love to hear from any small/medium sized company that is indeed using Meteor. Apparently there are 17000 active websites with Meteor in the World right now, so could someone raise their hands?
I’d be keen to have a discussion on how we and other small businesses are using Meteor.
2 Likes
You’re guessing right. We do have over 1200 functions in our server code, changing way over 1000 MongoDb commands isn’t something that we want to do, especially being so close to launch (it would mean a big delay).
Yet, we do need the ability to rollback multi document transactions in case one of the insert/update/remove is throwing an error (or something else in the code).
2 Likes
I’ve got a couple of Meteor sites in production, all using Mongo through either ddp-pub/sub or methods. I haven’t switched to Apollo yet - I’d like to, but there’s a lot to set up with it. I have some ideas on how to make that easier in Meteor 2.0! It involves sort of deprecating pub/sub (or at least downplaying it’s role in most cases where real-time response and push is not necessary) in favor of a connector model (especially applicable to react apps), even with MiniMongo. Once that pattern is established, it should be relatively easy to convert or migrate over time to Apollo, since all that data code ends up in one place.
I have mostly avoided issues like ACID transactions (in favor of rapid shipment), although I think my containerized, almost flux data flow model would help there (since I’m not using or worried about pub/sub, going directly to the data tier to set up transactions should be easier). What other issues do you want to discuss?
For starters, we have written up what we’ve found out so far on how to get MongoDb multi-document transactions going: Provide access to the MongoClient for transactions & change streams #311. It would be good to have more support to get this project on the roadmap for Meteor because right now it’s not on their roadmap (no one is assigned/no milestone, nothing).
But I’d like to point out more necessary code changes should you follow the temporary solution that is currently the only possible route:
-
Create named exports for all collections that will use transactions using
Collection.rawCollection()and export them -
Add a call for a function that generates a string base _id using Random.id() for insert functions to and attach it to the object
-
Change all chain of execution (calling functions) to include transaction session variable from top invocation to lowest one
-
Change code for updates
const numUpdates = dbCollection.update()so it works with currently huge list returned -
Change
.map()queries to use.toArray()at the end so we get an array of objects -
Refactor code that uses
.fetch()to use.toArray()if they are using rawCollection only
That’s a lot of refactoring when you have 69,000 LOC for your server app only!
I’m pretty sure most of that could be avoided if MDG would include multi-document transactions into a future release.
4 Likes
Have you thought of creating a PR? I know that’s not generally a satisfying response, but it’s all open source. Having your team refactor 69,000 LOC sounds like a lot of work - it may be comparatively much less work to have them create a PR.
1 Like
Meteor just needs to be Meteor, the ultimate web stack.
My top three wishlist is:
- updated Mongo package - the changes in MongoDB 4.0 are worth it
- service workers - the timing is right as iOS is catching up to Android for PWA support
- that’s it - Meteor is great
19 Likes
I do think Atmosphere can use some attention! It’s kind of embarrassing right now, all the counters are off. Also, the UI is kind of clunky… I think something much simpler could be designed.
At least, the counters on the squares should be consistent with what is on the package page, and those fake trending graphs should go. Also, MDG packages should be removed from the Trending packages, obviously they will trend the most, but the real goal is highlight great third party packages. I’d even get rid of MDG packages from Most Used.
10 Likes
There was a bunch of talk a number of years ago about deprecating atmosphere in favor of npm as the new standard. But I think there are a number of advantages to atmosphere packages that make them work it, including but not limited to benefits for modern bundles. Npm packages all come precompiled.
4 Likes
That’s not a restriction on npm itself, you can have a build script run post-install. Quite a few packages that compile native binaries do this, since they must compile on the platform they’re being run on
Yeah, basically, Meteor build tool will always get better integration with its own packages than with NPM
2 Likes
I hope we will ever see a Meteor 1.9. Since it seems Ben is mainly working on Apollo now, leaving Meteor with nobody?
6 Likes