21 likes
·
3.7K reads
9 comments
Hi, For the ZPure type W, you mentioned "I've used it for storing events in an event sourcing application, for feeding a stream of messages to players in a game, but also for storing actual logs" Isn't logging or firing events a side effect? And should no be in ZPure?
That's right, but in the ZPure layer I only accumulate them. After running the ZPure, if the program was successful only then I actually log them or do something with them.
I See, Thank you :)
Thank you for this insightful review of stacked technologies. But I still wonder if guilds are contained in one server but other things are not. I guess the ZIO effect code needs to access multiple guilds from different servers. How do you solve this communication issue?
Very Interesting, but I am still confused... If Shardcake entity handling messages one at a time, just like Akka actor does. Why do you need to handle race condition?
This allows you to handle the actor messages in parallel instead of sequentially (e.g. using mapZIOPar or just forking each message handling). Now depending on the use case that may or may not be desirable. If there would be a lot of contention (each request handling accessing the same objects), sequentially is probably better. In that case you can still use the ZIO/ZPure separation and skip the ZSTM layer. In my use cases (games), we often want to respond to client requests ASAP so parallelizing is better.
Thank you for the comprehensive explanation. I learned a lot. Much appreciated.
