Replies: 1 comment 2 replies
-
|
Hello @Meettya! Thank you for your interest in Wasm Workers Server!
Production readiness is a broad topic. However, at this time Wasm Workers Server focus is on the developer side of the story. This doesn't mean focus won't be production readiness in the future, just that our current efforts are going to making developing easier and straightforward with multiple languages thanks to WebAssembly. We don't have test coverage metrics yet, which would be nice to have. At this time, we have some unit tests on the parts of the code that we thought were good to have, but certainly increasing the coverage is always good. We also do have some e2e tests that cover endpoints in multiple programming languages (https://github.com/vmware-labs/wasm-workers-server/blob/main/tests/e2e.rs). Of course, all these tests are gating the release of a new version, so that all of them must pass before we cut a new release.
You are absolutely right. Thank you for pointing that out; we are aware of this issue and it has to do with the priorities we have for the project right now, which is to make it feature-full as well as stable and easy to use. The JavaScript shim, that is the code that surrounds your JS functions, automatically added by wws is growing a bit in order to be more feature-full (e.g. #149). All this developer-focused features end up adding up in the response times. However, we have plans to use wizer (https://github.com/bytecodealliance/wizer) to perform pre-initialization, so that JS workers can start right away, once the interpreter has done the initial load of the common code, or by pre-compiling the polyfill (e.g. #242). All in all, you are correct in that the latest release has a bit of a cost in terms of response times. However, while we are maximizing now on making easier the developer story, there are other things that could improve -- and will, when we have the cycles. -- Namely, and in no particular order,
You can check our list of issues (https://github.com/vmware-labs/wasm-workers-server/issues) to get a grasp of what's coming next, or what are the things we are considering next. We also welcome contributions!, so if you want to check a good introductory issue you can look for it among the "good first issues" list, or you can create your own if you think something is missing! Thank you again :) |
Beta Was this translation helpful? Give feedback.
-
|
Hello @ereslibre ! Thank you for this exhaustive answer. I believe this amazing and important project have bright future. And I will try it on my pet projects, have some ideas :) |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Meettya! Yesterday, I reviewed the JS engine performance and confirmed a x10 performance improvement after caching the JS polyfill. It’s still WIP, but we expect to publish it in the next version 😄 You can find a quick benchmark on the PR: #257 Thanks! |
Beta Was this translation helpful? Give feedback.
-
First of all - if we are having v1.7.0 - is it ready for production? Its stable and well-tested? I can`t find any notions about it in docs.
Second, I try JavaScript Hono example with local ab bench and not sure about results. I see
Requests per second: 151.47, isn`t low? May be my setup incorrect, but has you compared wws with mainstream solutions? Like nginx, nodejs, etc. I realise it's not fear comparations and wws build with another core idea, but it used to serve data to web, and have same function.Beta Was this translation helpful? Give feedback.
All reactions