Fast Vue SSR with Rust and QuickJS

QuickJS is a simple interpreter, no JIT, so performance obviously won&#x27;t be competitive with V8.<p>The appeal is that it supports most of ES2019 while being a easy to build, light weight dependency that can be embedded into Rust applications. [1]<p>Would I use something like this for a production service with a high traffic volume? It would be nice to see benchmarks, but most likely not.<p>But if you have a Rust backend and want a simple way to do SSR without having to operate a separate Node service or linking v8, this might be a neat approach.<p>ps: It would be nice to run QuickJS in a WASM runtime, while still offering the same convenient API surface for Rust. This would provide sandboxing for the QuickJS C code. It&#x27;s is in my backlog, I might get to it eventually. [2]<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;theduke&#x2F;quickjs-rs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;theduke&#x2F;quickjs-rs</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;theduke&#x2F;quickjs-rs&#x2F;issues&#x2F;11" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;theduke&#x2F;quickjs-rs&#x2F;issues&#x2F;11</a>

So, how is it &quot;Fast&quot;, without any performance benchmarks? Are we just assuming that it is fast just because it is written in Rust?

It seems that there is a JS context per worker and the workers are shared among different requests. Further, the requests are handled by simple string formatting and eval in the JS context. This means that it should be trivial to inject arbitrary js codes in the server and initiate a XSS attack.

If memory is the concern, node V8 Engine has the mode &quot;lite&quot; mode: <a href="https:&#x2F;&#x2F;v8.dev&#x2F;blog&#x2F;v8-lite" rel="nofollow">https:&#x2F;&#x2F;v8.dev&#x2F;blog&#x2F;v8-lite</a><p>with that perhaps you could spawn node to all threads and do even better in terms performance&#x2F;memory?

Be aware about a couple of issues in the implementation:<p>- The Warp handlers are blocked by the use of thread-blocking synchronization primitives (locks, channels) - which might harm performance and can even lead to deadlocks.<p>- The architecture with &quot;passing work off to a threadpool via a chnanel and waiting for it to complete&quot; is not very resilient, and prone to behave badly under high load. The reason is basically the inifinite queuing - if new requests come in faster than previous ones can be processed the queue length (and thereby the memory footprint of the app) will grow and grow. At some point the application will just be busy serving old queued up requests, which might already have timed out on the client side and potentially even being retried. That&#x27;s a vicious circle, and you can only get out ot it by shutting down the app. One way to fix this is to limit the queue&#x2F;channel size and perform load-shedding on requests which can not be enqueued.

I&#x27;ll definitely use this once Fabrice Bellard gets around to writing TinyRust.

I understand that Rust Hyper and&#x2F;or Warp provide a very fast httpd engine but I would have thought that invoking JavaScript via Deno&#x2F;V8, instead of QuickJS, was the natural integration.<p>Maybe Deno is hard to invoke from Rust Code.

I think you should post about this project to reddit: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust</a>

It’s been a observation for quite sometime add Rust to any heading and most likely will end up on top of HN.<p>Didn’t expect such a trivial thing to be in front of HN, but probably Rust marketing and evangelist are all on HN waiting to move them to top.<p>Stil waiting for good library in rust not dependent on C or unsafe code. Looking at most of the cargo libraries most good one’s are a wrapper around C or C++ library or use unsafe code.

Using JS to do SSR? How the turntables.

I hate post titles containing TLAs I don&#x27;t recognise.<p>(Three letter acronyms before anyone accuses me of hypocrisy)