Ask HN: Best way to build a backend shared by iOS, Android and the Web?
With Parse closing down, we are looking at reorganizing how our apps and web apps are interacting with our database/backend, but we are facing major difficulties with all the solutions we can think of.
Currently, our mobile apps are recording health related data, that are synchronized to the cloud with Parse. We also have analytic tools and web apps, written in Python, that are fetching data from Parse.
We like Parse because it does all the synchronization and authentication in the mobile apps for us, and that has been really useful to develop our MVP. However:
- it's impossible to make any complex queries (you better download all the database locally if you want to do any advanced computation on the data). We are not that much into the NoSQL hype, and we really enjoy the power that the SQL language provides. We also like schema's.
- Parse doesn't have transactions.
- how Parse handle permissions does not satisfy us.
- using Parse from Python is not really easy.
So now, we thought of several architectures for our backend, but we are having a hard time to determine which one to choose:
1. using Google Firebase instead of Parse. We'll keep our mobile apps as simple as today, but it does not solve most of the issues we currently have with Parse. Also, Firebase support for Python seems to be very poor.
2. create our own REST web-service for the mobile apps, backed by a PostgreSQL database. This solves all the problems we currently have, and it'll make it easier for us to write the web apps (a simple ORM that queries the database). However, this requires a significant amount of work on the mobile apps on the authentication and synchronization logic, times two (one for iOS and one for Android).
3. same as (2.), but we try to share our business logic between the iOS and Android apps using C++. Dropbox seems to do it this way.
I'd like to hear what you guys think about that. I'm pretty sure that we are not the first team to face these issues.