2

I would like to send some data to a Meteor server, from a small bit of Javascript on a third-party domain. I would like to send lots of small things, as they happen, so I would like to use an io-socket.

I can imagine a few ways of doing this:

  1. Connect to meteor's socket-io and "piggyback" it. Send custom events (namespaced to avoid collision), and somehow catch these on the server side. But I can't find the socket object to attach to on the server!

  2. Connect to meteor's socket-io, and pretend to be a meteor client. Catch messages with standard meteor functions on the server side. Is it possible to talk like a meteor client without a lot of protocol?

  3. Open a second IO socket listener on the server, and have clients attach to that. For that I would need to find the 'app' object.

  4. Run a completely separate Node process and have clients talk to that; it could save in the same MongoDB that Meteor uses. I could do this, but I liked the idea of keeping everything in one process. Also, I'm not sure if it would fire update events in Meteor.

I would really like help with #1: Where can I find the iosocket object on the server?

Failing that, is #2 feasible? How can I talk like a Meteor client?

joeytwiddle
  • 29,306
  • 13
  • 121
  • 110
  • For #2, it seems a DDP client library may help. http://stackoverflow.com/questions/14174281/ http://stackoverflow.com/questions/15931368/ – joeytwiddle Jul 16 '14 at 16:04

1 Answers1

1

You mentioned some good options, and the DDP client is probably the most robust way to go. However, you can just set up normal Node.js REST API endpoints using the webapp package (meteor add webapp).

WebApp.rawConnectHandlers and WebApp.connectHandlers are just instances to which you can attach connect/express middleware or handlers.

If you write to the MongoDB directly, it will fire events in Meteor, as long as you set up the oplog observe driver.

Andrew Mao
  • 35,740
  • 23
  • 143
  • 224
  • Thanks for the observer suggestion. Whilst robust, the disadvantage of DDP over piggybacking is that it will bloat the client a little, and tie us into that protocol. I have played with the `rawConnectHandlers` a bit, and they seem great for piggybacking http, but I'm not sure I can get any access to the iosocket stream that way. #4 and oplog seem like a good alternative, especially if we decide not to stick with Meteor in the end. – joeytwiddle Jul 16 '14 at 20:37
  • Meteor is just using SockJS for client/server communication. That is distinct from using regular connect handlers. Sometimes SockJS drops down to XHR long polling when websocket isn't supported, so it's not going to be necessarily any faster hooking into it. Are you sure you're not just prematurely optimizing here? – Andrew Mao Jul 16 '14 at 20:45
  • I want to send lots of small updates intermittently, so where possible I would like a push stream from the client to the server that stays open. But I probably *am* guilty of prematurely optimizing. I could focus on a working prototype and worry about streamlining it with crazy piggybacking later... :) Just wanted to start the research early! I could use plain http for now, and batch the updates to avoid overhead. Thanks again. – joeytwiddle Jul 16 '14 at 20:54
  • My assumption is that when a WebSocket *is* being used, the connectHandlers are bypassed and not called. They are *distinct* as you say. (Although they might be called during XHR.) But if my assumption is wrong then please let me know! (You made me consider that perhaps incoming socket messages are converted into connect-style requests, for a consistent layer to receive events.) – joeytwiddle Jul 16 '14 at 21:16