Live data from Hacker News

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

github.com

61–64 of 64 posts

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

#61
post #52

Earlier quoted context omitted.

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

That’s nice to hear, good motivation to get it out the door. It might take some time, but I’ll be sure to do a show HN when it happens!

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

#62
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.

It's not like you are paying that price for long. Usually you'll start getting benefits the next month, as soon as someone wants new numbers in the dashboard. Or as soon as a new feature needs to be added

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

#63

Earlier quoted context omitted.

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)

No because in a distributed system, you can't rely on SQL transactions. i.e. if you need to make one API request to start the transaction and a second API request to commit it/rollback - you can't hold the SQL transaction open between those.

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

#64
post #61

Earlier quoted context omitted.

Wow, I'm super curious about this now. Please keep us posted

That’s nice to hear, good motivation to get it out the door. It might take some time, but I’ll be sure to do a show HN when it happens!

Please ping me as well - I'd certainly be interested.
Post reply on HN