reactiverse
Is es4x production ready?
@Gondolav thanks!
es4x, is just a special launcher for Eclipse Vert.x. Vert.x itself is a very mature project that is running in production in many world known companies and powers many other frameworks/libraries.
What es4x does is, plugging to existing extension points of vert.x, for example:
https://github.com/reactiverse/es4x/blob/develop/es4x/src/main/java/io/reactiverse/es4x/ES4X.java
Extends the vert.x launcher
https://github.com/reactiverse/es4x/blob/develop/es4x/src/main/java/io/reactiverse/es4x/ESVerticleFactory.java
Implements a verticle factory
And:
https://github.com/reactiverse/es4x/blob/develop/es4x/src/main/java/io/reactiverse/es4x/Runtime.java https://github.com/reactiverse/es4x/blob/develop/es4x/src/main/java/io/reactiverse/es4x/ECMAEngine.java
Bootstrap a graaljs ecma2020 js engine to execute the code.
So, after covering mostly all the runtime code, applications will just be running vert.x APIs. These APIs are production ready, and I can also say that the code above is too.
While there are many modules in this repo, a closer look tells that most of the code here is "helper" code used during development, not production. For example:
- codegen - is helper to generate typescript definitions which aren't needed at runtime
- pm - is helper to automate working with npm and maven dependencies
- generator - is helper to generate all the npm modules published on each release to npm
To conclude, I'm quite confident that this code is production ready. The reason there isn't a 1.0.0 release yet is because there are still a couple of rough edges that need to be addressed:
- when I started the project typescript wasn't as evolved as now and to map the vert.x API's I had to use these abstract classes notation. Now that typescript has evolved, I should try to rewrite it to use proper interfaces as this would be a 100% exact representation of vert.x APIs
- pm has a few experimental commands (jlink which are hard to get to work with any combination of JVMs) and probably should do away
- sandboxing using JVM security manager is interesting as it kinda gives you some fine-grained security constraint to external code, however it will be removed from the JVM
- Now that es4x can work with remote modules e.g.:
import * from "https://server.com/module.mjs"we need to properly test it and also be able to download maven related dependencies
So, these changes should not affect already written application as they are as you can see, related to the "helper" development time code, not the runtime.
@pmlopes thank you for the thorough answer, very helpful! I'll certainly consider it for my next microservice, as I really enjoy Vert.x and using it with TypeScript could really be a gamechanger. For more practical questions, I should use Gitter right? Thanks again!