Sandboxed execution of V8 - restrict FS and Network Access? about v8go HOT 5 CLOSED

@mitar Take a look at https://github.com/tmc/reactssr
And https://github.com/kuoruan/v8go-polyfills

from v8go.

You can use v8go to do SSR; but the current implementation would require you to have a pre-built bundle.js file (via webpack for example) and then run your render inside of v8go with your data.

I'm planning on creating an example project to demonstrate SSR (with React).

v8go is only the javascript interpreter; so does not give you access to the filesystem, or network; you would have to do this on your own within your Go project; but I guess it is possible.

from v8go.

It would be possible but then technically you're embarking on a similar project to Node/Deno. In comparison, Dahl (the Node creator) has a v8worker2 project that lays foundations for this type of implementation as an early investigation into Deno's implementation.

If I remember correctly he attempts to optimize the cgo bridge by using ArrayBuffer (https://github.com/ry/v8worker2#difference-from-the-original-v8worker). This creates a safer interface between what V8 outputs and what Go receives. I'm only mentioning this because I noticed this lib uses strings which Dahl has identified can be slower. What you have here is a great interpreter and I'm not sure if you want to extend it, but I feel like it would be very useful to a broader community.

What I feel is missing in this particular niche is a Go-V8 binding that focuses on giving developers the ability to decide their own bridge interface. Hopefully I describe this adequately but it would be neat if developers could define the bridge interface (the contract between Go/JS) in a format that focuses on performance. Then they can add whatever low-level Go-based bindings they wish ie. FS or similar methods. This cleans up and hopefully improves performance between controlling the JS action.

I'm wondering if FlatBuffers could be used for the data exchange as well. Basically a developer could flesh out the .fbs describing the interface, then write both JS and Go based handlers on each side. :-)

If this is the direction you decide to take the project, I'd be interesting in helping out.

Edit: I did some digging and in a couple conversations on the Deno project they moved away from FlatBuffers because of performance constraints. If you look at v8worker2 he's definitely using ArrayBuffer: https://github.com/ry/v8worker2/blob/8aa233cd35a99264c75c4a045a8d27429b2376f4/binding.cc#L345.

from v8go.

I'm currently working on adding support for ObjectTemplate and FunctionTemplate, which would enable the caller (you) to create your own objects and functions between the JS world and the Go world. (see #64)

I've also added a section to the README entitles "Project Goals":

To provide a high quality, idiomatic, Go binding to the V8 C++ API.

The API should match the original API as closely as possible, but with an API that Gophers (Go enthusiasts) expect. For example: using multiple return values to return both result and error from a function, rather than throwing an exception.

This project also aims to keep up-to-date with the latest (stable) release of V8.

By this, you can use ArrayBuffers as you please to pass data structures between the JS and Go, or any of the other value types that are supported (see #59)

As we already have #28 I'm going to close this issue, but feel free to re-open if you think this is unanswered.

Thanks again for your interest in this project.

from v8go.

@rogchap Have you got to make a SSR example? I think that would be great! I also wonder about performance of such approach to render content (some comparison with node would be interesting, just to know how it compares when deciding what to use). And the overall architecture would also be nice to see, e.g., do you create a new V8 context per request, or do you do something else.

from v8go.