
Wolkenkit 3.0 – a CQRS and event-sourcing framework for JavaScript - goloroden
https://www.thenativeweb.io/blog/2018-12-04-18-17-introducing-wolkenkit-3-0/
======
tchaffee
From the home page:

"wolkenkit is a CQRS and event-sourcing framework for JavaScript and Node.js
which fits perfectly with domain-driven design (DDD). It provides the
technical foundation for your application, including an event-store and a
scalable real-time API. This allows you to focus on what's essential: Solving
actual real-world problems in no time."

I've been a developer for decades and this means almost nothing to me. I'm
sorry if this comes across as harsh - I'm just trying to be helpful. What's
your elevator pitch for this product? I'm not looking for CQRS because I don't
know what it is. How many more people might you attract to your product if you
could translate your pitch into how it benefits me? It's really hard coming up
with your one-liner in plain English. But every time I see a one-liner that
means very little to me as a programmer (which is unfortunately most
projects), I encourage folks to put in the effort. Otherwise, I just skip over
it and move on. And I'm guessing I'm not the only one.

Here's a one liner I think works well: "React: A JavaScript library for
building user interfaces".

I hope that helps.

~~~
linkmotif
Maybe you should check out CQRS? You already know what a UI is, so the React
tagline makes sense to you. Likewise with CQRS and the other things you don’t
recognize, they’d make sense if you spent as much time looking them up as
writing about how you don’t know what they are? I mean, this is not a product,
it’s a software framework. Maybe that’s a product to someone, but to me that’s
a tool you need to learn about if you want to make sense of it. It’s like
you’re expressing frustration about not knowing something, which is easy to
fix in 2018.

~~~
goloroden
I think one thing that is also important here is (and this also may sound
harsh, but is not meant to be offensive): If you don't know what CQRS and
event-sourcing are, you probably don't have the problem that CQRS and event-
sourcing solve ;-)

~~~
linkmotif
Which is funny because I’d think anyone who’s ever tried building and then
maintaining a web app would recognize they have the problems CQRS/ES is trying
to solve, but the that shouldn’t be taken for granted I guess.

~~~
sidlls
This architecture isn't necessary for most apps. It meets a specific need with
serious constraints that have to be considered before making use of it.

~~~
kilburn
The catch with CQRS is that it isn't widespread enough that everyone
recognizes its shortfalls, and the upsides are really easy to convey:

\- Excellent auditing abilities

\- "time-traveling" debugging (you get the entire history of what happened)

\- Easy backup abilities (append-only stores are objectively easier to backup)

\- Datastores tailored to your querying requirements (say bye to monstruous
SQL queries)

These are the things you see on CQRS-related websites. Then you decide to try
it or to research conference talks and such and you find out the downsides:

\- Data deletion is now a PITA (and you need it if only for legal reasons)

\- Doing actual transactions (in the ACID sense) is now somewhere between hard
and impossible

\- Welcome to the magic world of non-linearizable datastore operations. Here
be dragons.

\- If you make a mistake (wrong event / wrong data in an event) you will
suffer from it greatly, possibly for all eternity.

~~~
jsd1982
I think you're speaking more about event-sourcing than CQRS. CQRS is a generic
concept that's only about separating writes from reads. It's useful paired
with event-sourcing but on its own it does not suffer these specific
drawbacks.

Another problem with event sourcing is that there is no easily definable
concept of a "field" that can be read from and written to using a named
address (contrast with a SQL table column identifier). For a given aggregate,
you'll have a single command service that writes a set of "fields" and an
unbounded number of query services that receive a copy of that "field" from
the event stream and can transform it in any imaginable way. Your "field" may
be renamed and moved around through its journey from your command service's
API request body to your event's serialized form and to your query service's
internal data structures and its final resting place on the query service's
persistence data store (mongodb or SQL table or whatever).

To identify a field, it's best to use its writable address, and you'll need to
come up with your own identifier namespace and naming convention to represent
those addresses.

~~~
kilburn
> I think you're speaking more about event-sourcing than CQRS

True. I was reading to the comments here and yes, most of them were focusing
on the Event Sourcing part of Wokenkit, not the CQRS so my mind got tricked.

------
tomphoolery
Love how the "Getting Started" to Wolkenkit doesn't even have any tangible
code until page 3. If your quick start guide can't even get to the point until
halfway down the page, I'm gonna bet that your framework isn't very user-
friendly.

Also, can anyone tell me what this even does? I've been clicking around and
besides a bunch of vapid "philosophy" documents I can't figure out what the
fuck anyone would use this for...

~~~
akiselev
As others have said on this page, event sourcing is one of those technologies
where if you don't know what it is, you certainly don't need it. Even if you
do know what is, you usually don't need or want it unless you have no choice.

