Eclipse Vert.x 4 beta 3 released!

We are ex­tremely pleased to an­nounce the third 4.0 beta re­lease of Eclipse Vert.x.

Vert.x 4 is the evo­lu­tion of the Vert.x 3.x se­ries that will bring key fea­tures to Vert.x.

HTTP client request creation

Until Beta3, HTTP client has cre­ated lazy HTTP re­quests, since then cre­at­ing a re­quest has be­come an asyn­chro­nous op­er­a­tion guar­an­tee­ing that a slot for per­form­ing the re­quest is granted:

// Created a request
HttpClientRequest request = client.get("/some-uri");

// Connect to the server or reuse a connection from the pool and then try to send the request
request.end();

// Since Beta3
client.get("/some-uri", ar -> {
  // The client connected to the server or reused a connection from the pool
  if (ar.succeeded()) {
    HttpClientRequest request = ar.result();

    // Send the request
    request.end();
  }
});

An­other (hid­den) mo­ti­va­tion to switch to this model is avoid­ing data races when the HTTP client is used out­side the event-​loop using fu­tures.

Pre­vi­ously, you could write code like:

Future<HttpClientResponse> get = client.get("some-uri");

// Assuming we have a client that returns a future response
// assuging this is *not* on the event-loop
Future<Buffer> fut = get.send().compose(response -> {

  // Response events might have happen already
  return response.body();
});

Now, you can write in­stead:

Future<Buffer> fut = client.get("some-uri").compose(request -> {
  request.send().compose(response -> response.body())
});

HttpServerResponse send method

In the pre­vi­ous beta, HTTP client re­quest got a new sim­pli­fied send method to send a body or a stream. We did the same for the HTTP server re­sponse API:

server.requestHandler(req -> {
  req.pause();
  getSomeStream().onSuccess(stream -> {
    req.response().send(stream);
  });
});

HTTP tunnel improvements

Cre­at­ing an HTTP tun­nel has now be­come more nat­ural:

client.request(HttpMethod.CONNECT, "some-uri")
  .onSuccess(request -> {

    // Connect to the server
    request.connect(ar -> {
      if (ar.succeeded()) {
        HttpClientResponse response = ar.result();

        if (response.statusCode() != 200) {
          // Connect failed for some reason
        } else {
          // Tunnel created, raw buffers are transmitted on the wire
          NetSocket socket = response.netSocket();
        }
      }
    });
});

The new connect method tells the client that when a 201 re­sponse is re­ceived from the server then the con­nec­tion should be switched to not in­ter­pret HTTP data any­more.

On the server, the API has be­come asyn­chro­nous and re­named to toNetSocket():

server.requestHandler(request -> {
  if (request.method() == HttpMethod.CONNECT) {
    // Will send an HTTP 201 status code and switch the connection to use raw buffers
    request.toNetSocket(ar -> {
      if (ar.succeeded()) {
        NetSocket socket = ar.result();
      }
    });
  }
});

WebSocket upgrade improvements

The server Web­Socket man­ual up­grade op­er­a­tion has also be­come asyn­chro­nous and re­named to toWebSocket()

server.requestHandler(request -> {
  if (request.method() == HttpMethod.GET && "Upgrade".equals(request.getHeader("connection"))) {
    // Will do the WebSocket handshake
    request.toWebSocket(ar -> {
      if (ar.succeeded()) {
        ServerWebSocket socket = ar.result();
      }
    });
  }
});

Row to JSON conversion

SQL client can now eas­ily trans­form a Row into a JSON ob­ject, this can be con­vie­nient for ap­pli­ca­tions di­rectly trans­fer­ring JSON re­sults to the client:

client
  .preparedQuery("SELECT * FROM USERS WHERE ID=$1")
  .execute(Tuple.of(id))
  .onSuccess(row -> {
    if (row.size() == 1) {
      JsonObject json = row.iterator().next().toJson();
    }
  });

OAuth2/OIDC PKCE

OAuth2Handler can now han­dle PKCE, which means an­other layer of se­cu­rity to your ap­pli­ca­tion.

Redis RESP3

The redis client can now speak RESP3 with redis servers. This means it can han­dle all the new types and APIs avail­able on redis from all ver­sions (RESP2, redis < 6) and (RESP3, redis >= 6).

Finally

This is the Beta3 re­lase of Vert.x 4, you can of course ex­pect an­other beta as we get feed­back from the com­mu­nity and fix is­sues that we failed to catch be­fore.

You can also read the mile­stone an­nounces to know more about the over­ral changes:

The dep­re­ca­tions and break­ing changes can be found on the wiki.

For this re­lease, there are no Docker im­ages.

The re­lease ar­ti­facts have been de­ployed to Maven Cen­tral and you can get the dis­tri­b­u­tion on Maven Cen­tral.

You can boot­strap a Vert.x 4.0.0.Beta3 project using https://start.vertx.io.

The doc­u­men­ta­tion has been de­ployed on this pre­view web-​site https://vertx-​web-site.github.io/docs/

That’s it! Happy cod­ing and see you soon on our user or dev chan­nels.

Next post

JWT Authorization for Vert.x with Keycloak

In this blog post, you'll learn about JWT foundations, protect routes with JWT Authorization, JWT encoded tokens, and RBAC with Keycloak

Read more
Previous post

Eclipse Vert.x 3.9.3 released!

Eclipse Vert.x version 3.9.3 has just been released. It fixes quite a few bugs that have been reported by the community.

Read more
Related posts

Things to keep in mind concerning CSRF attacks

Eclipse Vert.x like most frameworks provides an anti-CSRF defense. However, no framework can prevent all attack vectors that exist in the web. Therefore, developers need to be aware of some dangers and common attack vectors concerning CSRF defenses.

Read more

Real-time bidding with Websockets and Vert.x

The expectations of users for interactivity with web applications have changed over the past few years. Users during bidding in auction no longer want to press the refresh button.

Read more

Some Rest with Vert.x

This post is part of the Introduction to Vert.x series. Let’s go a bit further this time and develop a CRUD-ish application

Read more