Hacker News Reader

"Wolkenkit: A JavaScript library for building event-sourcing applications"

As others have pointed out, neither of those two are useful if you don't know what "user interfaces" or "event sourcing" are.

What you're looking for is this: https://martinfowler.com/eaaDev/EventSourcing.html

Your version is still a big improvement. I only have to look up event sourcing now. But I would throw a couple of the benefits of event sourcing into that elevator pitch. Others already have. Here's mine, now that I've learned a little more:

"Wolkenkit: A JavaScript library for building event-sourcing applications.

Event sourcing is an alternative to relational databases and uses a transaction log as the primary source of data which gives you a true history of how data has changed. This allows you to put your application in any prior state which is useful for debugging, audit, traceability, and easier backups along with other benefits. Wolfenkit is the fastest JavaScript event sourcing framework by far."

I'm sure someone could do even better than that. But now any programmer who comes across this knows what event sourcing is at a very basic level, some of the benefits, and why this particular framework should be considered. A lot accomplished.

I also think it's fair to point out that "user interface" is a term every programmer knows. I typically read an hour or two a day from a variety of tech sources to keep up on best practice in programming, and I just now heard of event sourcing. I could just be out of it, but Google search shows about 219,000 results for "event sourcing" and about 78 million results for "user interface". I think I'm on solid ground saying that one deserves to be explained and the other is common knowledge.

EDIT: here is another one liner from another comment that I think works great: "Wolkenkit is a framework that allows you to save and replay your entire business's history so you never miss a key insight again." No jargon. Gives a key benefit. I'm interested. Maybe even as a business person. Tell me more.

It's trying to sell you to the newest enterprise fad of "CQRS" and "event sourcing" :). If you don't know the meaning of those terms, or don't feel compelled to learn the meaning, then the product is likely not for you.

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.

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 ;-)

Even if you know what they are you probably don't have the problem they solve :)

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.

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.

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.

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.

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

Great overview! I’ve hit these problems. I wish people would be more honest and upfront about how it’s really hard to implement these patterns and operate them.

That said, I think that’s what frameworks are all s about. I’m using Kafka Streams which is an amazing foundation for CQRS/ES but the absence of a framework for it means you need to implement all these models/patterns by hand. It’s pretty hard.

Most apps need migrations. Isn’t the best migration the one you didn’t do? If you have CQRS and event sourcing, you can create views like hot cakes.

I read one to two hours a day keeping up with the latest jargon and best practice. I'm pretty sure every programmer knows what a user interface is. I'll guess that most programmers don't know what CQRS is. And with how busy we all are as devs I think my point is still valid: tell my how it benefits me and I might read further. Others here have already done a really good job of improving on the jargon-filled original description. So I'm not wrong in saying there was room for improvement.

> It’s like you’re expressing frustration about not knowing something

I'm not. I'm trying to help startups and small projects do a better job of communicating what value they add so that potential customers and users don't skip over their project.

These are industry standard terms that allow for efficient high-level descriptions of complex concepts. That's what jargon is for.

It's on you to know those concepts so you can understand these terms. Would you read technical descriptions that a doctor would be familiar with and complain that they don't explain all the basics for you? Perhaps you should invest effort in learning instead of skipping it and moving on?

Even as someone who uses CQRS/ES on a daily basis, I don't expect most engineers to know them, just like I wouldn't expect a lot of engineers to know "currying".

Tech is a big field, it has a ridiculous amount of vocab. Unlike Doctors, we didn't standardize heavily.

The medical field is big too. The point is that it's your responsibility to learn things, not expect every piece of jargon to be explained to you.

I think you missed op's point. They weren't seeking an explanation, they were pointing out the initial sales pitch was too jargon dense as to be meaningless. The initial sales pitch might as well be in ancient Greek for your average engineer.

That doesn't make sense. Of course it's meaningless if you don't know the jargon.

The op says the product devs should "put in effort" otherwise the op will "skip over it and move on". This is backwards because it's up to you to learn things you don't know.

As a professional of course I try to keep up with industry standard terms and jargon. My point still stands because it's not about my lack of knowledge.

My point is that your elevator pitch, and what's on the landing page of your website, shouldn't tell me what cool buzzwords you use in your tech stack. Potential users / customers generally don't care. They care about how it benefits them.

> It's on you to know those concepts so you can understand these terms.

It's not if you want me as a customer. I don't have the time to look into the literally thousands of projects out there asking for my attention and then to learn the jargon to see if the project perhaps meets one of my current needs. Usually it doesn't. So if you want my attention, tell me how it benefits me. It's not going to hurt me to skip over it. A smaller project that gets no attention will just eventually die. So small projects / startups need to make their value proposition very clear if they want to stand out from the crowd. That's why incubators like Y Combinator insist you spend the time to get your elevator pitch right.

> Would you read technical descriptions that a doctor would be familiar with and complain that they don't explain all the basics for you?

If I were a busy doctor, I would want to start with the one liner "treats depression faster than other drugs in its class and with fewer side effects". Now I'm interested enough to read the tech details and why.

