Support chat for http://getprooph.org/ - official announcement: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html
I guess that would work.
You could also directly communicate with your event store (which is what the projection manager is most-likely doing) and remove some extra layers : https://github.com/gquemener/repositoring/blob/main/src/Infrastructure/Repository/Prooph/ProophEventStoreTodoRepository.php#L76-L101.
The idea being that in-memory synchronous implementation is enough until you encounter performance issue (I would advise to setup mecanisms to track this issue, if not already done).
You could also directly communicate with your event store
This is an older version of prooph where the query comes from the projection manager.
Here is an example of a newer version:
$eventStore
->createQuery()
->fromAll()http://docs.getprooph.org/event-store/standard_projections/overview.html
Is that what you suggested?
I'm suggesting to inject your Prooph\EventStore\EventStore service into your finder and use EventStore::load directly (check the link I shared for an example), instead of using the projection manager that is aimed to track the status of your projectors.
The reason being that your projector does not need to be tracked, because it reads all the relevant events from the start, every time.
That being said, what you did is probably working fine (however you're adding an unecessary overhead by querying the "projections" table, aren't you?).
🎉 The new #proophboard wiki is online 🎉
👉 https://wiki.prooph-board.com
𝗖𝗵𝗮𝗻𝗴𝗲𝗹𝗼𝗴
💄New layout supporting light and dark mode as well as different font sizes
🧭️ New sidebar with better structure and much easier navigation
💡More content incl. #eventstorming basics + guideline
🙏 Please have a look and tell me what you think. Feedback is very much appreciated.
2 replies
Good afternoon, our application is currently implemented using the PostgresSingleStreamStrategy.
So far we have around 15k players and in the Player stream we have around 8 million events (related to the 15k players)
When we have a huge amount of events at the same time (sometimes because of huge backlog), we find that the query that loads the actual player aggregate is taking much more time (around 1/2 second) that in normal scenarios.
SELECT * FROM "_889c6853a117aca83ef9d6523335dc065213ae86" WHERE metadata->>? = $1 AND metadata->>? = $2 AND CAST(metadata->>? AS INT) > $3 AND no >= $4 ORDER BY no ASC LIMIT $5Technically its not an issue per-se for our product as its still fast, but we were wondering if moving to a different strategy might actually solve it and make it more future proof
So we opted to see how it would behave by moving to AggregateStreamStrategy by changing the oneStreamPerAggregate to true in the player AggregateRepository. We also did a projection to migrate the events on the into the different streams (tables) therefore ended up with 15k tables and in itself it helps now with querying the aggregate repository because each stream is much smaller since its per player
Having said that projections deteriorate drastically since they have to consume over 15k tables to be updated. We know that this could be possible as it is stated in the documentation of the AggregateStreamStrategy (http://docs.getprooph.org/event-store/implementations/pdo_event_store/variants.html#3-2-1-2-5-1)
PS we did update the projections to use fromCategory instead of fromStream
anyone has managed to overcome such scenario
@andrew.magri_gitlab Did you consider using snapshots to speed up aggregate loading?
8 million events in a single stream shouldn't be a problem.
Regarding AggregateStreamStrategy:
The idea would be to write an event store plugin that hooks into the transaction to write events (or references) also into a category stream and let projections only subscribe to the category and not the aggregate streams.
Another option is to switch to prooph/event-store v8 and use EventStoreDB ;) That would be the safest path for the future even with a lot more players and events in the system.
yes we are using snapshots. I guess on a daily basis its around 50ms to load but when we have this issue that the source is halted and we get huge batches of data it struggles a bit. kind off we find that sometimes takes half a seconds... with data of around 1 week sent together
so its reasonable but still
Another option is to switch to prooph/event-store v8 and use EventStoreDB ;) That would be the safest path for the future even with a lot more players and events in the system
so with EventStoreDB I would have better performance for AggregateStreamStrategy
we are currently using prooph/event-store v7.5.6
Every service has it's own local event store and then there is a shared event store with each service having a public stream in that shared store. There was some trouble with projections consuming too much resources but this was mainly caused by the set up of the docker containers and K8s cluster.
For prooph board we use AWS SQS as an event-driven transport.
DS-UUID1[xxxx]
For our client this was more of a problem and one reason they decided to use persistent public streams. A team can set up a new service without coordinating that activity with other teams. They just consume all public streams they need and that's it. Definitely a huge advantage, but it's not for free.
Also all teams use prooph board to design their services and document the events available in the public streams.
They have bi-weekly architecture meetings with all team leads on prooph board to discuss public event changes in the streams: like new event versions, new available event types, new consumers and sometimes even new stream versions.
They found a very good way (with our help ;)) to handle their architecture, but without proper collaboration and documentation you can end up in a mess.
https://github.com/prooph/pdo-event-store/releases/tag/v1.14.0
1 reply
Hey, I'm thinking about a revival of prooph/event-sourcing but in a totally new way and it would be nice to get some feedback regarding the idea:
@sandrokeil had the idea to create a plugin for Cody (https://youtu.be/0FAgsPNqUV4) that generates framework agnostic domain model code: aggregates, value objects, messages, handlers, ... from a prooph board event map.
One reason to abandon prooph/event-sourcing was that it creates a framework dependency in your business logic. Something you don't really want. So instead you should use the package as inspiration only. But what if you could have a code generator, that generates all the glue code for you in the namespace of your choice?
- Value Objects
- Event Sourced Aggregates
- Commands
- Events
- Repository Interface
One can then connect the result with the framework of their choice. We think about prooph/event-store and Ecotone packages that can be used in combination to also generate framework related glue code (e.g. repository implementation, PHP8 attributes for Ecotone, ...)
Would you be interested in such a package?