Vert.x Roadmap
This document present the Vert.x projects global roadmap for the next releases.
|
Note
|
This road-map is not set in stone and might evolve over time. This document reflects the actual commitments sustainable by the developer community. It does not exclude additional contributions to the roadmap and the feature set. |
-
Vert.x 4 modernizes a few important aspects of Vert.x 3 and breaking changes can be expected
-
Breaking changes should be kept minimal and used when it is necessary
-
3.x users will have an easy and documented migration path
-
dual asynchronous programming model
CompletionStage/ callback -
split package removal
-
tracing
-
focus on backend clients usability and offering
See this RFC for the details.
The asynchronous programming model will evolve to support CompletionStage in addition of the callback approach. It is a fundamental change for users and thus the callback model will remain (in addition a portion of our users are fine with callbacks according to a survey).
See this https://github.com/vert-x3/wiki/wiki/RFC:JSON-improvements for the details.
-
Currently, Jackson exposed publicly
-
Jackson data-binding is the culprit
-
Many CVEs
-
Bloated JPMS modules (java.desktop module)
-
Works with native images? (YES and NO)
-
2 potential solutions
-
Solution 1: make only Jackson data-binding classpath optional
-
Solution 2: make Jackson optional
-
Need solution for data-binding (jsoniter)
-
Need solution for json streaming (actson?)
-
Investigations
-
Investigate the use of https://github.com/FasterXML/jackson-jr as a lighter alternative to full jackson
Client that read/write tabular like data or read/write JSON should provide consistent API for mapping to POJO
e.g in Web client:
client
.get(8080, "myserver.mycompany.com", "/some-uri")
.as(BodyCodec.jsonObject(User::new))
.send(ar -> {
if (ar.succeeded()) {
HttpResponse<JsonObject> response = ar.result();
JsonObject body = response.body();
System.out.println("Received response with status code" + response.statusCode() + " with body " + body);
} else {
System.out.println("Something went wrong " + ar.cause().getMessage());
}
});-
Currently, the event-bus service proxies are required to use the data object type for transferring custom types
-
Extend the notion of Data Objects to map any possible type to JSON #vertx-codegen/235
It is sometimes necessary for third-party libraries to follow the flow of an asynchronous program. Traditionally such libraries rely on thread local storage to achieve it. Libraries falling in this category are most notably:
-
distributed tracing integration
-
thread local storage
Vert.x shall provide support for tracing of its asynchronous flows to enable these use cases.
See this RFC for the details.
Revisit clustering to address some limitations.
The goals for this effort are as follows:
-
enable smart routing of messages
-
clearly separate concerns (delivery, routing, storage) to get a moderate level of complexity
-
avoid code duplication across clustering SPI implementations
-
lower the bar for clustering SPI implementation
-
cohesive configuration
Provide an alternative cluster manager implementation as a client of a separate data grid:
-
JGroups for discovery/membership
-
Infinispan client for data storage
This should improve startup time (no rebalancing) and memory footprint (no data stored on the node) by a great margin.
-
NPM first
-
Modules hosted on npm instead of maven central
-
TypeScript definition files bundled (hinting + intellisense)
-
Just Works(™) with modern IDEs
-
Benefits
-
Normal workflow for JS developers
-
Less maintenance (just 1 maven artifact)
Todo: determine where it should live.
OSGi is quite difficult to maintain and it is preferable to not continue supporting it in v4.
The package io.vertx.ext.web.templ is split between vertx-web and every engine implementation.
-
In 3.6 each engine is deprecated and the interface is copied to its own package.
-
in 4.0 the deprecated interface is removed
Sub-routers can be fixed using the same API. To achieve this the path evaluation is split into several steps
e.g for /a/b/c/d
-
partial evaluation at the parent
/a/b/* -
the child continues the evaluation
/c/*
Goals: simplify the integration of gRPC in Vert.x, we don’t want to use the same version of Netty than grpc-netty uses.
Actions: - Drop custom reactive-grpc compiler - Use shaded grpc-netty version
In Vert.x 3.x, the Groovy generation has become more lightweight based on extension methods. Therefore Vert.x for Groovy currently uses Vert.x APIs directly. In Vert.x 4 we remove any code generation in favour of using instead Groovy operators to achieve the same
def server = vertx.createHttpServer(["port":80])
server = vertx.createhttpServer(["port":80] data HttpServerOptions)
def json = ["port":80] as JsonObjectList of project dropped after 3.x
-
vertx-rx-js: replaced by ES4X
-
vertx-rx-groovy: no value
-
vertx-mysql-postgres-client: replace SQL client
-
vertx-jca: no value
-
vertx-embedded-mongo-db: provides a way to start / stop mongo embedded as a vertx service, it is not really needed and worth to support
-
vertx-client-services: in practice client services (Mongo, Consul and Mail) are not much used and instead people use clients
-
vertx-lang-ceylon: no value
-
vertx-amqp-bridge: replaced by AMQP client
-
vertx-camel-bridge (TBD)
-
vertx-maven-service-factory (TBD)
-
vertx-service-factory (TBD)
-
vertx-http-service-factory (TBD)
A new module in the vertx-infinispan project that provides a lightweight / simple client for Infinispan based on the HotRod Java client
-
Polyglot client (including RxJava)
-
Manages the HotRod thread / Vert.x context switch
-
Compatibility with SharedData API
-
Client listeners
-
Continuous queries
The new client API, which will be much closer to the original golang interface provided by Hashicorp. The current API will be marked as deprecated and deleted in the future.
The Web Authentication API is an extension of the Credential Management API that enables strong authentication with public key cryptography, enabling passwordless authentication and/or secure second-factor authentication without SMS texts.
Tokens with algorithms PS256, PS384, PS512 are supported. Caveat, it requires JDK >= 11 as the required crypto support at the JDK level is only available on the last LTS release. If other crypto providers are installed (e.g.: BouncyCastle, then it should be possible to use it on older JDKs).
Introduction of a new Promise API that is intends to replace parts of the current Future API.
API that was using Future as a completable object (executeBlocking method, BridgeEvent, Verticle async start/stop) has been updated to use Promise instead.
This is a change for the preparation of Vert.x 4.
Deprecate EventBus#send(…, Handler<AsyncResult<T>>) for EventBus#request(…, Handler<AsyncResult<T>>)
Launcher allows setting the priority of commands and respects an optional Default-Verticle-Factory MANIFEST.MF entry which allows polyglot projects to use naked verticle names (without extension or prefix).
An AMQP client that replaces the 3.x AMQP bridge
-
Allow configuring AMQP links options without diving too much in the protocol
-
Can be used in non pure-Vert.x application
When Vert.x is clustered, AsyncMap, Lock and Counter are always distributed.
Sometimes you just need a local AsyncMap, Lock or Counter and you don’t want to pay the price (latency) of clustering.
The idiomatic way to send records is to use a send method. Currently, the producer uses the write method inherited from WriteStream. A simple new send method that delegates to write will be added and the documentation will use it instead of write.
The current admin client uses the Scala based admin client, there is a new admin client written in Java. We aim to make deprecated the Scala version and use the Java version instead of using the asynchronous version. For the initial version, the same features should be supported, other features can be added later or contributed easily.
As of 3.6, Cassandra clients can be shared or non shared.
Before querying, the user must invoke connect.
There is no method for the user to close a client, it can only be disconnected.
This lifecycle design is not aligned with the rest of Vert.x stack and does not fit well the typical Vert.x application model (with different verticles, possibly multiple instances).
Most Vert.x data clients work as follows:
-
client connects automatically on first request
-
client disconnects automatically when calling
close(immediately if non shared or later if other shared clients are still running) -
closemethod is idempotent (user may invoke it any time in verticle code and yet undeploying the verticle later will not eagerly disconnect another shared client still running)
Provide a vertxy version of the Datastax driver mapping manager (row/object mapper).
Based on the graphql-java library, a GraphQL handler for:
-
GET and POST requests
-
request batching (POST-only)
-
websocket transport (compatible with apollo-link-ws)
The 3.x client provides a type-API modeled after Redis commands, this makes a strong coupling between the client API and the Redis version.
An untyped version of the client will provide a more generic framework for interacting with Redis and the client version will be independent of the Redis server version.
Redis redis = Redis.create(vertx);
redis.open(SocketAddress.inetSocketAddress(6379, "localhost"), open -> {
if (open.succeeded()) {
redis.send("set", Args.args().add("key").add("value"), ar -> {
...
});
}
});The untyped API will also provide better Buffer support to minimize conversions.
The API in Vert.x v3 for transferring stream with back-pressure is the pump API. This API has several limitations (it does not handle stream termination or error, it requires extra bookkeeping when piping to an asynchronous stream) and remains low level.
See this RFC for the details.