Meteor Streams works fine for now, it’s just an outdated and dead project. It’s bound to cause problems later on as Meteor improves over time. We actually did build our own solution before Meteor came out using socket.io, but now we’d like to stick with Meteor as that’s a managed solution and has caused us far less headaches than in the days of node.js, grunt, etc. Integrating a solution like socket.io that runs simultaneously with Meteor is not an option as a socket.io server would require an extra port, breaking SSL. Also having two websocket servers is just absurd I guess.
Thanks for the example. I was not aware that one could publish on the server like that. Is the server still creating a mongodb collection behind the scenes? E.g. is the Ticker counter being persisted somewhere? I guess it doesn’t matter as long as it doesn’t impact performance, but I’m still curious to know.
The main problem we’re facing is that we mostly need to send single events to users. Consider a player that has attacked a monster. We’d need to send an attack event using the monster ID and the weapon ID they’re carrying.
Note that we don’t care about saving this event, or having access to previous documents. It’s just fire and forget. Using a local collection for this becomes hard unless we use an ‘events’ collection and publish it to each user, that acts as a message bus. I believe this is exactly what Meteor Streams is doing, except that it is outdated so we might take a closer look at your example. Thanks again!