te_chris
Hey everyone. I’m working on a service that’s currently LV but will eventually have an app. The interaction will basically be the same. This has had me thinking about how I could avoid duplication with client/server interactions, while still offering a similar responsive/reactive experince on both platforms.
I’d like to avoid having to build a separate API (beyond bare necessities) and LV stack if possible so my question is: can I treat a channel as an ‘API’ interface that the LV and the App could both talk to and does anyone have any experience of this, advice/war stories they can share?
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 6 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
That sounds rather wrong tbh. Event handlers in LV should handle the web ui specifics, not domain level functionality. You shouldn’t need to duplicate any logic to another API interface. That stuff should be in lower levels of your codebase. Copying boilerplate (e.g. calling into your core modules) is imo the right way to handle this, as eventual divergance of interfaces is to be expected.
D4no0
I don’t see a way to do this without writing custom JS, starting a phoenix channel is trivial currently or you could always use something like this: GitHub - Miserlou/live_json: LiveJSON - LiveView for JSON · GitHub .
te_chris
No I get that. LV is obviously sending its diffs and such and I wouldn’t want to touch it. I’m just more wondering about something like a separte channel for key persistent state mutations or similar. So you can centralise a channel api between clients for things like e.g add-blah, blah-updated. Maybe more like a shared CQRS or similar? I’m unsure. It just seems like duplication to define how these events are handled twice (once on the channel and once on the LVs).
D4no0
I would not classify liveview as an abstraction over channels, I would say that liveview uses phoenix channels to implement the desired behavior, namely abstraction of frontend interaction.
I don’t know these days, but back in the day liveview implementation was marked as internal and it is not recommended to tap into how it works, because implementation details might change in a future release.
te_chris
I’m not talking about losing the behaviour, I’m talking about creating a consistent channel interface for sending events between client and server. LV is an abstraction on top of channels already.
D4no0
By definition, what liveview does is interactive frontend without writing JS, or having a communication contract.
If you want to change this behavior, you will literally lose all the benefits liveview brings, and IMO is better to stick with a separate frontend with a separate API.