The release of Eventide v2 was a hurdle of breaking changes to the message store and its supporting libraries, and the extraction of Message DB. Now that we’re past the v2 hurdle, look out for exciting new features coming to the Eventide stack.

Significant features in the v2+ timeline focus on testing and on Rails integration. A number of minor improvements and new libraries are planned, as well.

Rails Integration

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.

A new Session will be implemented that will use ActiveRecord’s database connection, and thus share ActiveRecord’s transaction. Additionally, the location of the message store connection settings file will default to Rails’ default configuration file location.

A new library will be released with the Rails integration support for use in Rails apps.

The Rails integration will be a useful affordance for applications that can’t quite make the architectural transition to evented and autonomous services, but that can still benefit from evented approaches.

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 v2 which provides first class support for fixtures.

Entity Query

A common pattern implemented by Eventide users that will become an Eventide feature with the benefit of being maintained by the Eventide Project team.

EntityQuery 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.

ReserveID Library

Generalization of the reservation part of the reservation pattern. It operates like a find_or_create operation 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.

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
  Category: taxonomy
  Identifier: (none)
  Starting Position: 0

    Handler: TaxonomyDataComponent::Handlers::Taxonomy::Events
    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

Looking Ahead to v3 Horizon

The Eventide v3 product generation is too far off the planning horizon for the moment to commit to specific features, but here are a couple of endeavors that are likely candidates:

Drop Support for the Event Store Database

Even though the [Event Store database] figures prominently in Eventide’s history, it hasn’t been of much interest to users since the release of Eventide’s Postgres implementation.

As of this date, there are no longer any active customer deployments of Eventide’s Event Store implementation. Everyone using Eventide heads straight for the Postgres implementation for it’s ease of developer experience and the breadth of its support by cloud providers like AWS, Google, and Heroku.

And, if we’re going to be completely honest about it, we don’t even maintain the Event Store implementation any more. If anybody wanted to use it, we could bring it back up-to-date quite quickly, but there simply hasn’t been any demand to do so.

We’ve heard that the Event Store team might be working on something new, and we look forward to seeing them make progress on a new product. Their work has been instrumental in our understanding, and anything new that comes out of the Event Store shop deserves serious consideration.

Removal of Storage Backend-Specific Namespaces

This one goes hand-in-hand with the removal of support for the Event Store database. When that happens, the existence of the Postgres namespace (ie: MessageStore::Postgres, Consumer::Postgres, etc) will be largely superfluous and nonsensical.

The namespaces and libraries will be consolidated into the root namespaces (eg: MessageStore). The legacy database platform-specific namespaces will be supported for backward compatibility purposes only.

Replace the Actor Implementation with Native Ruby Concurrency

By the time Eventide v3 ships, it’s quite possible that the Ruby team will have finalized Ruby’s next generation concurrency primitives, and their intended approach for using fibers and guilds will have been solidified.

If the stars align, we might see a replacement of Eventide’s actor library, ntl-actor, by Nathan Ladd, with Ruby’s own concurrency tools.