-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sandboxed execution of V8 - restrict FS and Network Access? #22
Comments
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. |
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. |
I'm currently working on adding support for I've also added a section to the README entitles "Project Goals":
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. |
@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. |
We are wondering if it was possible to use v8go for server side rendering Web-Apps in Environments, where Node is not allowed for security reasons around the npm ecosystem.
Would it be possible to:
The easiest way I could think of would be to:
Would that be a feasible / secure approach?
I know my question is rather an idea than a specific question, but any hints or resources that point us in the right directions would be much appreciated.
Thanks for your great work with this library!
The text was updated successfully, but these errors were encountered: