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

21–30 of 64 posts

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

#21

Post by acemarke »

jmcqk6 wrote: post #18
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…

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?

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

#22

Post by hudo »

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.

Try to solve complex architectures that can handle race conditions without some kind of event sourcing, good luck with that

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

#23

Post by root_axis »

Yuioup wrote: post #17

I've had to break it to my client that had built a CRUD application using CQRS and Event Sourcing that they have wasted a huge amount of resources on a misguided architecture. A rewrite is pending.

> A rewrite is pending.

So another huge amount of resources wasted.

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

#24

Post by maskull »

Yuioup wrote: post #17

I've had to break it to my client that had built a CRUD application using CQRS and Event Sourcing that they have wasted a huge amount of resources on a misguided architecture. A rewrite is pending.

Is it being rebuilt as pure CRUD? I've been working on an app lately where the major entities in the relational db won't be updated. They'll will just be superseded by the next record.

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

#25

Post by TheLudd »

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?

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

#26

Post by bauerd »

federicoponzi wrote: post #13
kyleperik wrote: post #11

Earlier quoted context omitted.

I don't understand how this is useful. The purpose of functional programming isn't to make everything immutable, but to use immutability to prevent unnecessary change of state which can result in flaky code. So where's the usefulness in a functional Database? Also this still isn't functional. Is adding records to a set not mutation?

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

They should make this more prominent, now I get what it does

Edit: Is a backup mechanism implemented? It's for persistent data, right?

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

#27

Post by honestlyidk »

root_axis wrote: post #23
Yuioup wrote: post #17

I've had to break it to my client that had built a CRUD application using CQRS and Event Sourcing that they have wasted a huge amount of resources on a misguided architecture. A rewrite is pending.

> A rewrite is pending. So another huge amount of resources wasted.

rewrites are really the on thing all programers enjoy doing. If it works dont touch it, should have caught it sooner. Make the next project better and move on.

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

#28

Post by naasking »

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.

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

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

#29

Post by arnioxux »

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…

I wrote a similar comment before, viewing redux as a realization of the event sourcing pattern: https://news.ycombinator.com/item?id=17061827

You can go even further and use the exact same "events" or "actions" for event sourcing on the server side too. You just need to save the list of actions to the server. This lets you do realtime sync and multiplayer really easily!

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

#30

Post by stabbles »

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…

This was also acknowledged by Greg Young a long time ago :) [1]

[1] maybe this talk? https://www.youtube.com/watch?v=JHGkaShoyNs

Post reply on HN