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

11–20 of 64 posts

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

#11

Post by kyleperik »

lojack wrote: post #7
kyleperik wrote: post #3

"Functional Database" is contradictory. Honestly this sounds like a bunch of buzzwords concatenated together. Is there an example or a purpose for this?

It isn’t that contradictory. You can have data in a functional language. One of the common features of a functional language that separates it from imperative is data immutability. In this case it’s a database of immutable data. I personally understand exactly what they’re talking about when they call it a functional database.

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?

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

#13

Post by federicoponzi »

kyleperik wrote: post #11
lojack wrote: post #7

Earlier quoted context omitted.

It isn’t that contradictory. You can have data in a functional language. One of the common features of a functional language that separates it from imperative is data immutability. In this case it’s a database of immutable data. I personally understand exactly what they’re talking about when they call it a functional database.

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

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

#15

Post by twic »

Some ex-colleagues were considering using this a few years ago. They were getting interesting in CQRS, got Greg Young in to give a talk, and came away filled with enthusiasm. I think they ended up doing something incremental on top of the MySQL they already had, rather than switching over to this.

Is there a particular reason this is suddenly exciting again now?

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

#16

Post by tobr »

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 are composed that tend to happen in a typical Redux app, and gets all the declarative benefits of selectors. It makes it easy to load code for new selectors asynchronously (for example when navigating to a new route), and because the state is a long list of every state your app has ever been in, they can "rewind" as far back as they need to sync up correctly with the rest of the app.

What I've realised recently is, this is basically event sourcing. Replace actions with events, selectors with projections, and memoization with snapshots. So this submission is certainly timely and of interest to me. Thanks!

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

#18

Post by jmcqk6 »

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.

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

#19

Post by platz »

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.

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

#20

Post by kyleperik »

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

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.
Post reply on HN