3 ms·

Show HN: Proof of concept – Realtime single page apps

69 points by jondubois 11y ago

Aeolun 11y ago
Oh, this is great! I'd been trying to get started with SocketCluster, but I didn't have much to go on. I could figure out lots of things, but examples are great!
mariopt 11y ago
The Proof of concept isn't new, having in consideration MeteorJs and other recent frameworks.
- zamalek 11y ago
  If you take the time to read the wall-of-text you'll find out that it's based on pub/sub and not RPC-esque like Meteor (which he also acknowledges in his wall-of-text). New? Probably not. Valuable? Not sure, pubsub is expensive but when you need it you really need it.
  - jondubois 11y ago
    Well observed. The problem with client to server RPC is that it's difficult to scale horizontally. When using pub/sub, on the other hand, you are giving control to your data consumers (frontend clients) so you don't run into issues of having to get references to specific users from your server (what if that user is connected to a different process/machine and not the current process?). I did a presentation a few weeks ago at my local JS meetup group which explained the issue better: http://slides.com/grosjona/realtime#/ http://slides.com/grosjona/realtime#/
    - jondubois 11y ago
      I'm not sure about the details of Meteor's RPC implementation so I can't comment on it specifically.
  - philippnagel 11y ago
    Doesn't Meteor implement pub/sub using DDP?
    - jondubois 11y ago
      DDP does sound similar to pub/sub. Maybe it's derived from it? Another approach for sharing realtime data between multiple client/frontends is via operational transform or differential synchronization but that is very expensive and it appears difficult to scale beyond a certain point due to latency (good for collaborative editing of rich text documents, but I'm haven't heard of it being used in other contexts).
      - jkarneges 11y ago
        I wouldn't say operational transform is an alternative to pub/sub. The two could be used together.
  - tinco 11y ago
    Meteor's DDP protocol is both pub/sub and RPC.
virgil_disgr4ce 11y ago
Curious what OP's general thoughts on Meteor are—obviously this is more modular and less tied to a specific (arguably monolithic) design model. It'd be really nice if [ungendered personal pronoun] made an ultra-simple walkthrough tutorial a la Meteor's ;)
trestletech 11y ago
That's really nice. I had faced a similar problem a while back and didn't solve the network layer as neatly as you have. But one feature I would miss from this implementation is event "bubbling." My approach is here: https://www.npmjs.com/package/giza https://www.npmjs.com/package/giza . It would just parallel your storage engine (whatever that is) and not the rest of the project. But I'd encourage you to consider how to subscribe to a channel hierarchy. I find that many of the event-driven projects I touch have at least some components that can be more neatly modeled under a bubbling pub/sub system like this.

69 points by jondubois 11y ago

Oh, this is great! I'd been trying to get started with SocketCluster, but I didn't have much to go on. I could figure out lots of things, but examples are great!

mariopt 11y ago

The Proof of concept isn't new, having in consideration MeteorJs and other recent frameworks.

zamalek 11y ago
If you take the time to read the wall-of-text you'll find out that it's based on pub/sub and not RPC-esque like Meteor (which he also acknowledges in his wall-of-text). New? Probably not. Valuable? Not sure, pubsub is expensive but when you need it you really need it.
- jondubois 11y ago
  Well observed. The problem with client to server RPC is that it's difficult to scale horizontally. When using pub/sub, on the other hand, you are giving control to your data consumers (frontend clients) so you don't run into issues of having to get references to specific users from your server (what if that user is connected to a different process/machine and not the current process?). I did a presentation a few weeks ago at my local JS meetup group which explained the issue better: http://slides.com/grosjona/realtime#/ http://slides.com/grosjona/realtime#/
  - jondubois 11y ago
    I'm not sure about the details of Meteor's RPC implementation so I can't comment on it specifically.
- philippnagel 11y ago
  Doesn't Meteor implement pub/sub using DDP?
  - jondubois 11y ago
    DDP does sound similar to pub/sub. Maybe it's derived from it? Another approach for sharing realtime data between multiple client/frontends is via operational transform or differential synchronization but that is very expensive and it appears difficult to scale beyond a certain point due to latency (good for collaborative editing of rich text documents, but I'm haven't heard of it being used in other contexts).
    - jkarneges 11y ago
      I wouldn't say operational transform is an alternative to pub/sub. The two could be used together.
- tinco 11y ago
  Meteor's DDP protocol is both pub/sub and RPC.

virgil_disgr4ce 11y ago

Curious what OP's general thoughts on Meteor are—obviously this is more modular and less tied to a specific (arguably monolithic) design model. It'd be really nice if [ungendered personal pronoun] made an ultra-simple walkthrough tutorial a la Meteor's ;)

trestletech 11y ago

That's really nice. I had faced a similar problem a while back and didn't solve the network layer as neatly as you have. But one feature I would miss from this implementation is event "bubbling." My approach is here: https://www.npmjs.com/package/giza https://www.npmjs.com/package/giza . It would just parallel your storage engine (whatever that is) and not the rest of the project. But I'd encourage you to consider how to subscribe to a channel hierarchy. I find that many of the event-driven projects I touch have at least some components that can be more neatly modeled under a bubbling pub/sub system like this.