Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EventStore: Open-Source, Functional Database with Complex Event Processing in JS

github.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#51

Post by tobr »

codebje wrote: post #45
tobr wrote: post #16

I've played around recently with a Redux inspired frontend architecture where the complex, nested reducers are replaced with a single one that simply adds every action to an immutable linked list (i.e, `(state, action) => ({state, action})`. This means all the business logic that would normally live in reducers can be moved over to memoized selectors, which fixes the awkward difference in how reducers and selectors a…

If actions are fully deterministic, a list of actions is isomorphic to a list of events: you can always determine what happened by looking at what was requested. A list of all past states avoids the determinism problem, but the consequence of each action is only implicit in the difference between two states. For event sourcing, "the state" is the list of events, and what you're calling "the state" is just another sel…

No, I’m suggesting that your state should be a list of event/action objects. By using a linked list, every new state can have a reference back to the previous state. This is not a projection, but a way to immutably append new actions to a list. This list is the state that you’d pass to selectors.

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#52

Post by tobr »

acemarke wrote: post #21
jmcqk6 wrote: post #18

Earlier quoted context omitted.

This mirrors exactly the way I've been approaching redux recently as well following the same realization. I feel like this is much cleaner and easier to reason about.

Hi, I'm a Redux maintainer. Got any examples of this? Also, how do you feel it's better than a typical Redux app setup?

For me it’s been experimental so far. I’ve not actually used Redux in these experiments, but I’m inspired by where Redux and Re-reselect has been leading me for the past two years or so. The pattern is a gold mine of interesting implications that I’m still discovering, such as real time collaboration, and speculative precomputation/prefetching.

As it moves all the focus from reducers to selectors, and has quite different requirements for how to do caching there, it’s led me to work on a custom selector library with quite different API from reselect/re-reselect. I’d like to release it when my experiments start to feel... less experimental.

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#54

Post by kyleperik »

naasking wrote: post #28
kyleperik wrote: post #20

Earlier quoted context omitted.

Oh I see I misunderstood then. But still, how is this a database? Without looking into it too much it seems that would either be an ORM or simply state.

A database is simply an organized collection of data with a restricted interface for accessing and/or querying said data. This seems to qualify.

Should we call PANDAS a database?

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#55

Post by naasking »

kyleperik wrote: post #54
naasking wrote: post #28

Earlier quoted context omitted.

A database is simply an organized collection of data with a restricted interface for accessing and/or querying said data. This seems to qualify.

Should we call PANDAS a database?

Add "durable" qualifier to my definition, since otherwise you could say that it's just a data structure. Which it is, but with durability properties.

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#56

Post by ouro »

circleoncircles wrote: post #4

It's not a new concept.

To be fair I have been talking about event sourcing for over a decade. The concepts have been around far longer than that. In fact most databases "event source" their own internal structures.

There is however benefit to modelling a system in that way and not just an internal transaction log. I have done many talks on the subject and you should be able to pull one up on youtube etc fairly quickly (its a bit much to go through in a comment).

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#57

Post by pgwhalen »

platz wrote: post #19

Event Sourcing seems like the ultimate YAGNI architecture. You make an architecture that optimizes for future features at the expense of a coherent flow for the current features that you know you have. it's like if you made pub-sub the core architecture for your system. very actor-system like, but also probably harder to understand the runtime behavior - control flow.

With good tooling, it is arguably a lot easier to understand than a synchronous microservices architecture, because of the persistence of events.

I’ll admit it’s probably harder to debug than a monolith, but that’s true of any distributed system.

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#58

Post by eithed »

kyleperik wrote: post #20
federicoponzi wrote: post #13

Earlier quoted context omitted.

I think your question is answered here: https://eventstore.org/docs/event-sourcing-basics/event-stor...

Oh I see I misunderstood then. But still, how is this a database? Without looking into it too much it seems that would either be an ORM or simply state.

Think about it as database of function calls, ordered by creation time. I'd however call it a log rather than a database - there will be a state your data achieves, but ES becomes the source of truth . DB can still used to contain the current state (however is not needed as ES tracks its own state) and data can be dropped from DB without repercussions, if you don't mind replaying events and have a separation of events that deal with setting data / performing external actions (like sendin emails for example)

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#59

Post by Fire-Dragon-DoL »

BillinghamJ wrote: post #32
TheLudd wrote: post #25

I do event sourcing in my company and we had a look at this when we started out 4 years ago. What I don't understand is why build a database? Why not build something in the application layer that uses your fav database as a storage mechanism instead? Aren't the existing databases more mature and better to use?

There are a lot of non-trivial aspects to scaling event sourcing systems. Particularly if you want atomicity or asynchronous two-phase committing. Having implemented them ~5 different ways for different services at my startup, I’d definitely welcome a reliable DB-level abstraction.

Sorry for my inexperience in this kind of implementation but wouldn't an sql transaction achieve something similar? And with table partitioning (at least on postgres) you should be able to go quite far, instead of neediness a new db (and a lot of related stuff to study)

Re: EventStore: Open-Source, Functional Database with Complex Event Processing in JS

#60

Post by juancampa »

tobr wrote: post #52
acemarke wrote: post #21

Earlier quoted context omitted.

Hi, I'm a Redux maintainer. Got any examples of this? Also, how do you feel it's better than a typical Redux app setup?

For me it’s been experimental so far. I’ve not actually used Redux in these experiments, but I’m inspired by where Redux and Re-reselect has been leading me for the past two years or so. The pattern is a gold mine of interesting implications that I’m still discovering, such as real time collaboration, and speculative precomputation/prefetching. As it moves all the focus from reducers to selectors, and has quite diffe…

Wow, I'm super curious about this now. Please keep us posted
Post reply on HN