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.
Related
after reading this answer https://stackoverflow.com/a/51614256/15486192 from #Arsam, i am successfully sending data from nodeMcu esp8266 to firebase.
but i am using Database secrets Although it is deprecated.
and while searching for an alternative i came across firebase REST
Firebase Database REST API
API Usage
You can use any Firebase Realtime Database URL as a REST
endpoint. All you need to do is append .json to the end of the URL and
send a request from your favorite HTTPS client.
HTTPS is required. Firebase only responds to encrypted traffic so that your data remains safe.
after reading that, anyone conclude that you can send data to firebase using HTTPS request.
so my questions,
is REST API just an HTTP request?
i am just confused if it is, then why just not naming it HTTP API?
can i send my data to firebase Realtime-database using only https request from my client?if yes then how
REST or RESTful API design (Representational State Transfer) is designed to take advantage of existing protocols. While REST can be used over nearly any protocol, it usually takes advantage of HTTP when used for Web APIs.
Be carefull when using the REST API on the client side!
The REST API for the Firebase RTDB is usualy ment for development of code where you don't wand or can't use the official SDKs. For example when you code in a language that doesn't have a official Firebase SDK. Or also in usecases where you because of perfromacne reasons don't want to use the SDKs. In most cases landing pages.
BUT. The REST API is very handy for public data in your database. And I would only recommend to leave public data only the read access. Othervise anyone could fill up your database with knowing your REST API.
So if you plan to use the RTDB on your client side try to use official SDK because the handle the security for you.
David East even had a talk on the last Google IO on how to improve the loading time for laning pages by removing the Firebase SDKs and using the REST API. But that was also only for public data.
If you want to use it on a server from the backend you can use also the REST API. Here is the documentation for using the REST API and here for the authentication part of it.
I'm a newbie to DialogFlow and I don't event know if what I want to achieve is possible.
I'm trying to create a DialogFlow intent that would make an HTTP request from the user device after receiving a given command. I know how to do this with webhooks, but problem is that webhooks HTTP requests come from Google servers, and not the user device.
The reason why I want the request to come from user device is that the receiver will only listen to local network (it's a web server running in an internet router). So this will only work if the HTTP request comes from a device connected to the router.
A workaround could be to create a public tunnel to the router (with softs like ngrok), but my application aims at real users, so I would prefer to avoid this complex setup.
Is it possible to do local requests with DialogFlow? Or is there another Google-Assistant API I could use for this purpose, like Google IoT solution?
Thanks
You could do this, but you wouldn't necessarily do it like a regular Dialogflow project. Here are the steps:
Build your Action through Dialogflow and add web fulfillment
Add a way to push a notification of some sort to your local device
This could listening to a database, polling, push notifications, etc.
When your device gets that notification, it performs the action locally
If you want this local action response to be sent back, you could update the webhook through an HTTP response (if making an HTTP call) or updating a field in a cloud-based database.
Actions do have a timeout of around 5 seconds to get a response, so be aware of that limit if you want to do this
I have a Firestore database which I want to populate with data that is delivered by a live sports event API. This API offers to push the data, so I get new values every time some event happen in a selected game - so we don't have to pull new updates all the time.
However, the delivery method is a websocket which means, that we should open a web socket to a certain endpoint, and then we'll get the data updates.
How could we do this in Firebase? If it was just a simple webhook with an HTTP call, it would be easy to make a firebase functon that could receive the posted data.
But is it possible to do something similar with a web socket? I guess that keeping a Firebase Cloud Function running 24/7 with the web socket is not a good idea at all.
What you're describing is not supported by any Firebase products, and definitely not Cloud Functions. Cloud Functions doesn't support websockets at all, nor does it support any streaming. On top of that, the max lifetime of a function is 9 minutes.
If you absolutely need websockets, consider a different backend infrastructure instead, such as App Engine.
I'm using the react native firebase sdk and am wondering about how the underlying network calls are implemented. When making firestore get queries, is the sdk just keeping a socket open when it's initialized and make requests over the open socket, or does it make individual http requests to an endpoint?
Specifically I'm looking for an efficient way to get a batch of documents (profile thumbnail properties given a batch of profile ids), and I saw an answer that said that firebase calls are pipelined so calling the gets in parallel is efficient. However, I'm not sure if that applies to firestore as well.
The Firestore SDK uses gRPC to communicate with the server. This is the same layer that many of Google's other Cloud products use under the hood. It is quite different from the Web Sockets communication layer that the Firebase Realtime Database relied on.
Digging into the code it seems like the "real time" part of firebase uses websockets. The database module also has a dependency on
faye-websocket
In an interesting blogpost about 'Firebase Authentication with the Firebase 3.0 SDK and Auth0 Integration', it is stated that:
You can even have Firebase communicate with Webtask!
Now I can imagine the (web)client triggering a Firebase operation and subsequently a Webtask, but not the other way around. Or am I missing something?
Firebase can run as a serverless app, but it can also run on the server. You can even have Firebase communicate with Webtask! (sic!)
I think that paragraph is misleadingly phrased, perhaps it was just added at the last minute to spark interest. You can have a webtask communicate with Firebase, not the other way around. You don't "run Firebase" on your server either.
TL;DR: A client application may call a webtask with an HTTP request, and that task can read/write the database, but not in any other order.
Here's a quick and dirty reality check as of Nov. 2016:
The Realtime Database by itself does not provide you with a way of executing code. This includes responding to database changes and user requests, handling fan-in and fan-out operations, etc. There is no support for webhooks either.
Which means you have to provide your own execution environment for such logic on a custom server, or you can try to cram as much as possible into the client code. This is a pretty exhaustive topic by itself.
Webtasks are short-lived functions that respond to HTTP requests. Their lifecycle always starts with a request, so they are not fit for continuously watching the database for changes. But they are perfectly valid for handling requests coming in from your client application.
As you can store "secrets" for the webtasks, you can authenticate the task on an admin access level. This gives you the possibility to verify client tokens – which should be sent along with the request –; perform complex authorization and validation, and perform RTDB write operations you wouldn't trust the clients with.
Or trigger external services securely. The possibilities are close to endless.