Hey, guys!
I’m wondering are phoenix channels appropriate in cases where json api or simple one-time request/response will do (resource efficiency and performance wise)? For example, when frontend needs to catch some data from database.
Was thinking request/response will do, when view templates are generated with .eex, and json api will conform in cases, when frontends are built with different frameworks (say, Elm or React), but saw couple of tutorials, where authors were using channels for simply fetching data from DB (no messaging stuff or something, so guess there no need for persistent connection).
Any thoughts or resources, where I can read about this stuff in more details will be highly appreciated 
Thanks
2 Likes
Channels aren’t really suitable for request/response interactions. Channels are for streams. If you try to turn a stream into a request / response interaction, you have to introduce your own mechanism to route the correct response to the requestor. I don’t see the advantage of doing this. It may be error prone, and all the tools we use to debug, log, manage our applications don’t really fit as well in this paradigm.
3 Likes
@jeremyjh Thinking that way too. The main pro-channel argument (as understood from one of the above mentioned tuts) is there speed, but think channels are made for entirely different tasks.
1 Like
You can use graphql with websocket as network layer if You want.
Also absinthe can use ws for subscriptions.
1 Like
You can easily do requests on a channel, and you end up with something that is totally similar to a http request code-wise - of course it doesn’t come build in, so you’ll do it with observables or whatever you prefer in client world.
con: it might be overkill for simple stuff and if there is no streaming, live updating or anything then why bother.
pro: it allows you to build a more modern product and UX.
say preloading the frontend app and then everything is already loaded when navigating around (and changes are live updated) - there are also advantages in offline/online scenario - where you will have a channel reconnect event (say I closed the lid on my laptop 10 hours ago, and now I open it again - what does your frontend do?) - event alerts etc etc.
but it all depends on the app/service you are building…
2 Likes
@outlog understood, Peter. Completely agree, it all depends… Thanks for detailed answer. Much appreciated
1 Like
The argument that there isn’t tooling is a good argument, if the tooling that we have in mind is the ordinary tooling that goes into a JSON + REST style API. At the core of this tooling is a notion of an HTTP based request / response model, and this doesn’t map well to channels.
As others have mentioned, GraphQL does not assume a transport, so if you had a GraphQL schema you could trivially switch from HTTP to websocket, and 99% of the effort you would have put in would also seamlessly transfer into a real time subscription model too.
4 Likes
@benwilson512 Awesome, Ben. GraphQL and Absinthe are next elixir/phoenix related things in my list to check. Sounds very good. Thanks.
2 Likes
