yukster
Pondering the pros and cons of making a JSON web endpoint (controller action) vs using a channel for the backend for a React Native app.
I had been looking into GraphQL, but I think it’s overkill for my app, at least now. It’s going to have have a single user’s data and not a large amount of data that would need to be queried in varying ways. It’s a handful of relations revolving around one main entity and the user will have a list of those. Thoughts regarding the benefits or pros/cons of the two approaches in this context?
One important criteria for the app is to work well with a fickle connection, so that makes me wonder if it’s worth the hassle of using channels. On the other hand, the stakeholder would like “save on blur” type behavior in the forms (I’d love to do it with LiveView, but the stakeholder also wants a “real” mobile app), which would work better with a channel. However, I could also have the client form save-on-blur locally with eventual consistency with the back end.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
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
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
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!
Producing high quality Elixir screencasts since 2017.
**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 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
maz
Do both
bottlenecked
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.
yukster
Yeah, I was thinking about it last night and it probably makes sense for a new or wiped client to pull the user’s entire state via an HTTP JSON endpoint and then just use the socket for updates of individual bits.
yukster
Duly noted!
outlog
I run everything over Phoenix channels in my react native app.. push entire state over in an “after_join” and then listen for changes and make any changes over the channel.. works wonderfully.. and handles the offline/online out of sync scenarios beautifully..
yukster
Hm, okay. Somehow the entire state seemed more suited to an HTTP request, but I suppose either way it is data moving over the wire.
andrejsm
What about server’s connection limits? Have you had any issues with that? Let’s take Heroku for example where dynos are limited to 50 connections. Does it mean that 51st connection can’t connect until one of 50 active connections gets closed?
outlog
yep, you do have edge scenario, which on mobile is not that edge with intermittent connectivity..
eg.
open app get state over http and connect over websocket.. (even here you have a “gap issue” eg time/state of http request data vs time of websocket connect - ie changes might have happened in the gap)
mobile now goes offline..
and goes online after a few moments..
app is now out of sync eg in unknown state..
you can of course fire of the http request on channel connect.. but now you are just intermingling different ways of getting data..
btw: I use redux-observables on react-native, and I’m a big fan..
of course there is no silver bullet, all depends on requirements etc etc.. maintaining a stateful connection is by all means “more costly” serverside than a stateless state sync..
and for really bad connections a retrying http request might have more success than getting a websocket going etc etc.
outlog
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..
yukster
Do you make a channel per model/context? Per screen? I’m spinning a bit on what to make my channels model. The examples seem to always revolve around chat rooms or the like. I’m building a relatively small mobile app and want to use channels to just transfer all state and updates. It feels like, at least to start, I just need one generic channel with various events for particular data changes. The app user connects to that once on app startup and sticks with it regardles of what screen they’re on.