Eventide v2 Roadmap

The v2 generation of Eventide is on the horizon. Here are the notable changes coming:

  • Direct support for pub/sub in the message store database
  • Test fixtures
  • New version of Test Bench
  • Component info dump at start up
  • Trace ID in message metadata

Realistically, we’re aiming for a release somewhere between the beginning of November and the end of December.

Direct Support for Pub/Sub in the Message Store Database

Changes to the message store database will cause incompatibility with previous versions of the message store client. It’s a breaking change. It will also require momentary downtime to update the database.

There will be no changes to the messages table schema itself, so the usual issues with schema changes to existing tables do not apply.

There will be a new index on the messages table to optimize queries based on the value of the message metadata’s correlation stream. Depending on the volume of the message store, the database operator might want to defer this part of the update, which is perfectly fine.

The two Postgres functions that read messages from the message store will be replaced. This is a straight replacement of the functions that will occur virtually instantaneously.

A database upgrade script will ship with the update.

The changes to the database move pub/sub based on correlation stream name into the database itself, where presently that code resides in the client implementation. With these changes, the message store database will support the most common messaging patterns out of the box and requires no particular client library implementation to support pub/sub between services. This is a welcome feature for those users who are coding against the message store in a languages other than Ruby.

GitHub issue: https://github.com/eventide-project/message-store-postgres-database/issues/5

Test Fixtures for handlers, writers, projections, and data structures

A handful of libraries in the Eventide toolkit will ship with built-in test fixtures, reducing the amount of code required for writing the most common types of tests. Fixtures will largely also establish standards for the implementation of common test patterns.

Fixtures will be provided for handlers, writers, projections, and data structures, and will provide test abstraction and automation for common assertions made for those elements.

The fixtures are built specifically for Test Bench, and require a new version of Test Bench which provides first class support for fixtures.

GitHub issue: https://github.com/eventide-project/eventide/issues/38

New Version of Test Bench

The Test Bench (https://github.com/ntl/test-bench) testing framework, while not definitively part of Eventide, is nonetheless a critical part of the Eventide family, and the only test framework used in the development of the Eventide toolkit and all of its constituent libraries.

The fixtures that will ship with v2 of Eventide are based on Test Bench. Significant changes to Test Bench have to be made to extricate the assertions and output machinery from Test Bench itself, and house them in a separate library.

These changes inevitably drive the need for a new major version of Test Bench. These changes are already well under way and will be released within the next couple of weeks independently of any Eventide v2 releases.

See the Test Bench project: https://github.com/ntl/test-bench

Component Info Dump at Start Up

Presently, when components are started, a minimum of information about the component is output to the log. While this info is helpful and useful it’s not quite complete, and isn’t really appropriate to the structured formatting that the logger uses.

The component and consumer libraries will be changed so that more useful and readable information will be dumped to the same I/O device that the log is printing to.

Here is an example of the output:

Starting Component: TaxonomyDataComponent::Start (lib/taxonomy_data_component/start.rb)
Name: (none)

  Starting consumer: TaxonomyDataComponent::Consumers::Taxonomy::Events
  Stream: taxonomy
  Identifier: (none)
  Starting Position: 0

    Handler: TaxonomyDataComponent::Handlers::Taxonomy::Events
    Stream Name: taxonomy
    Messages: Taxonomize, DataGenerated, Taxonomized

Started Component: TaxonomyDataComponent::Start
ProcessID: 65674

GitHub issue: https://github.com/eventide-project/eventide/issues/46

Trace ID Attribute in Message Metadata

This is a rather small change, resulting only in the addition of an attribute to the message metadata.

The addition of a trace_id attribute provides a standard means for supporting distributed tracing and APM tools. The support and integration of these tools themselves will not be part of the 2.0 release of Eventide, but is intended to come in later releases and as part of contributions from the Eventide community.

GitHub issue: https://github.com/eventide-project/messaging/issues/5

Additional Changes

In addition to these changes, a number of smaller improvements are slated for the v2 timeline. These changes are too insignificant to mention here, but will be documented with the v2 release.


On Deck in the v2 Product Generation

Post v2.0, there are a number of planned, follow-up features that will come in subsequent releases in the v2 generation.

Share Connection Between ActiveRecord and Eventide Session

This feature has been a repeated request from users and prospective users who have been asking for a way to write messages atomically in the same database transaction as the one being used in a Rails app.

It requires a significant re-thinking of the design of Eventide’s session in order to both provide this capability and not incur complexity penalties. Access to Rails’ raw Postgres connection will require connection access to be pluggable, which is not something that is ever needed when building autonomous services and is only necessary when integrating Eventide and Rails.

And while using Eventide within Rails isn’t an intended use case (or a recommended architecture), it is useful for applications that can’t quite make the architectural transition to evented and autonomous services.

GitHub issue: https://github.com/eventide-project/message-store-postgres/issues/12

Entity Query

The EntityQuery library is a composite of a reader and a projection.

It allows for the retrieval (ie: projection) of an entity from a stream. It respects the reader’s interface, allowing for the specification of the starting position, batch size, session, etc.

Additionally, a block can be optionally specified that controls when the reader will terminate. The conditions for termination are evaluated against the current message data being read.

GitHub issue: https://github.com/eventide-project/eventide/issues/39

Stream Scan Library

The EntityScan library is used to retrieve a single message data from a stream.

It scans sequentially for message data that meets a specified condition. If the condition matches the message data, the message data is returned.

The stream scan’s interface respects the reader’s interface, allowing for the specification of the starting position, batch size, session, etc.

GitHub issue: https://github.com/eventide-project/eventide/issues/44

ReserveID Library

Generalization of the reservation part of the reservation pattern. It operates like a find_or_create for some ID.

If the reservation is successful, the reservation message is written, and true is returned. If it can’t, the message is not written, and false is returned.

GitHub issue: https://github.com/eventide-project/eventide/issues/19