I really like how Meteor works similarly on client and server, but one problem I find is trying to access the underlying infrastructure of sock.js and send information manually
There doesn’t really seem to be any API to stream data without also saving it to the database. null collections, for whatever reason, do not seem to work as intended.
It would be really nice to stream certain data to all connected clients in some more manual way, without reliance on mongo
what do you guys think?
The functionality exists: http://docs.meteor.com/#/full/meteor_publish
If you use the raw publication routines, it allows you to publish records into a named minimongo collection. The best part is that collection might only be named on the client, as in it’s established in code that is client only, so no collection is created on the server or in the actual mongo database.
There are several examples there that involve manually querying a mongo database and setting up observers that way, but those are only one option. You can put anything inside minimongo as long as you provide a unique string key for each one (to the second parameter of the various publication methods). That string key becomes _id in minimongo.
Ultimately there is another aspect to this: Meteor is working on a new project that will provide a reactive layer over graphQL allowing for connecting Meteor clients to almost any data source.
Oh really? I was always under the impression that if you did not want to persist the data, you make the collection name null
No - as long as you create the collection only on the client, you may still give it a name.
This has a use case for “roll-your-own” publications, because you can target a specific, named client-side collection.
Okay so here’s another question: if I have this event emitter, and I instance it on both the client and the server, how can I generate the unique ID which will match on both client and server? Will I still have to use mongo collections?
Then this will easily allow for this advanced publication
This is all done within the context of Meteor’s standard pub/sub. So, in your publication, you make use of this.added, this.changed, this.removed and this.ready - see the docs.
As you will see, when you use those methods, you also supply the id to use. When the document arrives in your client (via the subscription), that id becomes _id in the minimongo collection.
You can use whatever you like as the id - fixed or random string - depending on how you want to reference it.
Makes sense, but the problem I am wondering is how do you correlate the instance of a given class to its instance on the client? So say I have like, three event emitters. How do the events get delegated to the appropriate event emitters?
I tried using Random.id() in common code, but that becomes different on both client and server.
But these are unsynchronised - there is no server collection to be concerned about. Interestingly, I’ve just posted a repo as an answer to another question - it may help clarify things - or not 
!