6

I'm trying to create a collaborative web application where multiple users can work together on various (shared) projects. So far I have a JavaScript client and one local jWebSocket server.

To remain scalable upon deployment, I thought of two options:

Option 1

I can use AWS IoT instead of multiple jWebSocket servers. Publishing changes of a project is easy, I would just need to publish to e.g. /project/{project-id}. But how would the traditional request-response mechanism work?

Sketch of option 1

The Problem: EC2 instances handling requests would be reachable by publishing to distinct topics (e.g. /server/1). But when the JS client connects to AWS IoT, it does not know of any EC2 instance to send requests to. How could I assign each client to an instance/topic?

Option 2

Run jWebSocket servers on multiple EC2 instances behind an AWS Application Load Balancer. The balancer would simply assign each client to a server and the traditional request-response flow would not be a problem. But what about pushing changes?

Sketch of option 2

The Problem: Because each server has its own set of connected clients, it can not push changes to clients connected to another server.

Remarks

  • Mixing jWebSocket to send requests to and AWS IoT to receive events from seems like a sloppy solution.
  • I assume I can programmatically adapt the IoT policies per cognito identity to allow/deny the subscription to specific projects.
  • Using AWS Lambda and relinquishing servers altogether is not an option due to the high latency introduced by Lambda (if you've made different experiences, please share).

Related posts

IoT request response protocol

Thanks for any thought you could give me on this issue.

Community
  • 1
  • 1
Double M
  • 1,449
  • 1
  • 12
  • 29
  • I've run a websockets app on Elastic Beanstalk (modified nginx.conf a bit to support it) and ran into similar issues with deployments. Because of the persistent nature of websockets we wound up using a clustered akka instance to publish messages. On deployments we'd push out a message to the JS client instructing it to reconnect. Very interested in the solution you come up with as ours was less than perfect. – Dave Maple Jan 25 '17 at 17:51
  • Thanks for bringing EBS and Akka to my attention (didn't know either). Could you sketch the architecture you ended up with? Were you able to work in a request-response way while being able to publish to **all** clients (even if connected to different servers)? – Double M Jan 25 '17 at 19:20
  • Side note: Elastic Beanstalk is actually just "EB." EBS is the acronym for Elastic Block Store. – Michael - sqlbot Jan 26 '17 at 01:09
  • I guess, AWS IoT is not working the way you think. Your clients publish messages to a IoT topic. Iot Rules subscribe to IoT topics (e.g. project/+) and can take actions like invoke lambda function (http://docs.aws.amazon.com/iot/latest/developerguide/iot-rule-actions.html). but there is no action to talk to an EC2 instance directly. In AWS IoT there is no way to subscribe to a topic directly. Only IoT rules can subscribe and trigger actions. besides that, I can recommend the IoT service for Websocket apps. – hellomichibye Feb 01 '17 at 15:55
  • Thanks for that valuable information. It's inconsistent with what the docs say, though: ["The message broker uses topics to route messages from publishing clients to subscribing clients."](http://docs.aws.amazon.com/iot/latest/developerguide/topics.html) Do you know of any similar service that would allow me to achieve the above? – Double M Feb 02 '17 at 13:25
  • Did you consider using a SaaS WebSockets provider? I can recommend Pusher. – The Onin Feb 04 '17 at 06:29
  • If you're not locking yourself specifically into AWS, Firebase (https://firebase.google.com) is a good solution for these kinds of live synchronisation problems. – Bilal Akil Feb 04 '17 at 08:38
  • @nino / bilal Thanks I'll look into those - but that setup would still leave me in the same scenario as in Option 1. Do you think it would be weird to use the approach in Option 2 for requests/responses, and Option 1 for notifications in a mixed manner? – Double M Feb 04 '17 at 11:29

1 Answers1

0

I've got it. The first suggestion in this question pointed me into the right direction. The solution allows all clients to maintain a direct WebSocket connection to the server they originally connected to, without subscribing to specific topics.

Servers push messages for unknown clients to the server in charge.

It works as follows:

  1. When a client connects to a server, the server subscribes to the client's channel
  2. If a server needs to send a message to a client that is not connected, it publishes that message to the client's channel
  3. (you guessed it) The server that is subscribed to the channel can then process the message on the first server's behalf

"Pusher" in the diagram describes this SaaS, but can of course be replaced by any other messaging service.

Community
  • 1
  • 1
Double M
  • 1,449
  • 1
  • 12
  • 29