Bad: React is an ES 2015 JS framework that uses JSX along with Babel and Webpack to create a virtual DOM along with efficient tree diff algorithms to prevent unnecessary renders.

Who cares? It sounds like a bunch of bragging about implementation.

Good (from their landing page): React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.

Now I know how it benefits me. Almost zero jargon, and what jargon they use is very basic.

I hope that helps you understand where I'm coming from. Which is an attempt to help startups and small projects get their one-liner / elevator pitch right. Get it right, and then I'll be interested in how you implement it.

> It's really hard coming up with your one-liner in plain English

Sometimes libraries are there to solve problems that you only have when doing a certain thing a lot and you are involved in that any way. That's when abstractions happen. CQRS/DDD are quite established enterprise patterns, these are not for everyone, on the contrary. Probably you don't want to do this.

A library implementing a thing I don't think should be on the hook for educating people what the thing is.

And, it's a matter of continuum anyway and where in the continuum your 1-liner should draw its line; web pages for programming languages need not (and should not) explain what programming is, how computers work, 2's complement, bits, etc.

In contrast, I thought that was a great description, admittedly because I am familiar with the domain. If I didn't know what JavaScript was, I'd be at lost as you are with CQRS. ;-)

I guess it depends on whether or not you want to attract customers / users not already familiar with the domain. Maybe in some cases you want to exclude anyone who isn't already in the know. But I would guess that's rare.

If you don't know what CQRS or event-sourcing is, you probably also have no usecase for this framework.

Or maybe they just didn't know the jargon for these things. This industry is filled with individuals having no formal training and it is filled with plenty of non-standard jargon. It isn't unreasonable to ask that said jargon not appear in the one-liner when the intent is to sell, so to say, the framework.

In my org, "event sourcing" is the metastasizing obfuscation layer over the mainframe era batch data processing complexity catastrophe.

PS- Move the code, not the data.

wolkenkit: A JavaScript framework for building scalable APIs that use historical data

We have had a very hard time to grasp what's special with CQRS and event-sourcing, and to put it into a one-liner, but basically, I agree with you.

That's so much better. Now I know what it does. I know whether or not to read on. But I would also throw a benefit or two in there. Why should I use a framework (or your framework specifically) if I want to build a scalable API that uses historical data?

And the next step is putting your one-liner everywhere that people first come across your product. On your website main page, and especially at the beginning of blog articles.

I guess this is becoming enough of a pet peeve of mine that I should write about it myself and give examples of good vs. bad and why to do it.

Well, the point here is: The reason why you should use it, because of the benefits of CQRS and event-sourcing – and unfortunately, at this point, I think you need to get your feet wet and learn about these concepts ;-)

Maybe https://docs.wolkenkit.io/3.0.0/getting-started/understandin... is a good place to start.

> The reason why you should use it, because of the benefits of CQRS and event-sourcing

So this is the ONLY framework that provides an implememtation of CQRS and event-sourcing? What I was trying to get at is to try to tell me why you're different and better.

None of this is easy. One-liners are very hard to get right. But it's worth the work.

It is the only one (I know of) that provides an all-in-one integrated approach that "just works".

Actually, inspired by your comments, I'm currently sitting at my desk, thinking about how to improve the claim.

I would love to discuss things with you. If you are interested in exchanging ideas as well, feel free to contact me via mail (hello@thenativeweb.io).

I agree with you it's tough to sell CQRS, it's like trying to explain to someone that their business should use a database in one line.

For me event-sourcing is a historical layer below your existing database that allows you to replay the sequence of events that got your database to its current state.

If I had to businessify it, maybe it would be 'Wolkenkit is a framework that allows you to save and replay your entire business's history so you never miss a key insight again.'

From a technical perspective, engineers can focus on the product and organically build and destroy the data structures around a changing business instead of trying to find the perfect data-structures that will inevitably be incorrect as the business grows and evolves. You get regression tests for free, and you get backups for free which may be nice-to-haves when the business is small, but absolute requirements once you have real customers paying real money. Not sure how I would squeeze that in an elevator pitch though.

Greg Young's presentation on event-sourcing is pretty great, you may find some inspiration there:

https://www.youtube.com/watch?v=JHGkaShoyNs

"For me event-sourcing is a historical layer below your existing database that allows you to replay the sequence of events that got your database to its current state."

In other words, a transaction log.

Yeah, that's essentially what it is. For example, you can build event-sourcing by tapping in to the log-shipping facilities that postgresql offers (set wall to logical, and assign a replication slot to it)

A transaction log is too detailed and specific. Typically an event log lists actions from the business domain rather than what got affected. It should explain what happened, not how it happened.

What might also be interesting is https://www.youtube.com/watch?v=rolfJR9ERxo

PS: I like "Wolkenkit is a framework that allows you to save and replay your entire business's history so you never miss a key insight again." :-)

Thanks for the idea!

This was my end goal. A better one liner for you. This one liner works for me as a programmer. And I'd venture to say most business people would get it too.

Great explanations that avoid too much jargon and that I think most developers could understand. Your one-liners and more detailed explanations got me hooked, and I want to know more. This is the right way to do it. Thanks!