Clarify the Firebase connections
I am a little confused about the Firebase pricing model, special concern is the connections or more precisely concurrent connections.
Let's have an example of a mobile app for iOS called FanZONE:
User will create groups during football matches. They will comment on the actual game and the comments are immediately displayed on each members screen.
Does this scenario means that each user who is participating on commenting/viewing counts for one connection?
So if a group contains 100 users who actively follow the screen and from time to time comment is there 100 connections each 90 minutes long?
What about users who have the app in the background and the app checks each 5 minutes the score. Is this connection as well 90 minutes long or only a fraction of time every 5 minutes?
Solution 1:
In addition to Mike P's excellent answer, here are a few other discussions on the same topic which may prove insightful.
From the Firebase pricing page:
What is a Connection?
A connection is an open network connection to our servers. It's a measure of the number of users that are using your app or site simultaneously. This isn't the same as (and is usually a lot lower than) the total number of visitors to your site or the total number of users of your app. In our experience, 1 concurrent corresponds to roughly 1,400 monthly visits.
Our Development Firebase has a hard limit on the number of connections allowed. All of the paid Firebases, however, are “burstable”, which means usage is not capped and instead you are billed for any overages. We measure connections for paid plans based on the 95th percentile of usage during the month.
From this mailing list discussion, by Andrew Lee (Firebase founder):
I strongly recommend you not worry about it unless you're actually bumping up against our limits...most developers vastly overestimate the number of concurrent users they will have. A good rule of thumb is 1 concurrent = 1000 monthly visits for the typical website. For mobile, the ratio between installs and concurrents is sometimes even higher (though it varies considerably depending on your use case). Our plans are quite generous when it comes to concurrent users. As a data point -- our own website could operate comfortably on the "free" Firebase plan most days. In fact, more than 99.5% of all of Firebases never hit the 50 concurrent limit.
So, long story short, if you're working on a hobby project, you will almost certainly not hit our free tier 50-concurrent limit. If you're a business or a larger app, I hope you will find our $49 / month plan more cost-effective than spending engineering time to figure out when to goOnline / goOffline to minimize that number.
At the very high end (huge Enterprise apps with 10k+ concurrents) we do offer custom pricing that has a lower per-concurrent rate.
A user benchmarking and testing of connections here on SO: How the Connection is calculated in Firebase
Another similar question here on SO: How are concurrent connections calculated
Solution 2:
In your first scenario - the short answer is yes. As long as your users keep the screen on where you have a Firebase connection that allows them to comment/read comments - you will have one concurrent connection per screen.
In your second scenario - this depends on how you develop your app. The Firebase API does provide you with the goOffline and goOnline methods (https://www.firebase.com/docs/ios-api/Classes/Firebase.html#class_methods) which give you control over your connection. If you want to go offline for 5 minutes, then briefly come back online to check scores and then go offline again, then you'd only hold a connection for a short duration.
Concurrent connections are just that - connections established at the same time. So if you have 3 people using your app to check scores, but user 1's app goes online at 12:00 PM and the connection lasts for 5 seconds, then user 2's app goes online at 12:01 PM for 5 seconds, and user 3's app goes online at 12:02 PM for 5 seconds then you've only ever had 1 concurrent connection.
If on the other hand, all 3 users' apps go online at 12:00 PM for 5 seconds then you'll have 3 concurrent connections.
You could potentially use this same goOffline/goOnline strategy with your first scenario, but that may detract from the experience if your users are expecting to be chatting about a game in near real-time.