In event sourcing, instead of having stateful objects, you have a log of
events that you use to build that state. It gives you powerful rollback,
backup, and history features at the expense of some insane code complexity
(usually solved by tooling). When paired with CQRS, another architecture
separating reads and writes in your abstractions, and done well with events
that are domain oriented ("AccountingReconciliationStarted" instead of
"StartButtonClicked"), you can hide most of the code complexity and allow
developers and less technical users to focus on domain complexity (i.e., the
logic that matters to the real world).

At least in theory.

~~~
elcritch
Why the insane code complexity? Yes there can be a lot of complexity in
storing the events but using Kafka or similar event stores which provide
libraries for handling the connection details should remove most of that
complexity. Then your code can essentially be written as a map-reduce. Add a
stream filter and it can easily be transformed to/from a Redux event system to
a business one. Perhaps if your codebase didn’t build on a streaming
architecture it would necessitate a lot of advocacy code.

------
bengale
This is the one that you can't use for commercial projects?

~~~
hbbio
Very funny, since we tried this... 6 years ago. At the time, HN reaction was:
[https://news.ycombinator.com/item?id=3931525](https://news.ycombinator.com/item?id=3931525)

And you know what? It was true. We changed the licensing to MIT for most of
Opa ([http://opalang.org](http://opalang.org)), but maybe a bit too late.

~~~
goloroden
But what other options than going dual-license do you have if you want to do
open-source in a sustainable way? MIT does offer nothing here, unfortunately.

~~~
hbbio
There are many good business opportunities if your open source technology,
without strings attached, gets popular. You could just sell professional
support as part of subscriptions and verified builds. Later on, when you
release a new version, you can still support the previous one or build
migration tools that you include with subscriptions, etc.

~~~
goloroden
That's true, but on the other hand there are also successful (A)GPL open
source projects … think of Linux (or MongoDB, at least for a long time).

~~~
Varcht
See also "economy of scale"

------
hknd
Looks really interesting.

Are there any companies using this in prod already? Or any load experiment
numbers? Proving that this actually is a "scalable real-time API"?

~~~
goloroden
Thanks for your nice feedback :-)

Yes, it is already running in production, but due to NDAs, unfortunately I
can't provide any details here.

Regarding the scalability most is prepared, but there are still a few things
that need to be done. We would be more than happy for anyone who wants to
contribute or to sponsor us. For details see
[https://github.com/thenativeweb/wolkenkit/issues/90](https://github.com/thenativeweb/wolkenkit/issues/90)

------
pibi
[https://www.wolkenkit.io/#getting-started-test-
drive](https://www.wolkenkit.io/#getting-started-test-drive)

I don't see any messages in my network console, so it seems the message form
is actually not really sending anything and the app is not a real wolkenkit
app. Am I right?

~~~
goloroden
The getting started part is only simulated, to actually get started, please
see [https://docs.wolkenkit.io/3.0.0/getting-started/creating-
you...](https://docs.wolkenkit.io/3.0.0/getting-started/creating-your-first-
application/setting-the-objective/)

------
z3t4
Why does libraries like this insist of using a query language similar to SQL
rather then map, reduce, filter that are more like JavaScript!? Or is SQL so
much better ?

------
boubiyeah
That header animation was cool only the first 50 times I saw it

------
Yuioup
CQRS and Event Sourcing ... run away, run far, far away.

------
ziont
when do you use cqrs/es ?

is this like Datomic?

~~~
spoudaia
To cut a long story short: Event-sourcing as a persistence mechanism, where
you store deltas instead of the current state, similar to what Git does. CQRS
is a pattern to separate the write side from the read side of your
application, with the goal of being able to scale both independently of each
other.

Regarding Datomic: I'm not an expert for Datomic, but AFAICS Datomic is
primarily a database, while wolkenkit is an out-of-the-box full-featured
framework for business logic, storage and so on.

~~~
jen20
Just to clarify here: event sourcing is _not_ what Git does at all. Git stores
complete snapshots of objects, not diffs [1].

Event sourcing itself is a fairly straightforward concept which the parent
does sum up though - store events which describe what happened to an entity in
a system rather than the resulting state. The state of an object can be
derived via application of a left fold over the history.

[1]: [https://willi.am/blog/2014/10/14/for-the-last-time-git-
store...](https://willi.am/blog/2014/10/14/for-the-last-time-git-stores-
snapshots-not-diffs/) \- this is the best reference I can find quickly, though
the git manual would obvioiusly be more authoritative.

~~~
goloroden
As said, "similar" to what Git does ;-)

Conceptually, it's still capturing the deltas, instead of storing the current
state and overwriting it. Storing the history is the key ingredient here, and
of course, there are differences in how to achieve this.

~~~
jen20
I would argue that there is a fundamental difference between the two: one
stores the state and calculates the deltas, and the other stores the deltas
and calculates the state.

Both are common in systems, but only the latter is event sourcing - at least
if the definition is to have any use and not become overloaded.

~~~
linkmotif
Yeah every time people say Git stores deltas it’s sad because the fun thing
about Git is that it DOESNT store deltas.

