node-fetch support

[solsson]

I've done various examples with lambda-style js in microservices contexts, bundled using for example esbuild. The blocker for real world applications in those cases has always been that there are legitimate needs for consuming HTTP resources or emitting HTTP side effects.

What's your take on this?

While the http and https Node APIs are quite big, an alternative would be to maintain compatibility with node-fetch instead. Bundles could embed the node-fetch lib (which at runtime depends on http, https, zlib, stream ... and more) or somehow allow it to be injected/required/imported.

[caoccao]

Thank you for raising this. Here are my thoughts for your reference.

Node.js Mode or V8 Mode?

Javet provides both Node.js Mode and V8 Mode. Some Javet users just use the Node.js mode for its rich ecosystem regardless of its insecure nature. That's completely fine for Server Side Rendering (SSR), Serverless Computing. I wonder if your use case is qualified for this kind of non-client facing usages, you may directly use the Node.js mode and the problem is solved.

However, some Javet users expose the JS runtime directly to the end users who are capable of executing arbitrary JS code. Security becomes one of the top concerns held by the architects during the architectural investigation. In that case, I recommend the V8 Mode + Javenode.

Priority

One of the challenges faced by Javenode is there are so many Node.js modules, but I don't have time implementing them. Of course, even if I worked 24x7, I wouldn't be able to scale enough to cover all of them. So, I believe it's a community driven thing.

For now, even some common modules, e.g. http, zlib, etc. are not implemented yet. If node-fetch is good enough, either I will prioritize it or you may follow the current architecture (on vert.x) contributing to Javenode.

Summary

For now, Javenode is an infant who needs to be taken well care of by the community. I believe Do It Yourself will remain the guiding principle for quite a long time.

[solsson]

Thank you, "do it yourself" is the realistic answer. I was actually surprised to see Javenode advertised from the Javet readme, and increasingly surprised to see a commitment to future fs module support. Otherwise I wouldn't have asked. IMO http support is higher priority, and lower risk, than fs support.

Regarding my use case "directly to the end users" is out of scope. The end users in our case are trusted developers. We can still restrict HTTP traffic if necessary using out-of-process means.

[caoccao]

IMO http support is higher priority, and lower risk, than fs support.

That makes sense. My development for Javenode is just for fun (no one pays me). So, I'm fine with http over fs. Of course, my fingers are crossed.

Regarding my use case "directly to the end users" is out of scope. The end users in our case are trusted developers. We can still restrict HTTP traffic if necessary using out-of-process means.

I guess restrict HTTP traffic is a valid reason why the Javet Node.js mode is not suitable in your case. Does that mean your application allows the guest script to access the network with complete governance, e.g. bandwidth limit, protocol limit, remote address limit, etc.? If the answer is YES, I think a Javenode native network module would be an attractive solution.

By the way, I checked out the product list you seem to be working on. I guess you are looking for a scripting language integration to further empower those products, right? If you are interested, you may reach me at discord for more discussion.