141–150 of 210 posts
Good for NodeJS However, I feel the fetch API is completely botched because it lacks timeout support. I have cobbled some together for https://github.com/Backblaze/gists/pull/8 but gosh. I really hope all that is actually not necessary :/
Also, keep in mind that the linked solution does not abort the web request. It only aborts waiting for the response in the JS code. The browser does not close the connection.
I love fetch, except for the way that it combines headers. If more than one of the same header is set (such as multiple set-cookie headers), it combines them all into a single comma-separated string. I know this is allowed in the HTTP spec, and it's probably even a sensible default. But the fetch spec doesn't allow any access to the raw headers, so there's no straightforward way to get the original uncombined headers…
Earlier quoted context omitted.
Where can I find an explanation about what is Fetch and why it should be in Node.js?
It looks like it is a new standard: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API I thought it was a Node popular library.
Earlier quoted context omitted.
Yeah. What's your point?
Comments like “it’s standard” do not answer the original question: “I'm curious why Node core has decided to make this an official part of Node?” The standard describes many functions and classes. What makes fetch more land-able than e.g. the event system, of which node has incompatible implementation? Or feature detection via navigator. Why it? What were the main point(s) of adding fetch specifically?
If something is standard, and it makes sense in the context of a backend, then it's convenient to just use the same API on both ends. Navigator makes almost no sense on the backend unless maybe it worked as a dummy polyfill object.
Earlier quoted context omitted.
Quick question, judging from the commit alone this seems like a rather small change. I assume there's more to it though. I just wonder how come features like this that kind of seems obvious to include in the ecosystem takes quite some time to land? I understand the reality is more complex perhaps, so I am genuinely curious. I hope you realize no disrespect, this will greatly improve the daily work for me since I use…
The commit adds undici (another Node.js project at https://github.com/nodejs/undici ) as a dependency and exposes its `fetch` - the code changes you see are probably just adding a flag :) > I just wonder how come features like this that kind of seems obvious to include in the ecosystem takes quite some time to land? I answered that below (check it out) but note how expensive adding a bad API is vs. asking people for…
Node uses undici JS library. Undici includes a C HTTP parser that is used via webassembly. The parser is generated from rules that are implemented in JS/TS using llparse framework.
A native C binary there in the middle is quite surprising.
Hey, Node core person here (and the person who triggered the land) - we're super excited for this and would love help and feedback. This is still experimental and we'd love to hear from the community what you'd like to see.
Earlier quoted context omitted.
Intercommunicating backend services isn't new, but having an HTTP API call another one from the backend is a case that used to be more normally accomplished by calling both APIs from the frontend. The slow ooze of browser-oriented thinking onto the backend took time. Existing backend engineers, who thought it a harebrained scheme, had to eventually wear down, and give up.
So when you write an application that integrates with an external service via an HTTP API, you think the normal way to architect such an application is to make all API requests from the browser? And you think that making such calls from the backend is a new and "harebrained" idea that backend devs have been forced to adopt against their better judgement? I'm curious to know what position you occupy in our industry?
Calling an external API from a backend that integrates directly with an client app has been rare for me. Payment processing is all that comes to mind, and that was usually through an imported API package. I've made data scraping tools, but they were unique projects, not part of an app backend. I am a senior full-stack webdev.
Hey, Node core person here (and the person who triggered the land) - we're super excited for this and would love help and feedback. This is still experimental and we'd love to hear from the community what you'd like to see.
Earlier quoted context omitted.
In that in the browser you are able to see that you have gotten a 301/302 response but can't see where the redirect would have sent you.
Oh right, because they don’t want cross-site scripts to be able to see redirected URLs since they could contain secrets. I wish we could completely do away with cross-site scripts and just have nice things!