Show HN: Sparbuch, an event-store for Node.js(npmjs.com)
npmjs.com
Show HN: Sparbuch, an event-store for Node.js
https://www.npmjs.com/package/sparbuch
9 comments
Yes, you are right: Many applications can work without those features that you referred to as "advanced". So, I agree that it might be a good idea to separate the docs more into the basics and advanced things.
Thanks for the suggestion :-)
(PS: I'm one of the authors of sparbuch.)
Thanks for the suggestion :-)
(PS: I'm one of the authors of sparbuch.)
This seems somewhat complex to me.
Are there any suggestions for simpler event stores (perhaps with the interface of an event queue) in any language?
Are there any suggestions for simpler event stores (perhaps with the interface of an event queue) in any language?
A couple of days coding around RocksDB or LMDB would allow you to write one yourself.
I'm not mentioning LevelDB on purpose because it doesn't allow you to have several processes writing and reading to the store at the same time, which really sucks if you want to separate ingestion and projection services, for example.
I'm not mentioning LevelDB on purpose because it doesn't allow you to have several processes writing and reading to the store at the same time, which really sucks if you want to separate ingestion and projection services, for example.
Thanks for the pointers!
Is the name a portmanteau of Baruch Spinoza?
Sparbuch is the German word for a savings account. The idea behind the name is as follows:
A credit institute doesn't store your current balance, but keeps a list of deposits and payouts, which can be used to recalculate the current balance (or any balance from the past).
In the same way, an event store does not store the current state, but keeps a list of events, which can be used to recalculate the current state (or any state from the past).
A credit institute doesn't store your current balance, but keeps a list of deposits and payouts, which can be used to recalculate the current balance (or any balance from the past).
In the same way, an event store does not store the current state, but keeps a list of events, which can be used to recalculate the current state (or any state from the past).
Is it really necessary to read unpublished events, publish multiple events at once, ...? I guess a large percentage of applications could do without that - Just publish all events immediately and read only published.
IIUC (the docs), this should be possible anyway. So, it might be helpful to describe this standard use case better, and create separate docs for advanced features (not in Readme)...