These are chat archives for YoEight/eventstore

6th
May 2016
Akii
@Akii
May 06 2016 16:27
whee nice client :D
Yorick Laupa
@YoEight
May 06 2016 18:33
Thanks, it's appreciated !
Akii
@Akii
May 06 2016 18:34
it's really nice, I tried the subscriptions today
it's just wow
Yorick Laupa
@YoEight
May 06 2016 18:34
which kind ?
Akii
@Akii
May 06 2016 18:35
the catch up one
Yorick Laupa
@YoEight
May 06 2016 18:35
cool
Akii
@Akii
May 06 2016 18:35
hm I am still new to Haskell and I find it difficult to organise my events though
Yorick Laupa
@YoEight
May 06 2016 18:35
I use it in production already but it's always good to hear it works for others too :-)
Akii
@Akii
May 06 2016 18:35
I want to focus more on streams and less on aggregates
so that kinda leaves me with one option: data Event = All | The | Events
Yorick Laupa
@YoEight
May 06 2016 18:36
well, there are more literature on OOP for sure
Akii
@Akii
May 06 2016 18:36
aggregates itself are kinda oop-ish
Yorick Laupa
@YoEight
May 06 2016 18:37
true but I successfully implemented those already
Akii
@Akii
May 06 2016 18:37
ye it's just state
Yorick Laupa
@YoEight
May 06 2016 18:37
yes
most of the time, I use STM to handle my state threadsafely
Akii
@Akii
May 06 2016 18:38
also I find "Process" is such a more nice word for aggregates
do you have an idea how I could express that fx. a projection can handle a set of events?
Yorick Laupa
@YoEight
May 06 2016 18:39
well, I working one a complex event processing lib (base on stream processing algebra) to operate with EventStore (not exclusive)
Akii
@Akii
May 06 2016 18:39
projection being [e] -> s more or less
Yorick Laupa
@YoEight
May 06 2016 18:39
it really depends of the use-case really
Akii
@Akii
May 06 2016 18:40
:o that sounds interesting
it's always events and then you have an effect on those I guess
a long running projection could be state
Yorick Laupa
@YoEight
May 06 2016 18:41
you might be interested into FRP here
Akii
@Akii
May 06 2016 18:41
ye but that is really abstract
Yorick Laupa
@YoEight
May 06 2016 18:42
depends, reactive-banana or event sodium are really practical
first version of the driver used sodium
Akii
@Akii
May 06 2016 18:43
I took a brief look at reactive-banana, I'll check out sodium :D
Yorick Laupa
@YoEight
May 06 2016 18:43
those are pretty similar if you ask me
it might be a too big of a step if you've just started learning haskell though
Akii
@Akii
May 06 2016 18:44
that's probably the problem :D
I mean if you look at business processes - they're mostly simple
Yorick Laupa
@YoEight
May 06 2016 18:45
sure
Akii
@Akii
May 06 2016 18:45
given x if y happens do z
Yorick Laupa
@YoEight
May 06 2016 18:45
the only issue with Haskell here is tracking of effect
Akii
@Akii
May 06 2016 18:45
x is previous state, y is an event, z is a command (or event)
yep
Yorick Laupa
@YoEight
May 06 2016 18:46
that what is making to code not obvious at the first glance
Akii
@Akii
May 06 2016 18:46
so for me, eventstore subscriptions make the entry point easy
Yorick Laupa
@YoEight
May 06 2016 18:46
good :-)
Akii
@Akii
May 06 2016 18:46
like they give me events, I can run projections easily now
Yorick Laupa
@YoEight
May 06 2016 18:46
those feel like queues
Akii
@Akii
May 06 2016 18:46
yep
so I stick in a Conn I get a projection that does its thing
and more importantly, the events come from the store
still migrating my mind to the FP world where you can't just have an EventBus that you inject into some object and then it does side effecting magic
so the world for me looks like this atm: (magic) -> ES -> Projection
but, that is a nice start
Yorick Laupa
@YoEight
May 06 2016 18:54
That's a way to see it
For myself, I see everything as a foldl
If you have some real code, I could help
Akii
@Akii
May 06 2016 18:56
it's too early, but ye my initial version of projections is a simple foldl
and it will probably remain that way
sec :D
Yorick Laupa
@YoEight
May 06 2016 18:57
that's what I do in production
but my library takes a different approach
Yorick Laupa
@YoEight
May 06 2016 18:57
even if it foldl at the end
Akii
@Akii
May 06 2016 18:57
like this most basically
Yorick Laupa
@YoEight
May 06 2016 18:58
composing it's just better
Akii
@Akii
May 06 2016 18:58
with subscriptions you need a way to continuously fold left
Yorick Laupa
@YoEight
May 06 2016 18:58
yes, It's easy to implement
Akii
@Akii
May 06 2016 18:59
well if I think again, with subscriptions you get one event at a time so basically you don't even fold
Yorick Laupa
@YoEight
May 06 2016 18:59
not exactly
you have it as those arrive
you don't ask to read more event
there is already one or you have to wait for it
you can implement something similar to foldM or foldM_
Akii
@Akii
May 06 2016 19:01
I did a naive implementation today
_ <- forkIO $ forever $ do
    ev <- nextEvent sub
    putStrLn $ show ev
Yorick Laupa
@YoEight
May 06 2016 19:02
yes but that isn't a fold
Akii
@Akii
May 06 2016 19:02
well the fold happens on the eventstore
Yorick Laupa
@YoEight
May 06 2016 19:02
I can write you one quickly
Akii
@Akii
May 06 2016 19:02
not really
this would need to somehow make use of apply directly
Yorick Laupa
@YoEight
May 06 2016 19:07
what's apply ? do you mean your aggregate apply ?
Akii
@Akii
May 06 2016 19:07
(just stumbled upon this book, do you know it? https://www.manning.com/books/functional-reactive-programming)
the apply method from my Projectable typeclass
could be aggregate apply as well
Yorick Laupa
@YoEight
May 06 2016 19:08
I don't know this book
Akii
@Akii
May 06 2016 19:08
although I'm heading away from aggregates towards a more stream based approach
Yorick Laupa
@YoEight
May 06 2016 19:09
your Projectable apply function can't handle IO effect
that's why you are not able to do it
I could come up with a foldM for Subscription
Akii
@Akii
May 06 2016 19:11
the questions is: does it have to
the projection itself is pure
Yorick Laupa
@YoEight
May 06 2016 19:11
there are used cases where it does
Akii
@Akii
May 06 2016 19:11
unless you do DB interaction
but assuming you just take the state of the projection every so often and persist it, it would move the IO out of the projection
Yorick Laupa
@YoEight
May 06 2016 19:11
in particular aggregate dealing with aggregates
Akii
@Akii
May 06 2016 19:12
well it would make sense to put all of that into the projection
and not back out.. that complicates things a lot
Yorick Laupa
@YoEight
May 06 2016 19:13
yes
but some use cases are complicated too
I don't know what's the best solution frankly
There are still things I'm figuring out
in particular in Haskell design space
Akii
@Akii
May 06 2016 19:19
so I will investigate the mapM thing :D
and then try to do combine this with the subscription
thanks for your help! I'll report back on my progress hrhr