I am starting to use Firebase Cloud function and it is generally great.
The only thing that is not clear to me is how to handle a failure of the process that runs in the trigger function.
For example - I have a trigger on Firebase Auth that creates a Stripe Customer on our Stripe account every time a new user is created.
It is possible that the Stipe API call will fail. In a "Normal" HTTP request I will return an error to the client that will respond accordingly, but on a cloud function I do not have a callback from the trigger (Or do I?)
Any Idea how to handle this while using cloud function?
Thanks
What you do in an auth trigger depends on the APIs you're calling. As you know, in HTTP functions, you return a response to the client for every code path that can occur. For all other types of functions (including Auth functions), you need to return a promise that becomes resolved when all the work is complete. If the Stripe API uses promises, you can simply use those (in addition to any others in your code) to return a single promise. If you have a promise in hand, you can know if its work fails by using catch() on that promise to trap the error.
I strongly recommend reading the Firebase docs on promises, and also looking at sample code (especially the Stripe example).
Related
I have an Express server running in firebase cloud function.
Currently, I am calling this cloud function from my client (assume it's a web client) using direct http call to url that was provided to me to access the function.
However, there is another method to call this function which is using thr firebase cloud function library for the client.
My question is : what advantage do I get ( in terms of speed ) if I use the library instead of the direct http call.
My assumption is that the library uses a web socket to accesd the function whereas the direct http call uses http call
I couldn't find anywhere in the documentation saying which one is better
Callable functions invoked using the Firebase SDK were not designed to provide any sort of increase in performance over a normal HTTP request. In fact, on average, you will hardly notice any difference between the two.
It's better to pick the one that meets your needs and preferences rather than thinking about performance. But if you really must choose the one that's faster, you should benchmark your choices yourself to see which one is better for your specific case.
See also: Are Callable Cloud Functions better than HTTP functions?
Say you have an HTTP endpoint which, when triggered, publishes a PubSub message and then sends a response.
There is another Cloud Functions which is subscribed to this event, performs what it needs to perform, and then ends.
How would you go about to trace the entire sequence of function executions triggered by an initial request (in this example, the first HTTP request)?
I see in the Google Cloud Platform logs there is a function Execution ID, but this changes with each function that is triggered hence it's hard to follow the sequence of executions. Is there an automated way of doing this? Or does it need custom implementation?
Thanks!
You will need a custom solution. If you want to trace this all the way back to the client request, you will need to generate some unique ID on the client, and pass that along to the HTTP function, which would then pass that along to the pubsub function via the message payload. And so on.
You might find it helpful to use StackDriver logging to collect the logs around that unique ID.
I am building application in nodejs where I have to display the data by hitting the HTTPS endpoint. I am using Swagger UI to display the data.
If this is the built in HttpService in NestJS, the service returns an RxJS Observable which by default is not awaitable. You can tack on a toPromise() to convert the Observble to a promise that can be awaited and should have the awaited response from there. Otherwise, you can remove the await and make the function non-async, returning the observable and letting NestJS subscribe to it under the hood.
Important side note: You'll need to make sure that you don't try to send back the raw Axios response, as there are circular references that Nest will not e able to stringify. Look into the observable pipe and map operators, or use a then after the toPromise() and map the response that way
If you are not required to user HttpService from NestJs, you can use request-promise-native or request-promise. These packages will return Promises by default and you can await them.
Hope it helps!
I have an application where the web ui (react) Cloud Function then runs and updates a completion value in the database.
How can I show a 'progress' indication and take it down when the Cloud Function has completed?
I initially thought I would do something like this pseudo code with Promises:
return updateDatabaseToTriggerFunctionExec()
.then listenForFunctionDoneEvent()
.then return Promise.resolve();
However, I'm not sure how to know when the function has finished and updated a value. What is the recommended way to detect when a triggered Cloud Function has completed?
You'll have to implement something like a command-response model using the database as a relay where you push commands into a location and the function pushes results out that can be listened to by the client that issued the command. The thing that makes this work is the fact that the locations of the commands and responses and known between the client and server, and they have a common knowledge of the push id that was generated for the client command.
I go over this architecture a bit during my session at Google I/O 2017 where I build a turn-based game with Firebase.
An alternative is to use a HTTP function instead, which has a more clearly-defined request-response cycle.
Is it OK practice to put additional logic into a Firebase HTTPS function, after the response was sent?
I have functions where this is happening:
write to the Firebase DB
once the write is done, I send back the response (this is where res.status(200 / 500).send() is
called)
I look up some FCM tokens in the DB and send a push message (it does not matter from a requester perspective if this is successful or not)
I understand that another pattern could be that I move step 3 to another DB trigger function to do the messaging. That would introduce some delay as I'd need to wait for that DB trigger function to fire.
My question is: is it safe to put additional logic to a HTTPS function after the
response is sent, or Firebase may start to cleanup / terminate my function already?
firebaser here
While your sending of FCM messages (in step 3) may frequently work, it is not reliable. There is no guarantee that the HTTP-triggered function will continue running after a response has been sent.
Precisely for this reason the Firebase documentation says:
HTTP functions are synchronous, so you should send a response as quickly as possible and defer work using Cloud Firestore.
So in your case, the documentation explicitly says to put the sending of the notification into a database-triggered function.