Announcing Zeebe Node Client 0.23

by Josh Wulf on May 23 2020 in ReleasesJavaScript.

The 0.23.2 version of the Zeebe Node Client is out and available via NPM.

There was a critical build error in 0.23.0 and 0.23.1. Special thanks to @myfjdthink for reporting it, and @lwille for the Pull Request that fixed it.

The complete Change Log is at the end of this post, with the full list of known issues (for the first time in a release - there is one), breaking changes, new features, and fixes.

In this post, we’ll also feature a few of the major changes in this release in detail.

Feature: Zeebe Node is now pure JavaScript

This release is a major refactor, replacing the previous underlying gRPC implementation (based on the C client) with a pure JS implementation of gRPC.

This means that the build chain for projects is simplified. Previously, you needed to rebuild your Node.js Zeebe projects for the target Operating System. This meant that a developer could not npm install on a Mac or Windows workstation and simply mount the development directory in a Linux docker container.

Now, with the pure JS client, the same npm install works across operating systems.

As well, prior to the 0.23.0 release, Docker files required either a multi-step build or a Docker container with the build chain in it, and Electron projects required the use of electron-rebuild.

So build complexity, build times, and eventual project size have all been reduced.

Representatively: the overhead of a Zeebe Node project has been reduced from 50MB to 27MB.

Known Issue: Connection Error debouncing

The pure JS gRPC client has some different behavioural characteristics to the C client, and this results in the first Known Issue in a zeebe-node release.

Because the channel behaviour differs, the internal error and retry handling has been modified. The unit tests all pass, so as far as we can tell the behaviour is the same - with one exception that we know about: the onConnectionError handler is not correctly debounced in this release. This means that for a single error event, your error handler or connectionError event listener may be invoked multiple times - so if you are using this feature, you need to make sure it is the lack of debouncing does not impact your application. This will be addressed in a future release.

There may be other behavioural characteristics that are not covered in the unit and integration tests, so if you discover something, please open a GitHub issue, and we’ll take a look at it.

Fix: Transparent Reconnection after K8s pod reschedule

As part of the work implementing the pure JS version, we created a test using a custom version of testcontainers-node to test the behaviour of the Node client when a broker is stopped, then restarted - simulating a Kubernetes pod reschedule.

Prior to 0.23.0, a broker restart required a restart of any connected workers, as the gRPC channel would fail to reconnect. With the 0.23.0 release, the client now transparently reconnects. Users of Camunda Cloud (which offers a hosted Zeebe service), where pods are periodically rescheduled, will be happy about this.

Again, if you encounter issues with this resiliency, please open a GitHub issue.

Feature: Developer-friendly logging

Prior to 0.23.0, the Zeebe Node client used a structured JSON log output by default. This is useful if you are sending your docker logs to Logstash or a similar log collector, but is not very friendly for development on a workstation.

In the 0.23.0 release, the default logger has been changed to a simple text logger that provides a more human-friendly output.

You can turn on JSON structured logging via an environment variable for production systems.

Feature: Batch Worker

Version 0.23.0 introduces a new worker type - the ZBBatchWorker. This worker allows you to batch jobs in the worker, then process them all at once when a predefined capacity or timeout is reached.

The ZBBatchWorker batches jobs before calling the job handler. Its fundamental differences from the ZBWorker are:

You can use the batch worker if you have tasks that benefit from processing together, but are not related in the BPMN model.

An example would be a high volume of jobs that require calls to an external system, where you have to pay per call to that system. In that case, you may want to batch up jobs, make one call to the external system, then update all the jobs and send them on their way.

Version 0.23.0 Changelog

Known Issues

Things that don’t work or don’t work as expected, and which will be addressed in a future release

Breaking Changes

Changes in APIs or behaviour that may affect existing applications that use zeebe-node.

New Features

New shiny stuff.