I'm curious how redundant Firebase is? When I write database to Firebase is it automatically replicated to multiple data centers/servers?
I noticed if I go to http://status.firebase.com/, there is a list of servers (?) called s-dal5-nss-XX. Not sure what these exactly mean or how to find out which one of these your application resides on.
More information would be great!
Thank you!
how to find out which one of these your application resides on
From a discussion on the Firebase mailing list:
You can monitor https://.firebaseio.com/.settings/owner.json to find out what server is currently handling requests for your Firebase app. Note that whilst this is a method of getting the current hostname your Firebase is under, Firebase apps are not guaranteed to stay on the same server - configurations can (and do) change as we add or remove servers from rotation or load balance as necessary.
Related
We are building an app for our teams out in the field that they collect their daily information using Firebase. However one of our concerns is poor connectivity. We are looking to build an Online/Offline button they can click to essentially work offline for when things slow down. We've built a workflow in which we query all the relevant information from Firestore.
I wanted to know if there was a way to tell Firestore to work directly on the cache only and not try to hit the servers directly. I don't want Firestore attempting to make server calls until they enable online again.
You shouldn't need to do this. If you use realtime listeners, they will already first return the data from the local cache, and only then reach out to the server to check for updates.
If you are performing one-time reads, the SDK will by default try to reach the server first (since it has only one chance to give you a value). If you want it to only check the local cache, you can pass an argument to the get call to do so.
You can also disable the network completely, in which case the client will never call on the network and only serve from the local cache. I recommend reading about that and more in the documentation on using Firestore offline.
I want to be able to add domains to Firebase hosting with the API instead of the web UI, is that possible?
I want to add potentially hundreds of domains, is there a domain limit per project in Firebase?
As far as I can tell from the entire CLI documentation, there isn't any way to do this.
Lets take a step back and consider what the web UI process involves i.e. the generation of a TXT record to add to your DNS records, after verifying the presence of said TXT record on the domain, providing A records that you (authorized owner) add to allow redirecting to your firebase hosted site.
In my opinion, this very manual back and forth is necessary as a security measure. The only way it is taken out of the equation via the CLI is by providing a means for you to authenticate ownership of a domain (registered with any one of many domain registrars), and being granted authorization to change your A records. These are both outside the scope of Firebase, and could potentially introduce severe security flaws. Regardless, even if it existed, it would still have to be step-by-step and somewhat manual via CLI rather than the single command it sounds like you're looking for.
It is not possible to add custom domains automatically through an API at this time.
Nor would it allow you to create a reseller or multi-tenant project (i.e. connect a large number of domains or subdomains dynamically) since you cannot connect more than about 36 domains connected to one project.
It's possible to add domains using Firebase Hosting Rest Api. I am not sure why they didn't put it on their official website but I checked today and it works. https://developers.google.com/resources/api-libraries/documentation/firebasehosting/v1beta1/java/latest/com/google/api/services/firebasehosting/v1beta1/FirebaseHosting.Sites.Domains.html
Answer that I've received from Firebase support:
There is no API yet that would allow you to add custom domains, it was
requested as a feature before but unfortunately we have no more
information on that - so for now, only the Console UI allows you to do
it.
When it comes to the limits, in a project, a custom domain is
attached to a site - there can be 36 sites per project, and for one
site there is no hard limit, but we recommend not exceeding 20 custom
domains. You can experience technical issues with SSL certs when you
exceed 20 domains per site, which we won’t be able to troubleshoot
since the system was not designed for such use cases.
I have a Firebase (Firestore) project on which, to my surprise, I just reached the free limit of 50k daily reads only while testing simple regular pages of my app.
I tried to find a way to log how much calls are done for each of my app's pages, or by function... I didn't find how to.
Is there a simple way to get this data clarified? I absolutely need to find what calls are causing this before sending anything to production.
There is no breakdown within the Cloud Firestore console or Stack Driver on the source of read operations. If you need something like that, the best I can think of is to log additional information from your clients.
Let's say you want to use firebase to allow people to play a betting game and they would get points.
The questions are:
if there is no server side code then who decides the winner of the bet?
who would be the authority that would give points to the users?
If an individual user has write access to their own points, they could update it (which is not what we want)
The solution that we thought about is a admin node firebase client running on a server. It would listen and make decisions and write to the points location for each user. Users would only have read access.
But this means that there would have to be scalable server or servers. This seems to be a single point of failure. Plus what if you have 100's of admin firebase clients running, that could be a synchronization issue.
What is the best practice for this type of problem?
I suspect all games must have this issue? no?
You can use App Engine for backend processing, which is Google's "serverless" solution. Checkout this solution: Using Firebase for Real-time Events on App Engine. It think it solves your questions.
I am trying to evaluate whether Meteor JS would be suitable for a future project that would incorporate live chat, and may need to be scalable.
It certainly can perform the chat functions, but I don't want to paint myself into a corner if traffic spikes and we need to provision the app with more resources in the form of drones/dynos/instances. I have read that a Meteor app on Heroku won't easily scale (perhaps not at all?). I am not clear on whether this is a Heroku issue, or more to do with the current state of Meteor JS (0.6.2.1 at this time). I've not found much more related to Nodejitsu or AppFog.
Can anyone clarify whether a Meteor JS app can currently be deployed on a PaaS such that resources (drones/dynos/instances) can be easily scaled up to meet demand? If so, which Paas? If not, what is the explanation (for a 5-year-old), and is there a roadmap?
Personally I've set myself up with an AWS load balancer and EC2 instances, with my DB over at MongoHQ.
The load balancer setup was made that much easier by following these instructions:
http://www.ripariandata.com/blog/creating-an-aws-elastic-load-balancer
I wrote a script to deploy to a single EC2 instance. It wouldn't be much work to add additional remotes in case you have multiple instances:
https://github.com/matb33/meteor-ec2-install
The best I would recommend is Meteor.com hosting (via meteor deploy).
This is because they would incorporate the ddp-proxy solution within their architecture. Its not as simple as just proxying between two meteors and using a dynamo because each user's session might be on the other server & it might cause a bit of trouble when switching over to another dynamo.
For now its free & it looks like they scale it fairly well too. I think they're also going to introduce a nicer hosting solution soon & who better to host meteor apps than meteor themselves.
If you want to deploy on your own infrastructure (EC2 for instance) you could scale up vertically for the moment until the DDP proxy is released (DDP is what meteor uses to communicate between the server and client (and soon between servers too) to make sure the state can be relayed across multiple 'dynamos'.
This answer is Heroku specific.
As far as I understand meteor application can't be scaled on Heroku on more than one dyno. The reason is that the meteor server instance holds a state for every client. This way it knows what updates to send to the client every time. Meaning that the client has to talk with the same server every time. The Heroku proxy layer doesn't provide this kind of communication and can route client request to a different dyno which does't hold client state.
So now the server has to get all client data from the db and send everything back to the client. The server gets loaded and the client gets updated. So we have two dynos, we do twice the work and add lots of noise to the client.
I hope it is clear enough.