Determine which area you want to contribute in (specific packages, Meteor itself, community organization, docs, etc.)
If packages or Meteor itself, go to that repository and familiarize yourself with the contributing guidelines and the code.
2a. Optional, but highly recommended, familiarize yourself with the key people in the project.
Take on an issue that you have in your project or a small issue that you can do. Don’t be afraid to reach out and ask the maintainers to guide you.
Create a PR with your contribution.
Repeat, get involved in the issues discussions, and so on.
Each project is a bit different, but the key is to start solving issues and contributing. Another option is to sponsor the maintainers and get involved in the discussion about the directions of the project. Feel free to reach out to me in PMs if you have specific ideas in mind and want more directions.
I think another package that we should recommend for people to move away from (over the long term) is underscore. There is an ongoing effort to remove as much of it from core packages and update our Meteor version to a newer version (though there are still some bugs). The issue being that often you can get the specific function from NPM packages and there is also:
It depends on what you are doing. For some database operations, you want an “opt out” option. An example: If you remove a huge amount of temporary data (f.e. 100.000 documents or more) at once, your Meteor application will crash. Why? Because Meteor will process every single remove event when you use the integrated oplog integration. With redis-oplog, you can call remove via the native database methods (collection.rawCollection()). In this case, Meteor will “ignore” the removed documents because the updates are not sent to the Redis instance.
Hi, I only use rawCollection throughout my whole data heavy backend app, since many years before Meteor added transactions. So guess what, what you described isn’t a problem at all for me.
I mostly don’t and it’s not needed. There’s some data that is sent from the Backend app via the “StreamyMsg” package that informs the Frontend about data updates which is then displayed, so that’s eg used on progress bars or to update displayed data.
My app is very data heavy as it keeps DNA data but there aren’t many concurrent users (but data grows fast from those few users) which some other people have at the opposite site of the spectrum of apps (meaning several thousand of users accessing more or less the same data). So the M10 Atlas server was always fine with it, even during peak times it never broke a sweat.
Remains to be seen if that scales in the future or if I need to add Redis-Oplog at some point in the (far) future.
My whole point of my answer was that there’s isn’t one single use case in Meteor apps and everyone has the volume that they need Redis-Oplog. On the contrary I think, my guess is that there are many smaller apps in Production that can achieve the necessary reactivity whilst avoiding pub/sub like Count Dracula avoids the sunlight
Hence my view that there’s nothing wrong with keeping Redis-Oplog out of the Meteor core for now and keep Changestreams in view in the meantime as an alternative, or whatever changes might happen in the future.
Im summary, you are not using Meteor’s reactivity. With the same logic in your conclusion, you do not even need the pub/sub feature in core, whether it is oplog-tailing, changestream, or redis-oplog.
For apps that do not need pub/sub at all it would be prudent to question the choice of Meteor in the first place. If in a Meteor project data is only transmitted over methods, a stateful connection still needs to be set up by default. Why not just use REST in that case with a more widely used framework? REST scales better than anything else, is easy to maintain, easy to reason about and debug, easy to set up and scale infrastructure (no sticky sessions), it is as future proof as can be (most of the web works on http requests and will continue doing so for a long long time) and is language agnostic (most back end languages have everything in place to support http servers). And above all, it is as standard as can be, meaning infinite pool of devs can hop in and start work on the project at any time. And for front end work for such projects, Next, Nuxt & co are and will remain infinitely more widely used technologies than Meteor.
This is not to say that Meteor should only be used for projects involving pub/sub. There is value in other parts of Meteor as well. Such as the accounts system. However, let’s not kid ourselves here. Choosing Meteor comes with a hefty price - requires specific knowledge, sets limits on scalability, forces mongo etc. And the main reason why people are willing to accept this price is that pub/sub is inherently complex and alternative solutions for pub/sub, those few that do exist, come with an even heftier price.
Pub/sub is the main thing giving an edge to Meteor. No other open source framework has delivered pub/sub in such an elegant and usable form. Yes, devs should consider carefully where to use pub/sub. And yes, for most apps the majority of data should flow via methods and pub/sub should be used only where reactivity actually has real UX benefits. But at some point the often used phrase “just do not use pub/sub” has gotten old. Since we are dealing with Meteor projects here, it can be assumed that most projects do need it in one form or another.
Since pub/sub is key to Meteor’s value versus other frameworks, it makes sense to consider options on how to solidify that advantage even further. Making use of redis-oplog seems like a good option to me.
The points you bring up are going OT hence I won’t respond much, just that pub/sub was never a reason for me to choose Meteor. The integration with MongoDb was surely one.
But like I wrote, not every Meteor app has the same needs.
We are relying on publish-composite for quite some pubs. And yes, we use it in a reactive manner. If it was removed, I would love to see tutorials on how to replace it.
To manage reactivity and consider related documents, I prefer peerlibrary/meteor-reactive-publish. Its code integration aligns easily with a standard publication by wrapping relevant sections with this.autorun . While reywood:publish-composite forces you to shape the publication distinctly, making the creation of generic and reusable utilities more difficult.
However, a drawback is that the library is no longer maintained, and its dependencies, along with being written in CoffeeScript. In the future, I might convert it to JavaScript, upgrade to version 3.0, and customize it to suit my specific requirements.
Anything with reactivity impacts badly on performance, so is better avoid or be wise on where to use it, above all if it requires tracking related documents. Having redis-oplog, or the recent changestream-to-redis solution are great for this. I love these packages and definitely I will still need them.
