
Ask HN: What stack should I use for my mobile app? - gitrog
I am about to start development on a mobile app prototype, which, if we can secure funding, would be used by hundreds of thousands of people daily.<p>I would like to build the prototype on the same stack as I&#x27;ll use for the final product to start getting my head around architecture choices and third party libraries to include.<p>I&#x27;m predominantly a web developer, having experience in Ruby on Rails and Django on the backend side of things and having worked with React, Cordova (Phonegap) and Angular.  I&#x27;ve built some mobile apps using these technologies, as well as a small mobile app using Kivy.<p>The app will largely be informational with some data capture and lots of updates pushed to users, probably several times a week.<p>So based on my experience, I was thinking of going with Django Rest Framework and React Native, as I&#x27;ve built an app with this before a few years ago.  But I remember dealing with the state on the UI side being a bit of a pain and was wondering if maybe going with Django, GraphQL (Apollo) and React Native wouldn&#x27;t be better (even though I don&#x27;t know GraphQL yet).<p>Do I have better options?  Would my suggested stack be able to eventually handle the workload?  Obviously the API will have to sit on some solid cloud infrastructure as well.
======
theory_of_10
In the last 6 months, I’ve built 3 mobile apps using React Native with Django
Rest Framework. I can’t be more satisfied.

We tried GraphQL, it added a lot of complexity on the backend that you don’t
really need

We like to keep things simple, so we avoided state management libraries and
all we needed was [https://github.com/async-library/react-
async](https://github.com/async-library/react-async)

We also liked onesignal to manage push notifications

~~~
gitrog
Something crucial I should have mentioned is that many of the users will
likely have poor internet quality. Not sure if this will end up affecting my
need for state management.

~~~
didericis
I kind of disagree with OP about GraphQL adding too much complexity on the
backend. Depending on what kind of queries you define, creating efficient
resolvers that don't hit the database excessively can be complex, but in most
cases I find GraphQL very easy to work with.

I've used Django Rest Framework as well, and although I would agree there's a
bit less overhead (though I'd argue not that much: you still should be
defining serializers for models like you would be defining types in GraphQL,
there are just a lot of nice little helper methods and conventions for DRF
that make it a bit faster than setting up GraphQL with Django), one of the
main selling points of GraphQL is the ability to use Apollo on the frontend.
Because of Apollo's caching system, you don't really need to create any custom
state management related to fetching and storing queries from the server. You
might need state management for other purposes, and you'll still need to tell
it to do things like update lists when deleting items/when a mutation might
invalidate other cached query results, but it handles a lot right out of the
box.

The biggest headaches related to SPA state management I've run into before
Apollo were always about fetching data efficiently and invalidating results
from the server, which Apollo does really well. You don't need to worry about
"am I fetching X somewhere else an extra time" or "did I remember to update Y
in all the right places in the store when I fetched new data"; you can just
declare the data you're component needs, and Apollo will either get it from
the frontend cache, or if it can't find it there, the server.

If your app was more about user input than ingesting information, I might
recommend checking out pouchdb. I just started using it for an app that's
almost entirely based on user input that I wanted to work during long
stretches of being offline, and it's been working pretty well so far (although
I don't feel I've done enough with it to really endorse it fully yet/I have
yet to see how the project pans out).

But since it sounds like your app is mostly about displaying information
coming from the server to your users, and you want to avoid hitting the wire
for data as much as possible, I think a combination of React Native and Apollo
is probably a good fit. I'm sure there are other solutions, but it's the one
I'm most comfortable with/what I'd probably jump to in your situation.

~~~
gitrog
GraphQL and Apollo looked attractive to me for all the reasons you stated, but
I was just worried that the learning curve and making it play nicely with the
rest of the stack (that I know quite well already) would be too steep to
justify using for the prototype. I'm thinking of writing the prototype just
using DRF and React Native but during each step of the process basically
looking into how that step would be done with GraphQL.

~~~
didericis
I was familiar with GraphQL before integrating it into a Django project, so my
experience may differ, but I had a good experience using graphene:
[https://docs.graphene-
python.org/projects/django/en/latest/t...](https://docs.graphene-
python.org/projects/django/en/latest/tutorial-plain/)

