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!
Related
I'm confused about why so many of the examples for NextJS revalidation use a separate endpoint for revalidation. Is that because some folks set up some polling to revalidate via that endpoint?
For my use case, I have a route and when the user makes an update to it I want to call revalidate... But I would rather not have to call fetch and make a separate call and just use the existing NextApiResponse object to revalidate the route. Is this a bad practice for some reason?
With the latest Firebase Update callable functions were introduced. My question is whether this new way is faster than the "old" http triggers and if it is more secure.
I have no expertise in this field, but I think the HTTP vs HTTPS might make a difference.
This is interesting to me because if the callable functions are faster, they have that advantage, but their disadvantage lies in the nature of flexibility: They cannot be reached by other sources.
If the callable functions have no advantages in terms of speed or security I do not see a reason to switch it up.
Callable functions are exactly the same as HTTP functions, except the provided SDKs are doing some extra work for you that you don't have to do. This includes, on the client:
Handling CORS with the request (for web clients)
Sending the authenticated user's token
Sending the device instance id
Serializing an input object that you pass on the client
Deserializing the response object in the client
And on the backend in the function:
Validating the user token and providing a user object from that
Deserializing the input object in the function
Serializing the response object in the function
This is all stated in the documentation. If you are OK with doing all this work yourself, then don't use callables. If you want this work done automatically, then callables are helpful.
If you need direct control over the details of the HTTP protocol (method, headers, content body), then don't use a callable, because it will hide all these details.
There are no security advantages to using callables. There are no speed improvements.
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).
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.
http://docs.meteor.com/#meteor_methods
I have tried it in publish.js in my server folder.
I am successfully calling Meteor.apply and attempting the server call from the client. I always get an undefined response.
Calling Meteor.methods on the server is correct. That will define remote methods that run in the privileged environment and return results to the client. To return a normal result, just call return from your method function with some JSON value. To signal an error, throw a Meteor.Error.
On the client, Meteor.apply always returns undefined, because the method call is asynchronous. If you want the return value of the method, the last argument to apply should be a callback, which will be passed two arguments: error and result, in the typical async callback style.
Is your server code actually getting called? You can check that by updating the DB in the method and seeing if the client's cache gets the new data, or calling console.log from inside the method body and looking at the output of the "meteor" process in your terminal.
There are several places I can define my Meteor.methods() (with pro's and con's):
On the server only - when the client calls the method, it'll have to wait for the server to respond before anything changes on the client-side
On the server, and uses a stub on the client - when the client calls the method, it will execute the stub method on the client-side, which can quickly return a (predicted) response. When the server comes back with the 'actual' response, it will replace the response generated by the stub and update other elements according.
The same method on both client and server - commonly used for methods dealing with collections, where the method is actually a stub on the client-side, but this stub is the same as the server-side function, and uses the client's cached collections instead of the server's. So it will still appear to update instantly, like the stub, but I guess it's a bit more accurate in its guessing.
I've uploaded a short example here, should you need a working example of this: https://gist.github.com/2387816
I hope some will find use of this addition, and this doesn't cloud the issue that methods are primarily intended to run on the server as debergalis has explained.
Using Meteor.methods() on the client is useful too. (look for "stub" in the Meteor.call() section too...)
This allows the client to (synchronously) simulate the expected effect of the server call.
As mentioned in the docs:
You use methods all the time, because the database mutators (insert,
update, remove) are implemented as methods. (...)
A separate section explaining use of stubs on the client might ease the understanding of methods calls on the server.