From personal experience websockets tend to be lower latency but http is better when observability matters. It is usually easier to trace (logs, metrics) and debug both clientside (chrome dev tools) and server side, as firewalls, reverse proxies and almost every physical or virtual appliance that manages network traffic in some manner is much more capable of logging http request details (layer 7 packet inspection) than websocket traffic. If the server needs to push data to the client though a mixed solution (http for synchronous requests/responses, websockets for server pushed data).
I hope this helps.

Ha. Helps to carefully read the docs. I was trying to destructuring my state out of an object returned from useChannel instead of an array as the README clearly states. It’s now hooked up and working fine.

I’m surprised there doesn’t seem to be much uptake for that use-phoenix-channel library. It’s not a lot of code, but it’s a nice abstraction and saves a little bit of work. Then again, we’ll see how I feel once I have a lot more data to deal with.

this is incorrect

the limit is “per router” and they have a lot of routers - you can ask support for the real limits, or do a load test.. last time I checked the limit was around 1500 per dyno in the EU region ymmv..