Skip to content

Vert.x Roadmap

Thomas Segismont edited this page Mar 19, 2019 · 17 revisions

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

  • 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

CompletionStage support (4.0)

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 RFC for the details.

JSON improvements 4.0

Jackson

  • 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

Proposal
  • Encapsulate Jackson so the API is not exposed publicly

  • Need a replacement for TypeReference

  • Make data-binding optional to avoid CVEs

  • Define SPI for POJO mapping ?

  • Handle data object out of the box?

  • Extra jar for data-binding?

Client JSON mapping

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());
    }
  });
Performance improvements

Drop unnecessary rewrapping of map/list/byte[]/date on put/add that can consume resource when used on the hot path

JSON codec

  • 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

Tracing (4.0)

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

  • MDC logging

Vert.x shall provide support for tracing of its asynchronous flows to enable these use cases.

See this RFC for the details.

Clustering (4.0)

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

Infinispan cluster manager improvements (4)

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.

AMQP Client (4.0)

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

Kafka Client

Producer (4.0)

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.

ES4X (4.0)

  • 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 (4.0)

OSGi is quite difficult to maintain and it is preferable to not continue supporting it in v4.

Vert.x Web

Split package resolution (4.0)

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

Redis backed session (4)

Port old yoke Redis store as a quick win.

Router performance improvement (4)

todo

Sub router improvements (4)

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/*

Handler merge (4.0)

Some handlers are fine-grained and are anyway always used together

  • Session + UserSession

  • OAuth2/OIDC + JWT

gRPC (4.0)

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

Groovy

Code generation pruning

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 JsonObject

Groovy verticle class pruning

In Vert.x 3.x, the GroovyVerticle class for base verticles has been deprecated in favour of io.vertx.core.AbstractVerticle. GroovyVerticle is removed in 4.0.

Removals (4.0)

List of project dropped after 3.x

  • vertx-rx-js

  • vertx-rx-groovy

  • vertx-mysql-postgres-client

  • vertx-jca

  • 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

  • vertx-amqp-bridge

  • vertx-camel-bridge (TBD)

  • vertx-maven-service-factory (TBD)

  • vertx-service-factory (TBD)

  • vertx-http-service-factory (TBD)

Infinispan Client (4)

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

Consul Client

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.

Vert.x 3.7

Core

  • deprecate EventBus#send(…​, Handler<AsyncResult<T>>) for EventBus#request(…​, Handler<AsyncResult<T>>)

Local version of shared data structures

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.

MQTT

MQTT over WebSocket community contribution for the server, try to get a client version as well.

Kafka Client

Admin client

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.

Cassandra Client

Redesign client lifecyle

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)

  • close method 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)

Mapping manager

Provide a vertxy version of the Datastax driver mapping manager (row/object mapper).

Collector API

Provide a method on ResultSet which allows to consume with a Java collector (cf. the Reactive Pg driver).

Vert.x Web

GraphQL support

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)

Detyped Redis client

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.

Stream pipe API

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.

Clone this wiki locally
You can’t perform that action at this time.