search

workshopper / list

A central catalog of existing, planned and requested workshoppers
14 stars 7 forks source link

Workshopper for web-sockets (with socket.io?) #28

Open martinheidegger opened 9 years ago

martinheidegger commented 9 years ago

I have been asked at the NodeSchool Osaka tonight about a workshop specifically for socket.io. I was shocked to find that it doesn't exist. Probably there should be one at least on that topic. Isn't this one of the most-common uses of Node.JS?

afronski commented 9 years ago

@martinheidegger We were shocked as well, the same question appeared at NodeSchool Silesia meeting. We're trying to develop something here: https://github.com/rspective/websockito (we've used recently released how-to-npm as a starting point).

At the beginning we would like to focus on two modules - ws and socket.io used only on the server side, at least for now. Feedback and help is welcome!

Do you have any idea (or even better - feedback from community) what topic should be covered in such workshop?

martinheidegger commented 9 years ago

@timoxley and me just talked on gitter about a content for a socket.io workshopper and we came up with two different approaches to it that could build on each other.

Approach 1: Form -> Socket

A form submission workshop that incrementally works up to websockets:

  1. Submit with HTTP Post. Reload data as natural page refresh on POST.
  2. HTTP Post over XHR. Reload data by auto refreshing page.
  3. Manually update results with HTTP GET with XHR.
  4. Switch from manual update to polling.
  5. Switch from polling to long-polling.
  6. Switch from long-polling to raw SSE
  7. Switch from raw SSE to raw WebSockets
  8. Switch from raw WebSockets to socket.io

Approach 2: (Integrated) Socket -> Hardcore Socket

Build against a decentralised (optionally online) Server system that starts with the basics of sockets but soon becomes a lot more complex.

  1. Use sockets to send a message to a central server. (hosted on heroku/modulus/gcp/aws/.. <- sponsor?)
  2. Receive a message from the server
  3. Automatically try to reconnect to the server
  4. Change the socket system to use an automated endpoint lookup (keyword: bittorrent)
  5. Create a socket server and relay a message from a (given) client to the central server.
  6. Use data from the central server to store a shared state.
  7. Connect an express/hapi/koa session to a socket.io session and send it to the central server.
  8. Deny access to a certain client based on session and write log to central server.
  9. Cleanly shutdown the server with a notification towards the central server and clients.
  10. Send A/V content over socket
  11. Secure the socket connection
timoxley commented 9 years ago

The flow I described is designed to ensure people understand the lesser-known alternatives like long-polling and SSE as well as giving people a taste of how to use websockets.

Underlying motivation is to curb the "websockets for everything" trend that's been going on for a few years now while alternatives are more widely supported, accessible and often more suited to the task at hand. Particularly, I'd like to raise awareness of SSE, which can replace a large number of places where websockets are currently used, without the proxying/intermediaries hassles of websockets (though this is getting better).