We had a customer create a detailed post on using websockets: https://forum.datomic.com/t/websocket-guide-wip/1916 that might be of some interest to you.

I wrote that as part of my own going toy project. Most of the work is in understanding AWS websocket setups. That is, datomic cloud doesn't really add any overhead to the process. I also haven't thought through storing the websocket sessions. Likely that should be done in a separate dynamo db table where it's easier to remove/expire them.

When we oriented ourserves towards WS, we had our dynamodb table for storing websocket sessions. We didn't see value in keeping them in our Datomic system of transactions.

@U0514DPR7 Did you by any chance do a write up on that? I'm mostly curious about an overview of the session management in a couple typical cases. I imagine the overview is just... 1. client -> server : if create -> store in dynamo. If delete -> delete from dynamo. If message -> whatever 2. server -> client: if new data you want to send to potential clients then look up affected users, then lookup session keys in dynamo and then send message.

I want to keep a rules engine on the server that has a cache of the data any open session might care about. i'm curious if anyone has gone down that road.

Hi Drew, I was not the one implementing it. I helped making a POC through AWS API Gateway and made a way in our code to talk to DDB, but the actual session management was implemented by another developer. You've outlined it quite well, though.

@U0DJ4T5U1 would you store such cache in dynamo, then?

@U02CV2P4J6S I'll revise my earlier statement. I would cache things as needed, the easiest (from a development perspective) option is to never cache. So re-creating the rete-network data on request each time is fine for my application currently. It has no users 🙂 . Assuming perf did start to matter, and i did need to keep the rules network in memory (a cache of the db). Then It would be on the server likely just in a clojure atom. From there it gets more complicated and it would be useful to know which access patterns specifically were slow or a bottleneck.

interesting. What is the server? Is that a http ion? Ah I searched the forum and suppose 1 way is to start some process when the namespace of the ion loads

On the other hand you need to keep the connection-id to be able to send your response back to the ws client.