Best practices to build APIs for mobile apps

Chat / Discussions
, , , , ,
1

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?

1 Like
2

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 API or GraphQL 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 about native apps. I would use LiveView only for browsers. I’m not an expert in security, but generally I’m against embedding web app 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 by Android … If so what’s with updates?

When LiveView is a web-app (not Android app) you do not need to worry what browser is using user. However when you depend on browser or WebView (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 opinion web-based solutions in Android app does not makes sense. Obviously same happens even for LiveView as such dependency (client JS part) also needs to be updated (for example last time we got awesome uploads support).

2 Likes
3

I also think so. I personally prefer GraphQL API instead of REST API.

4

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…

2 Likes
5

Great. Another perspective. I will look into it. Thanks.

6

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: https://github.com/factsfinder/pheonix_api

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 ?

1 Like
7

Thanks for your comment. I will look into pheonix_api project. I like the way absinthe GraphQL API.
I have somehow the same opinion on LiveView.

1 Like
8

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.

2 Likes