Web Sockets

[sam-goodwin]

The ability to use web sockets to subscribe to messages from the backend?

How far should we go with this?

• Should we do the minimum of just providing a connect/disconnect lifecycle and leave the rest for the user to manage?
• Do we want to implement some pub/sub mechanism like channels? channel prefixes? Is there a standard we can follow?
• Something else?

Design options:

• API GW + DynamoDB?
• AppSync's Subscription primitive
• AWS IOT?

[yehudacohen]

Some high level considerations re options:

AWS IoT is not built for pure websockets, it's built for MQTT over Websockets. What this means practically is that you'll need an MQTT client to connect, and all messaging will happen with pub / sub. You lose the granularity of being able to send messages over individual connections which are listening on a topic, or seeing how many consumers are currently connected. The permission model works via IAM. You can control who has access to what topics, so it is feasible to post to a separate topic per connection. There is definitely significant security consideration that needs to be given to making this work securely but it can be done. Note that unlike SNS, you can post to a topic, and if it doesn't exist and you have permission, the topic will just be created for you.

API GW + DyanamoDB is simple but has the opposite issue. Support for broadcasting to connected clients would be great, but doing so needs to be designed with custom primitives. This is a flexible model, but it is really clunky to build with. It's also not as cheap as AWS IoT from what I recall. Going down this route, I'd strongly suggest Eventual defines some of its own websocket primitives, and abstracts away connection management, and provides a built in construct for pub / sub messaging and broadcasting that is automatically wired.

AppSync is a service I have never actually used for this because you have to model all web-socket messages as part of a graphQL schema. Queries and mutations. I don't know if you can send messages which don't conform to types you've predefined. I prefer rigid restful / rpc based contracts between servers and clients to ensure I have predictable client behavior.

I tend to feel like API GW + DynamoDB is the most flexible, but also least fully managed option out of the three approaches mentioned above. Having eventual abstract this complexity would be great, though.