You get a very simple action/command programming model with zero latency, but you need to account for actions/templates living client-side. So use:
- Actions & templates for data that’s public to the user (gets zero latency interactions)
- Commands for operations that should be private and when you need security (executed on the server)
For example, if a bank is processing a credit score using trade secrets, internal algorithms, and user data that should only be visible to the bank, you’d use a command that calls your Phoenix context or some service and returns the data for the template (like the final score or approval status). Actions and templates are basically your view layer that lives in the user’s browser.
The action/command model gives you a clean separation that works nicely in practice, with usage patterns emerging for different cases like server-to-client state updates, and patterns will likely emerge around these client/server data decisions as well.
Looking ahead, I have ideas for additional tooling like a DSL for defining data shapes, and eventually a local-first data layer where user data syncs declaratively and automatically between client and server.
The mindset shift is: “What does this user need to see/interact with?” goes client-side (and gets instant responsiveness), everything else stays server-side. 
