kamranhossain
For mobile apps in Elixir, Phoenix apps what is the best practice?
Using GraphQL API with Absinthe and consume it with the mobile frontend?
Using a simple REST API and consume it with a mobile frontend?
How LiveView fit in the whole picture?
Trending in Discussions
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
New
Hey there,
It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Quite interesting article Google brought me. Didn’t find any mentions about it here.
What do you think in general? Would you use togethe...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Since we have deprecated our Erlang sections (as we have dedicated Erlang Forums now) let’s add this thread for those who’d like to post ...
New
:warning: Security advisory: Decimal DoS vulnerability
A vulnerability has been published for decimal where very large exponents can cau...
New
Other Trending Topics
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
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
- #metaprogramming
- #hex
- #security











Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
Eiji
I’m not mobile developer, but I can say one thing … Many companies due to reduce costs does not optimized apps and games well and
COVID-19-related problems shows us that such approach is gonna fail sooner or faster. Depends on country problems with for example overloaded networks are still noticeable.Therefore if I would be able to choose
simple REST APIorGraphQL API(or similar solution) I would not need any time to think about it. Anyway still every solution is best in its own use case. The only thing I can suggest you is to choose wisely based on your project and consumer needs.Personally I don’t like putting
web-based solutions when talking aboutnativeapps. I would useLiveViewonly for browsers. I’m not an expert in security, but generally I’m against embeddingwebapp in browser and delivering it like a normal app. Not sure how it works on mobile devices, but let’s even assume that such browser would be delivered byAndroid… If so what’s with updates?When
LiveViewis aweb-app(notAndroid app) you do not need to worry what browser is using user. However when youdependonbrowserorWebView(wekbit?) you are responsible for updating your dependencies. Now keep in mind that many mobile users does not updates apps often unless they are forced to do so. Therefore in my opinionweb-based solutions inAndroidapp does not makes sense. Obviously same happens even forLiveViewas such dependency (clientJSpart) also needs to be updated (for example last time we got awesome uploads support).kamranhossain
I also think so. I personally prefer GraphQL API instead of REST API.
outlog
I use react native - connect it to a phoenix channel and send all stuff over the channel, you can easily send graphql over the channel if that’s your thing - then you get a thin/small channel(very little code).. I just use normal msgs over the channel, so mine is kinda “thick”/a lot of code in channel..
kamranhossain
Great. Another perspective. I will look into it. Thanks.
factsfinder
Right now I’m using the graphql way like you mentioned. API with absinthe and consume it on UI.
I made a full featured boilerplate (pending tests) of API only Pheonix framework which I’m using in my side project. Give it a check here: GitHub - factsfinder/phoenix_api: This is an api only phoenix framework boilerplate which supports graphql, authentication and aws/backblaze s3 and thumbnailing out the box as of now. · GitHub
I’m pretty sure you can save a lot of time using this.
I’ve only used Phoenix as an API only so far. So not so sure about the live view. But I’ve heard good things about it. However, I think it is limited only to the web side ?
kamranhossain
Thanks for your comment. I will look into
pheonix_apiproject. I like the way absinthe GraphQL API.I have somehow the same opinion on LiveView.
Matsa59
Also it depends of your needs. Do you need real-time app using rest api? Phoenix will be the best choice IMO.
You prefer use GraphQL? You don’t need Phoenix at all (you’ll not use channel, live view …). For real-time app, you can simply use Absinthe subscription (just follow the absinthe QuickStart with plug).
For the main question :
GraphQL offer something really interesting for mobile : selecting data that you need easily (reduce network packet size for example).
Rest allow to create and update things easily. You don’t have to create your « input_object » that can be really painful sometime. (Imagine object A that use B; B use C etc). In rest you just work directly with the data.