I’m new to this, but it seems to be that the least painful way to write an “offline first” social network app would be to use a auto-synching database like Google “Cloud Firestore” or Realm Object Server because I believe it would greatly reduce the amount of server-side REST or GraphQL programming.
The client-side React Native code would just be driven by local objects that would auto-persist to the cloud.
(BTW, even if Realm was supported by Expo I couldn’t use it because Realm Object Server [self-hosted, no less…] costs over $2,000 for 500 users… so getting to 100K would bankrupt me.)
Any feedback? What would YOU use? What is the current state-of-the-art or best practice? Seems every app developer immediately hits this architecture issue and has to pick something!
Meteor.js also makes subscriptions easy to get up and running, but not sure it’s going to easily scale to 100k users… but then again what will “easily” scale to 100k users. (some interesting discussion here)
Have you considered just choosing whatever the easiest solution is for now, get to 5-20k users, and then consider more scalable options? Or are you 100% guaranteed to hit 100k users within the first 6 months of launching so the scalability is a major concern immediately? 9/10 apps end up bombing anyway, so it’s always good to avoid worrying about 100k users before you even have 1 user.
I’ve never looked at Realm, but I wonder what their main market is if 500 users costs $2k in hosting… seems pretty limited to fortune 500 companies who need a real-time app internally… as nobody is going to start a b2c app paying that much per head.
Hey! My team and I are currently in the nearing the launch of a social media that is hopefully going to scale to over hundreds of thousands of users.
We are using django (python’s rest API based web framework) and PostgresQL for our backend. Something to keep in mind is that most of google’s firebase functionality requires detaching from expo which likely will cause more headache than it’s worth.
If you want more specific examples, feel free to hit me up on twitter or shoot me an email!
I’ve worked with Firebase before and really enjoyed it (disclaimer: I’ve only done a little bit with it in React Native- most of my experience with it is in Swift). It’s my first choice for building something completely from scratch. Sync is always complicated, so having a platform that abstracts offline/ online syncing is a huge boon to productivity. Like anything, you can setup stuff in a way that doesn’t scale well, but I have no doubt Firebase can scale to 100k or much further. The free tier is very generous and gives you tons of runway to try something out. If you’re building something on your own or with just a couple of people, IMO it’s really important to pick a few things to focus on where you want to put your most effort in, and simplify/ outsource the rest. With Firebase, you basically eliminate the whole step of having to write a backend API so you can focus on the frontend user experience. That’s huge.
In terms of cost, whatever you choose, I wouldn’t worry too much about what 100k users would cost. Or even if your app could technically scale to 100k users. I would worry first about building something that gets 100 devoted users (which the Firebase free tier could handle easily). If your app gets popular beyond what you can handle, then hopefully the idea has legs and could be monetized/ turned into a full-time paying job/ get funding. And then there could be resources to improve the technology to make it scale better. Most apps never get to this stage.
I’ve found Pieter Level’s philosophy on a dead-simple infrastructure for new apps interesting. In this blog post, he talks about storing app data on his server in JSON files- no database. In other places, as I recall he’s mentioned that you can actually scale surprisingly far with just a SQLite database.
