I have been using the asynchronous abilities of Node.js from quite some time now. But I am stuck on an interesting problem. Basically I have 2 API's that I need to call one after the other. Due to the asynchronous nature of Node.js I cannot retrieve the response of the first API request till it has finished and the respective callback function is called.
What I want to do is that I want to pass the response from the first API as request payload to the second API on the fly and not wait till the first API gets fully completed.
As a possible alternative, should I switch from building rest API to stream APIs?
Any pointers on how to do this?
Thanks
Yes, converting REST API'S to stream API is a better option. Node.js is known for its asynchronous behaviour. Because of the same all REST api's function in the same manner as you described earlier. As someone has previously pointed you could look at the Twitter Stream API for reference.
For more understanding you can check out this link - How to create a streaming API with NodeJS
Related
relatively new to Node.js and I've found that there's a lot of support for multiple callback functions. I'd love some help in understanding the applications of having such a structure (why isn't one enough?) Thanks!
Might it have something to do with making async requests in our callback functions?
i.e. I'm taking handling a get request, and must first make a get request of my own before ultimately returning the request to the client.
I'm using the react-activities-feed components to manage the user side of feeds for our web app. The documentation is very lacking and I'm trying to figure out how to customize how the with a callback for making the post. I think it's the doRequest property, but I'm not 100% sure.
EDIT: It IS doRequest and it just expects a promise as a return. However... When I do my own doRequest and just console.log the input it's the activity. Which it great, BUT the images are already uploaded in this activity and have URL's
How do I hijack the image upload process and use my own? I use Google Cloud buckets with signedURL's.
I'm new to graphql and just wanted to ask which operation executes completely first? Query or Mutation? I went through the docs and it mentions queries are in parallel, and mutations are serial, but if both are present, which one completes first?
I'm trying to convert a GET and POST rest API route to graphql. And the request body of the post request will be the response from GET call. Can anyone tell me how can I implement this logic? I couldn't find any demo/online tutorial for same. Here's one of my previous questions regarding graphql for code purposes.
I'm a student who's newbie to the world of APIs and I'm working on an assignment where I have to create a NodeJs rest API that would call a SOAP service, transfer the XML response into a JSON object and return it to my angular project that calls this API.
I have looked around and found very little information about this, so is there a good place for me to start (Tutorial, courses, etc..) ?
looking forward to receiving answers because my passing grade is on the line :( </3
You need to break up this problem into multiple steps.
How do we make a rest-api in nodejs?
See a link like: https://www.codementor.io/#olatundegaruba/nodejs-restful-apis-in-10-minutes-q0sgsfhbd
OR How to best create a RESTful API in Node.js
How do we call a soap service from nodejs?
See e.g. SOAP Request using nodejs
How do we call our rest-api from angular?
https://angular.io/guide/http OR
Call Rest API From Angular Application
So break the problem up into steps, find the tutorials that help you implement that part, and put it all together.
Also use console.log and JSON.Stringify to debug your objects. E.g. see: https://levelup.gitconnected.com/5-ways-to-log-an-object-to-the-console-in-javascript-7b995c56af5a
If I understand correctly, a preflight OPTIONS request is sent as a way of asking "what's allowed here?". Then, once the response comes, if allowed, the calling site sends the POST request (or GET but in my case it's a post). I have figured out that, at least with Azure Function Apps, the OPTIONS request is executing the code that I expected only the POST to execute. I believe this to be the case because once I added some null checking (since the OPTIONS request doesn't have a payload in the body) everything worked fine.
I'm wondering if this is standard.
Seems to me that if I had written the API without using Azure Function Apps, I'd have the OPTIONS request sent down a path that would set the appropriate headers and return a 200 response. And the POST request would be sent down a different path that would expect a payload in the body. If that's how it usually works then that means I've just found an idiosyncrasy of the Azure functionality. But if not it means that I have something to learn about the OPTIONS preflight request.
Thanks in advance for your advice.
Denise
As sideshowbarker mentioned, the OPTIONS request is sent automatically by the browser to check if the cross-origin request can be made.
In case of Azure Functions, this will handled by the Azure when running in the cloud.
If your function is being triggered, that would mean that you have "options" as a supported method for your HTTP Trigger
In the HTTPTrigger attribute for C# functions
In functions.json for non-C# functions
If you want to customize the CORS responses and/or running functions in a container, you could always include "options" as supported and respond differently when the incoming HTTP method is OPTIONS.
Also, if you are using Azure API Management with Azure Functions, you could offload CORS handling to it instead or even use Functions Proxies as shown here.
Thanks y'all! Sorry I was unclear. And sorry it took me a while to get back. Things have been a bit crazy on this end.
Yes, the function being called is mine. And now I understand the browser doesn't have much choice as to whether or not it makes the OPTIONS call.
And yes, I could make my Azure function handle an options call differently and thanks for that suggestion too. That's sort of what I ended up doing but basically I did it by handling an empty payload. I didn't follow that best practice originally because I thought any valid request would have a payload. Accordingly, any request that did not have a payload was invalid and should be turned away as a failure of some sort. This was before I knew that the OPTIONS call was actually executing that function.
My remaining question is if I had NOT been using Azure... if I had rolled my own solution and hosted it somewhere, I'd have a class or at least methods that handle calls to this particular API. (This is something I'm new to so bear with me if my terms aren't quite right and please do correct me). So if I'd done my own API, I'd have one method to handle a POST call and a different method to handle an OPTIONS call, wouldn't I? And the method that handles the OPTIONS call would return information about what's legally do-able with this API. And the method that handles a POST call would handle the payload sent with it. And the method that handles the POST wouldn't get executed when an OPTIONS request is sent. At least that's how I figured it would work. And that's my question -- is that how it's done when not letting something like Azure handle some of the infrastructure?
I'm just trying to learn if the OPTIONS request executing a POST's function is a standard practice or if it's some kind of idiosyncrasy to working with Azure functions.
Thanks again for the advice and for helping me understand these questions.