Live data from Hacker News

Fetch API has landed into Node.js

github.com

151–160 of 210 posts

Re: Fetch API has landed into Node.js

#151
post #18
post #16

My biggest issue with node when I was working on it briefly was I couldn't do the 'import' statements like wepback. Are they supported too now? I'm not a web developer so I had a very hard time understanding why there are so many different type of imports in JavaScript like require, import, umd, amd, etc and which one works in browser and which one works in node? Also why do so many libraries have this strange 5 line…

Those have been supported for several years now :) You need to tell Node to use the format by either naming your file `.mjs` or setting `"type": "module"` in your `package.json` file. > Also why do so many libraries have this strange 5 line header code for this umd, amd, business. Is that to make their packages work with nodejs? That's just old for "adapt the module system" from the old days and libraries just didn't…

Several years is a bit of an exaggeration. They were "experimental" until 20 months ago.

Re: Fetch API has landed into Node.js

#152

Earlier quoted context omitted.

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!

Yea, so instead it would just encourage more 3rd party libraries doing random things on your site. This is what happens in native. Instead of embedding an ad in an iframe and isolating its damage you embed your ad service's library in your code and it spies on way more activity than it ever could otherwise.

I would also be okay (ish) with explicitly isolated third-party code execution, like your example of an iframe to a different domain. I'm pretty sure that should already be the case with iframes, in fact (you obviously shouldn't be able to embed an iframe to facebook.com on your website and then use your website's JavaScript to inspect the DOM on that facebook.com iframe).

Re: Fetch API has landed into Node.js

#153
post #148

Earlier quoted context omitted.

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?

Yes, I think the normal way to integrate an app with an HTTP API is via the browser. 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.

Has it ever occurred to you that your users can (a) see all requests you make to third party services, including your credentials and client secrets, (b) modify and replay those requests at will and (c) spoof responses from those services?

Re: Fetch API has landed into Node.js

#154
post #142

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…

There's a relevant spec issue here https://github.com/whatwg/fetch/issues/973

Oh, good. The first comment there references my closed issue from 2017, but it's nice to see this being given some more consideration.

Re: Fetch API has landed into Node.js

#155

Earlier quoted context omitted.

Yea, so instead it would just encourage more 3rd party libraries doing random things on your site. This is what happens in native. Instead of embedding an ad in an iframe and isolating its damage you embed your ad service's library in your code and it spies on way more activity than it ever could otherwise.

I would also be okay ( ish ) with explicitly isolated third-party code execution, like your example of an iframe to a different domain. I'm pretty sure that should already be the case with iframes, in fact (you obviously shouldn't be able to embed an iframe to facebook.com on your website and then use your website's JavaScript to inspect the DOM on that facebook.com iframe).

[deleted]

Re: Fetch API has landed into Node.js

#156
post #148

Earlier quoted context omitted.

Yes, I think the normal way to integrate an app with an HTTP API is via the browser. 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.

Has it ever occurred to you that your users can (a) see all requests you make to third party services, including your credentials and client secrets, (b) modify and replay those requests at will and (c) spoof responses from those services?

I think the misunderstanding is, beyond special cases like a payment processing, why would you be calling third party services from your service? When I think of calling a 3rd party HTTP API, I am thinking of public APIs, like say a widget that shows the weather in a users area.

Re: Fetch API has landed into Node.js

#157

Earlier quoted context omitted.

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!

Yea, so instead it would just encourage more 3rd party libraries doing random things on your site. This is what happens in native. Instead of embedding an ad in an iframe and isolating its damage you embed your ad service's library in your code and it spies on way more activity than it ever could otherwise.

It's pretty funny that such an RPC framework as the browser exists that gives the end user a genuinely decent sandbox, yet all it receives is criticism for its flaws. People will then happily install a screen dimmer or "productivity" tool with superuser privileges from a completely untrusted source.

Re: Fetch API has landed into Node.js

#158

As someone browser focused this surprised me. I've been using fetch() for years now.

Not every browser API is an instant candidates to be added to Node's core. If there isn't a big performance hit from doing it as a user library or lack of functionality to do it as such in the first place then it's rare it'll be brought into core right away, if it will at all. It's nice to see the really popular ones make it in though, makes for fewer dependencies when doing browser compatible projects and also allow…

This is what frustrates me so much about javascript. Everything is all over the place.

Re: Fetch API has landed into Node.js

#159
post #131

Earlier quoted context omitted.

Hi there, > ...we'd love to hear from the community what you'd like to see. In our tests, fetch on Deno was wayy faster than undici fetch that now has been merged into nodejs. I couldn't figure out why that was case, but forwarding requests over node's http2 client (instead of undici fetch ) then had comparable (but not as fast) performance as Deno (presumably because our hand rolled impl lacked connection pooling).

This is very new and the implementation _just_ landed today so it makes sense Deno would be faster with an API they have been working on for years. I am confident that Node's implementation will _eventually_ have comparable performance. That said: please do open an issue in the undici repo at https://nodejs.org/node/undici so this gets tracked.

That URL gives me a 404 – should it be https://github.com/nodejs/undici ?

Re: Fetch API has landed into Node.js

#160
post #156

Earlier quoted context omitted.

Has it ever occurred to you that your users can (a) see all requests you make to third party services, including your credentials and client secrets, (b) modify and replay those requests at will and (c) spoof responses from those services?

I think the misunderstanding is, beyond special cases like a payment processing, why would you be calling third party services from your service? When I think of calling a 3rd party HTTP API, I am thinking of public APIs, like say a widget that shows the weather in a users area.

I'm going to take a wild stab in the dark here and guess that despite having the title "senior", you have little or no experience in commercial software development? Because what you dismiss as "special cases" covers a vast amount of the plumbing of the modern web. In modern apps even something as simple as storing and retrieving files requires HTTP calls at some point in the stack, and such calls should never under any circumstances be initiated from someone else's computer.

Which brings us back to the original question you responded to above. Contrary to your odd views of how software is architected, issuing HTTP requests from the backend is both normal and common enough to be banal. Node adopting the fetch API is generally a good thing as it allows JS developers to code against the same interface whether they are working from the frontend or the backend.

Post reply on HN