From what I read change streams are implemented by parsing the oplog, the difference is now the db can do it and be more efficient and granular.
I really hope we can get something close to RethinkDb but I doubt it.
Good call. And maybe a Docker integration best practice?
- Electron
- React Native
- MongoDB change notifications
- Docker integration
3 Likes
I was going to make a PM but then I thought it is better to answer publicly.
I read you like a npm/react maximalist. I agree this is good that meteor opened up to this new ecosystem, and imports are popular (I don’t think they are the perfect solution, I still think it kind of does the job today). What I regret is the lack of detailed guide from Meteor.
Meteor used to be the land of the noobie .
Now it is getting pretty complicated to get an access ticket (too many possibilities, not so many sources of truth)
We’ve heard this sentiment many times, I wouldn’t be using Meteor today if didn’t open up the rest of JS ecosystem, yes I was JS noobie but you don’t stay noobie for while and you start looking for more advanced stuff sooner than later. The language and ecosystem evolved since 2012, the import statement is language standard and it needs to be supported for NPM packages to work. NPM is the largest software repository and not having access to it is a huge disadvantage.
Beside the framework is still backward compatible which I find incredible. There are tradeoffs to choices, but all things considered, what we’ve today is far more mature then what we started with. So I hope you take a moment to a look at things for different perspective, not just those who’re starting, and try to see the platform within the context of the evolution of the overall JS ecosystem.
I find that a strange statement, Meteor has a detailed guide with its own repo which it didn’t have before 1.3 I think, you can contribute to whatever you think is missing.
With regards to future releases, if I’ve to choose one thing, I’d go with MongoDB change notifications, other things can be supported by the community with packages but this change is very core to Meteor.
7 Likes
Don’t get me wrong, I love Meteor as it is today, MDG has done great work so far, I also want Mongo notification integration, I cope with imports statement (even if I believe this has to mature, it is a good thing)
Now I just say that the whole ecosystem has expanded a lot, and the price to pay is that for a new dev to join the framework today, it is far from easy !
eager loading was easier, blaze was easier, there was no front-end schizophrenia (React, Vue, Angular2, Blaze? ==> Let’s go React, oh but I lose accounts-ui if I do that. Let’s go Blaze, oh but I lose SSR if I do that !!! )
Well if you are a noobie here, better run away to Next.js, even if less capabilities.
1 Like
This is by far the most upvoted feature request for Meteor but there’s no mention of it on the roadmap. The 2nd most upvoted feature (source maps in production) is also missing from the roadmap. Is this an oversight ? Would be great to hear MDG’s thoughts on 1.7 now that 1.6 is pretty much done and dusted (Great work btw! 
)
I don;t have much to add to what Alawi aptly said in the comment above, except to suggest:
- '‘how do i begin’ with meteor is really well covered in the 3 tutorials, meteor guide, and even for free on youtube, or paid courses elsewhere
So the problem may well be…
“how do i progress to the next level” - which is a true novice problem solved only by experience… ( === time spent solving issues)
- “how do i do…{issue}” which is why this forum
Here, answers are scattered around & reflect the myriad ways to achieve one thing - but are only a search away.
If worthwhile, perhaps the community could organise to add a ‘source of truth’ to the docs/forum section - MDG seem as open as can be to contributions. Maybe something like meteor cookbook which focuses on clinical use case - covering/curating in more depth around idioms/issues like SSR, dynamic imports, or cloudspiders brilliant AWS series.
Why these materials aren’t currently maintained in one place, is precisely because all the stack moves on… (yet Meteor itself remains wonderfully stable and praise and thanks to them for that) and time: people find a solutions, then move on with their project/business, etc.
2 Likes
Just to be sure it’s not a far-fetched statement, it’s 40x when I tried a 5 level nested query that retrieved almost 10,000 objects from db. For smaller queries and for real life scenarios I believe it will be just around ~1-3x faster.
+1 for change notifications. I really hope the guys at mongo node driver can do a proper implementation, because integration with Meteor’s LiveData would be relatively cheap ~20-40 hours of work.
Just read www.meteor-tuts.com this was the purpose of it, to simplify Meteor’s learning curve.
Regarding View Layer, it’s done go with React. It’s MIT since few weeks, there is simply no reason not to. I like Blaze more, but you can’t really match React’s performance and community, and plus, it takes you 20 hours to get used to it, from then on it’s much easier.
6 Likes
Service workers, http/2, and mongodb upgrades please!
4 Likes
Perfect - that should be pinned on forum 
2 Likes
There is a top level appcache plugin which even has the bones for offline support. That package implemented the defunct appcache standard, but the same package could conceivably be implemented on top of service workers, with a similar API. (Or it could be a new offline package which uses a similar interface, IDC).
It’d also be nice to have a top level service worker system of some kind (which a new version of appcache would utilize), since service workers are used for more than just offline caching (used for push notifications, etc.).
1 Like
People keep asking for this, but it doesn’t make sense. You can already use Apollo with Meteor, and there aren’t really any points where you could combine the two more tightly. It’s a bit like saying “we could start integrating Meteor and React further and further”. What exactly would that entail?
The one thing that could be improved though is Meteor Accounts. It’d be great to have an Apollo-only version of accounts that doesn’t use DDP or Minimongo.
But although this would be welcome, it also seems very far from the kind of work both the Meteor and Apollo teams have been doing lately.
5 Likes
Meteor and Blaze had these great end to end solutions for various things, like the user accounts system. It’d be nice to have some of that kind of stuff with apollo.
Apollo is a different animal though. It’s nicer when you need to power of a SQL backend, but it’s also harder to set up, and I wonder how you’d even do a database agnostic accounts system on Apollo, if that should even be a goal.
spot on!
The one thing that could be improved though is Meteor Accounts. It’d be great to have an Apollo-only version of accounts that doesn’t use DDP or Minimongo.
Once your application becomes bloated and you realise you have a monolith beast on your hands, the only hope you have is to split it into smaller apps. Divide and conquer.
An Apollo server seems to be the perfect tool to interconnect these new apps you are creating. In theory you could build Apollo on top of any technology out there, like express, but that’s when you realise that if you are relying on Meteor to handle authentication/authorization then you can’t do it. You are forced to have the Apollo server built on top of Meteor, forever.
It is currently really hard to have other apps to integrate well with Meteor, even with meteor-apollo-accounts. But that’s just one of the many use case favouring the full transition to npm.
Splitting Meteor’s parts into independent npm packages that work outside Meteor will open these to a broader audience and consequently will foment and speed up development, strengthening the whole by strengthening the parts. It is simply not sustainable to keep having a few leading the development of such a big project, something needs to be done to open the environment.
I don’t think that the “opening” of Meteor by moving it fully to npm is going to have the desired effect that you think. Yes, there are going to be few people that are going to pick the parts and maybe do some integrations to other frameworks or tools, but for every package that would be released from Meteor there are about 10 alternatives already on npm. What makes Meteor great is how easily these packages work with each other without the need to write any additional code. When moving to npm suddenly there will be a new issue of those packages having to play nice with the other major players out there, especially if you want to grow the community around those parts.
I do agree that overall it is probably a good idea, but I still have the above-mentioned concerns and that it might fragment things more than we need at this moment (aka the comments for more orthodoxy in technology selection).
But let’s do something about this then. We can start with identifying parts/packages that should be moved first to npm or that have the most to gain by this. Let’s provide a solution/path so that @benjamn and @abernix don’t have to everything alone. Maybe once we have some more concrete ideas on how to achieve this goal, then there is going to be more progress on it.
1 Like
A little while ago I dug in and researched what would be involved with migrating Meteor to npm. I went as far as migrating a few core packages, to get a feeling for the level of effort that would be involved. I can tell you with confidence that one of the first packages that needs to be migrated is not what you would expect - it’s TinyTest. I know, not very exciting, but this was one of the first roadblocks I hit during the migration process. TinyTest is used extensively by Meteor core, and unless we’re going to migrate packages over without tests, TinyTest has to be one of the first packages moved over. We could consider dropping TinyTest and switch over to using another testing framework, but that would not only require a substantial amount of work, it doesn’t work around the fact that TinyTest has some Meteor specific features (that Meteor relies on). To make matters more complex, TinyTest has other Meteor core dependencies, on things like ejson, ddp, mongo, etc. So attempting to migrate over TinyTest first will open up a very large can of problems, without having those other core dependencies in place. Unless of course TinyTest itself is refactored to remove core dependencies, but then is that really a great use of development time? Spending more time developing an internal testing framework, when there are countless other testing frameworks available? Wouldn’t that time be better spent trying to extend another testing framework, to replace the functionality TinyTest provides? Arg, too many questions!
It’s at this point I ran back to my loving/caring non-npm based Meteor and let it re-assure me that everything is going to be okay; we can still build and deliver awesome apps in record time, leveraging other npm based packages when needed, while at the same time using Atmosphere packages to help with Meteor specific things that npm doesn’t support. Thank you Meteor! 
15 Likes
I want Meteor to be not only easy to use and noobie friendly but powerful enough for big apps. So I’d like -
- like many have said, integrate mongodb change streams and updates
- higher performance for pubsub and more fine grained control. I think this is something that quickly becomes a bottleneck which is why there are so many attempts to solve this - subs manager, redis oplog etc
- a better deployment story - how to deploy and scale is still a very common question here
- integrate Kadira APM. Its now open source and is still pretty resource intensive, it should be part of Meteor and officially supported
- Apollo integration
- official docker support
A lot of these are tied together, my hope is Meteor can become more componentized and modular.
2 Likes
Disagree. Tried cordova web app with meteor, before a React Native one. UI performance doesn’t compare between Web and Native components.
1 Like
Oh yeah, that goes without saying. Moving Meteor’s parts to NPM would be a huge win.
2 Likes