A lot of LiveView’s advantages stem from its persistent connection model.
- No more manually handling internal http requests (vs rest)
- Server is source of truth: no more manually managing client state (vs rest / graphql)
- No more authenticating every request i.e. db round trip (vs stateless server)
Obviously the “fragmental real time html rerendering” (can’t find appropriate term) is the main innovation here and probably LiveView’s biggest selling point, but isn’t feasible on mobile today. However, I wonder whether LiveView’s persistent connection model is. If we omit UI, the not-so-LiveView-specific concept of a persistent connection to handle all requests replaces the conventional stateless request/response model, and can potentially offer all the pros enumerated above.
So I was wondering what are the cons of using this approach, specifically for mobile?
So far I have come up with the following cons:
- Lack of a standard protocol on top of the transport (i.e. websockets has numerous subprotocols without a clear winner/best practice/idiomatic one) vs HTTP
- Increase in server load to handle the persistent connections/sessions vs stateless api server
- Spotty networks on mobile