Does the AngularFire service use REST under the hood?
If so is there no limits in the hacker plan, because the Firebase page on pricing says:
REST API requests don't count towards your connection limits
?
The AngularFire library uses Firebase's regular JavaScript/Web SDK under the hood. Each client keeps a connection open to Firebase servers, so will count towards the connection limits.
You can easily verify this yourself by creating a minimal AngularFire client and opening it in a few different browsers. After 15-20 minutes you can see the connections showing up in the Analytics tab of your Firebase dashboard.
Related
I've read the docs about Firebase Auth Limits in https://firebase.google.com/docs/auth/limits. It states that there is a limit of 1000 requests/second per project. There is no example or any explanation about what those API Limits are. What kind of actions are counted in the API Limit? Does verifyIdToken() and createUser() in Admin SDK count as an API Request?
I am also aware that there is a duplicate question here but it hasn't been answered well.
I've asked Firebase Support about the API Limits and got the following response:
The API’s quota applies depending on the Firebase API you want to
use. In this case the API quota applies to the use of the Firebase Auth REST API. Using it, you can query the Firebase Auth backend
through a REST API. Also, it can be used for various operations such
as creating new users, signing in existing ones and editing or
deleting these users.
To create, and refresh a token the quota will apply, if you use the
REST API to do the operations. However, even if you don’t use the REST
API there are other internal quotas associated with the refreshing of
the token. In order to avoid refreshing the token so many times, set
forceRefresh to false to minimize unneeded token refreshes when a
valid token may still be cached.
I've also asked about the internal quota when refreshing the token using the official sdk and got this reponse:
Unfortunately, some quotas are internal, and confidential information.
For this reason, I am not able to share it with you. However, if you
receive quota errors you can contact us
The rate limit includes both the Client and Admin SDK:
The API limits encapsulates every request that comes from the API.
This includes various operations such as creating new users, signing
in existing ones, and editing or deleting users. The limits apply to
requests coming from both the Client and Admin SDK. This means that
Firebase allows you to have 1000 simultaneous requests/second (both
from Client and Admin SDK) in a project.
~ Firebase Support
In Google Firebase pricing (https://firebase.google.com/pricing/) table states:
The Spark plan only allows outbound network requests to Google-owned
services.
Does it mean that JS function in web browser (client) page can't call Firebase function and retrieve data in FREE TIER?
firebaser here
Good catch, that piece of documentation probably should be clarified.
Inbound requests are allowed, as long as you're within your allowed quota. So your app can call a Cloud Function.
Outbound requests for projects on the free plan are only allowed to Google-owned services. So your Cloud Function code can only call google owned web APIs, unless it's on a paid plan.
Update: the above applies up to Node.js runtimes up to v8. From Node.js 10 and upwards your Firebase project needs to be on a paid plan to be able to use Cloud Functions. For full details on this, see the Firebase FAQ on Cloud Functions pricing.
At lowest possible costs (USD 11.53) it is better to have Blaze plan and use REST calls to Firebase functions freely:
no, they do not talk about JavaScript Functions, they talk about serverless computing functions
https://firebase.google.com/features/functions/
theses functions can make only make http calls to Google Services and e.g. not to Yahoo or Amazon services
I am working on a project that might use Firebase only for messaging. The goal is for the following to happen:
App registers with Firebase on startup
App sends Firebase token to our server
Our server sends Firebase messages to all clients via the token from step 2
Note there is no step where the user will log into anything or enter any credentials. I am a little confused if this is possible in a production app, as most Firebase documentation talks extensively about different ways to authenticate, either via username/password, OAuth, etc.
The server will be sending different messages to different clients, but that logic will be handled by the server and not by different types of registration to Firebase. I know Firebase supports groups, but to make a long story short it probably won't be leveraged.
Can all this be done on Firebase? Is GCM a better match for these requirements? I feel like we would be throwing away 95% of Firebase and just trying to force it to simplify the messaging part.
Firebase Authentication does not at all affect the way that Firebase Cloud Messaging works. FCM only cares about the token for the app on the device as a means to target the app for messages. It doesn't care at all if the end user is authenticated by any means. If you want to associate a token to a user somehow, using Firebase Authentication or some other system, that's up to you.
FCM is an evolution of GCM. They are powered by essentially the same components. Using GCM doesn't give you any additional constraints or flexibility than FCM, except for the path to integration in your app.
Can we implement Firebase for an android app, where I am registering user using Mobile number (Similar to Whatsapp). Users will be sent a code by server which is entered by user in android app to validate the user mobile number and registering him on the server.
Question : Can I use the above method in conjunction with Firebase Auth?
I was earlier going to use MongoDB for my project, but since Firebase has SYNC capabilities, it will be a better choice for storing data. Another good reason is as below:
If a client loses its network connection, your app will continue
functioning correctly.
Every client connected to a Firebase database maintains its own
internal version of any active data. When data is written, it's
written to this local version first. The Firebase client then
synchronizes that data with the remote database servers and with other
clients on a "best-effort" basis.
Very NEW to Firebase, just came to know about firebase (through Google 2016 IO).
https://firebase.google.com/docs/database/android/save-data
Firebase hosting is not for server side processing.
It stores static assets of your website as a world-class high availability CDN. So websites hosted here loads very fast. Even in high-availability scenarios.
So you have to do processing at other server which then connects with firebase and stores userinfo in realtime database.
Firebase has put limits on userinfo to be placed in directly for users auth dashboard.
For detailed userinfo, firebase realtime db is the way to go(from your processing backend to firebase realtime db).
Further Reading: What kind of web applications are Firebase not ideal for?
I have a couple of questions on Firebase. I went through their documentation on their site, and the tutorial. I've never used anything like this before, so it's a bit confusing:
I see there is a REST API and a Javascript API. Is the main difference that the REST API is more like a traditional API and requires polling, whereas the Javascript API allows you to receive deltas from Firebase itself?
I want to create a service that receives these deltas and stores them in my own database. But I don't understand how Firebase can keep a connection open for so long. I'm assuming there must be a connection open that Firebase pushes the data through back to my service. Is there a time limit? Or if the connection gets closed is the best practice to detect this error and re-login?
There are many differences between the Firebase REST API and its client libraries. The biggest difference is indeed that most REST clients don't use a persistent connection. But REST clients can listen for changes too, using Firebase's SSE based REST Streaming.
Firebase uses web sockets to establish a persistent connection from the client to the server. On browser platforms where web sockets are not available, the client falls back to HTTP long-polling.