Since efficient querying is a concern, I highly recommend just biting the
bullet. It's extremely easy to underestimate the complexity of caching state
on the frontend and to end up accumulating an unmaintainable frontend state
management situation. It's totally possible to do what OP suggested without
running in to those kinds of issues, but typically that involves more frequent
fetching from the server.

It depends how quickly you need to make the prototype/whether you'd be willing
to refactor it/how efficient the querying really needs to be/whether you think
you can keep state management simple and structured enough to avoid it
ballooning/how quickly you think you can grok the basics of GraphQL/etc.
Apollo doesn't really care what your schema looks like, unlike relay, so the
learning curve isn't as steep. When I picked up GraphQL/Apollo for the first
time the terminology felt pretty obtuse, but once the basic idea clicked it
felt pretty natural. Most of the devs I've worked with have had similar
experiences.

~~~
gitrog
I'd like to get the prototype out quickly, and then there will probably be
quite a bit of time before the final product is launched.

Things like this worry me about getting up and running with GraphQL though,
especially "Common GraphQL problems: Server/Client Data Mismatch":

[https://www.freecodecamp.org/news/five-common-problems-in-
gr...](https://www.freecodecamp.org/news/five-common-problems-in-graphql-apps-
and-how-to-fix-them-ac74d37a293c/)

~~~
didericis
Out of all those problems I'd say the most difficult one to tackle is related
to performance, but if it's an api that only you are hitting, you can usually
avoid doing anything too costly.

The recommended solution of using graphql on the server for the server/client
data mismatch problem is a good one, but it's not really applicable in your
case. That's geared towards people using both javascript and nodejs. If you're
using javascript on the frontend and python on the backend, you can't share
code/there's inevitably going to be a mismatch. A mismatch isn't always a bad
thing, either; often you don't need to expose all of the database models to
the client, and want a lighter weight abstraction.

------
elamje
If you are a Rails developer, this Turbolinks presentation makes a strong case
to be used for mobile apps.
[https://m.youtube.com/watch?v=SWEts0rlezA](https://m.youtube.com/watch?v=SWEts0rlezA)

It seems like there is a strong productivity gain from using rails here since
it’s extremely productive and you can make simple wrapper apps to release to
the Play and App Store that really just wrap the web view.

The biggest gain is obviously reusing most of the web app across three
different platforms, and the ability to add native navigation and interaction
as needed, later. You also avoid needing a big javascript library.

~~~
yeskia
I’ve looked at this before, but it seems to require you use remote forms. And
when you use remote forms there’s no out of the box solution for displaying
errors. Am I missing something here? Were you able to successfully build a
Turbolinks app off a Rails app?

------
charlie0077
Why not node.js instead of Django? In general I feel node.js community is more
active in terms of web development. And you don't need to do context switch
between node and python. I would go with GraphQL, the part that I like the
most is the schema. You don't need to maintain doc now. There is also a
playground, you can do integration test easily during development.

If you feel bad about all the boilerplate code you need to write in server
side. There are many node libs/blackbox services that can help you, such as
prisma, hasura. You can also take a look at a lightweight library that makes
your life easier when building GraphQL server:
[https://github.com/charlie0077/graphql-server-
crud/](https://github.com/charlie0077/graphql-server-crud/)

I am the author of that library.

------
hactually
Django is fine, if a little heavy but it will provide a good restful API. For
the app - I'd really recommend dipping into Flutter. The language is simple,
tooling is great and you can get up and building rapidly.

~~~
gitrog
I'm keen to try out Flutter as I've heard good things, but I'm weary of
delving into an entirely new language for this project if the languages I know
already offer a viable (and popular) mobile app dev stack. Unless it really
makes state handling on the UI mega simple, which is my biggest problem with
the JS library/framework solutions I've worked with before.

~~~
cercatrova
Try out both and check them out. The dev experience on Flutter is in my
opinion far superior to React Native. It _just works_ whereas with RN I spent
so much time getting things to work correctly, even with Expo. I am not sure
why it's so terrible given that create-react-app "just works" almost as well
as Flutter.

------
kgin
React Native and Firebase

or, if you want to be more independent

React Native and FeathersJS

~~~
gitrog
What are the benefits of FeatherJS and Firebase over using the backends that
I'm already familiar with?

