prolic on v1.10.3
prolic on master
update changelog (compare)
prolic on master
fix restarting projection durin… respect lock in memory resetting projection and 12 more (compare)
I know the code generated is on our git, but it still breaks established workflows. any plans to bring the board as a self-hosted / run version?
And yes, we also offer self-hosted options. But they are more expensive.
ideally as something I can define as a dependency on the project and start like "any other code generator" (just with a graphical UI instead of CLI).. running locally also would be preferred from a security & confidentiality perspective
@fritz-gerneth That exists! Cody is open source and can be installed via composer. The free version of prooph board is hosted on github and requires no login at all! Everything that you do there happens only on your local machine within your browser. You can import/export boards etc. But without the SaaS version you cannot collaborate with your teammates (yet). We're working on making that possible in the free version as well. That should become available at some point in this quarter, but will have limitations. We still want to earn some money with the SaaS version :D
The free client is available here: https://free.prooph-board.com
@fritz-gerneth if you really want to try Cody, let me where you need support. A good starting point is the tutorial:
It covers the absolute basics. @sandrokeil could support you in exploring the "Open Code Modeling" stuff and we could open source the Event Engine implementation shown in the video if that is of interest as well. But this is highly opinionated :D
just released: https://github.com/prooph/event-store/releases/tag/v7.7.0
special thanks for @gquemener and also thank you @netiul for reminding me to take care of this.
spread the word!
Good afternoon @prolic @codeliner
We are currently use the prooph framework for our loyalty engine. In short we have a setup that on each transaction that is created, an x amount of events are created on the player aggregate
The problem is that before we start acting on the player aggregate, we first load the player aggregate (snapshots taken) and then append 1 or more events on it depending on the life-cycle of the loyalty engine campaign. We do have snapshots in place so its not as if we are loading the full history of the player. But still the query generated by the framework to load from snapshot (AggregateRepository -> loadFromSnapshotStore) is quite CPU heavy on the RW db, compared to other queries
In the past we did POC moving to the
AggregateStreamStrategy but as written in the documentation, we did struggle alot to have our projections as real time as possible. we would have 1000s of tables if we do one table per player.
So we are looking for options to perform better when loading the aggregate from a snapshot.
DBAs suggested to use partitioning of the main player aggregate table but not sure if prooph itself has that option. Otherwise if DBA create partitioned tables (prob one a day), then we need prooph framework to load the aggregate with these partitioned table.
Another idea that we had was to keep a parallel event store (inMemory) with the state of the players in the last 5mins. meaning that the player is kept in memory for around 5mins or even less.. that would drastically reduce the load on the db.
any other options/thoughts?
On a side note we are using
7.5.6 and we currently experience around 1.8million to 2million transactions at any given day. for each transaction we load the player aggregate (for the player related to that transaction) and append further events to the player aggregate