Status

[Ri1a]

We’re not offering hard release date estimates yet, after all, it’s an open source project executed by volunteers in available time. That said, our optimistic estimate is for a v1 release in 3 months. The pessimistic estimate is 6 months. We hope to have an operational pre-release within 1 to 2 months.

Are there any status updates for this project?

[sbellware]

Hi @Ri1a. It's very much a casual project at this point. We're doing projects with Eventide and Rails right now, and testing ideas of what the integration will look like. But no firm updates on scope and timing yet.

Are there capabilities in particular that you're interested in?

[Ri1a]

We're starting a new rails project and I think there will likely be a lot of questions to answer. Maybe we can answer some questions in this project here!

[weh]

How is https://github.com/hubbado/eventide-rails related to this repository?

I wanted to use the hubbado/eventide-rails as starting point, and ran into a renamed function (https://github.com/message-db/message-db/commit/914842648db180b81bc2cf759faf2c911014362b)

Is there some (work in progress) code that you are using in your projects and willing to publish? I am currently not sure, if we should use the plain Ruby examples, and use message-db directly (mdb-create-db,..) or use hubbado/eventide-rails as base.

We will use the Rails Part only for API (controllers) and Models as Read-Only Aggregates.

[sbellware]

@Ri1a @weh Sorry for the late reply. It's a busy time right now, and we're backed up on communications.

The best place to get questions answered is in the Eventide Project's Slack: https://eventide-project-slack.herokuapp.com/

There is no in-progress code for Rails integration available right now. Everything that exists at the moment is entirely proprietary and not general-purpose.

The most common Rails/Eventide integration need is the writing an event in conjunction with doing an ActiveRecord update. A reasonable workaround is to directly call the Message DB write_message Postgres server function, and to have that call and the ActiveRecord updates occurring in the same database transaction.

It requires installing the Message DB database into the same database where you're Rails model lives. You'd need to be comfortable with Postgres basics to do this, but other Eventide users have done it quite easily - again, given comfort with Postgres.

Here's a writeup on using the Message DB server functions: https://blog.eventide-project.org/articles/build-your-own-message-db-client.

We'll have more updates over the coming months about Rails integration, but again, it's still a project that's very early in its conception - despite having a clear path forward.

I hope this helps.

[cavi21]

Hi there! wondering if there is any update on the status of this project, but also if anyone have a recommendation on the best strategy to gradually start using Eventide on a working Rails project. If that's something that make sense in your opinion? and what should be the reasonable next steps for that.

Also @weh how do you proceed with your idea of using Rails for the API part only? do you have any idea or suggestion?

Thanks!

[weh]

@cavi21 that is a longer story but at some point we decided to not use the Eventide Framework anymore and continued with a Rails app and ActiveJob for the asynchronous backend jobs.

There are many reasons for this decision. Some can be found in architecture decisions, and a data model that IMHO did not fit well in our Services that we wanted to build. Also the fact that we used Events for every part of the Application. We sure had some lessons learned here.

The Idea to use Rails for the API and (any Event driven Framework like) Eventide adds the need to introduce some kind of Polling. Think of having to bridge between the synchronous API calls and the asynchronous Event world, where you can not make assumptions on when the Command will be finished. So you can not hide the asynchronous nature of your services for your API users. They may need to e.g. "get a ticket" and poll until the work is done. At least if you do not only have some "fire and forget" Tasks. Again, maybe our Case did not fit in this kind of Architecture very well.

Another Point that may be more related to Eventide was our impression that we need to write (copy/paste) a lot of Boilerplate Code to get the simplest things done. I am not sure if this general the case in this Event driven World or just with this Framework, but there are surely some very opinionated parts in this Project.

So my advice is to really think if you really need to put yourself in this Event Driven world. I still think that it may fit very well for some cases. Just make sure you really need it, and don't just do it because you want to try some of this cool Buzzword stuff.

[sbellware]

@cavi21 Sorry for the late reply. Still extremely busy.

The status remains the same. It's really not a project that moved forward because there is very little tangible reason to have Eventide integrated with Rails. Integration only serves a small number of use cases that are quite rare in practice (ie: saving messages and saving ActiveRecord model data in the same transaction.

In the end, Eventide isn't a front-end technology. We use it in Rails all the time, but the point is to write a message and exit. Everything from there is a back end concern. We of course have some forms-over-data features of the apps we build, but there's no intersection between forms-over-data and events. They're entirely different architectures made for entirely separate (and separated) concerns.

[sbellware]

@weh Indeed, Eventide doesn't seek to eliminate boilerplate. Boilerplate just isn't where the cost of creating or maintaining software is generated. So, we don't do anything to optimize for it. In practice - when you've developed, operationalized, enhanced, and supported a significant number of components - the boilerplate is a net gain. It's critical component of usability for the consumer and reader of the code. It's a simplification and a human/cognitive optimization that we make with full awareness and purpose.

This kind of work is difficult enough as it is without having to mentally reverse-engineer opaque abstractions while also trying to understand complex message flows.

That said, it's a "toolkit", not a "framework". It's got all the things any developer can use to build any number of abstractions to reduce the amount of code written.

But as Kevlin Henney once said, typing isn't the problem. Meaning that getting code into an editor is not the costly activity. We optimize for the literacy of these implementations, and shy away from abstractions that impact a developer's ability to understand what's happening.

Again, from an in-practice perspective, explicitly leveraging boilerplate has continued to be a net gain. It takes a lot more effort to read and understand code than it does to create it. We leave what needs to be understood in the editor under the developer's eyes.

I can say with 100% certainty that every customer that we've had that wen't the route of using abstractions to try to further remove the boilerplate ended up ultimately removing the abstractions and restoring the boilerplate.

And ultimately, the purpose of abstraction in design is absolutely not to eliminate code. The purpose of abstraction is something much more subtle, and we're only willing to leverage generalization up to the point where going further invites the wrong kinds of design qualities into the toolkit, and while leaving some room for users to explore on their own.