8 ms·

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 provi

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.

goloroden 8y ago
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.
- tchaffee 8y ago
  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.
  - goloroden 8y ago
    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/understanding-wolkenkit/why-wolkenkit/ https://docs.wolkenkit.io/3.0.0/getting-started/understandin... is a good place to start.
    - tchaffee 8y ago
      > 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.
      - goloroden 8y ago
        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).
- matthewaveryusa 8y ago
  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 https://www.youtube.com/watch?v=JHGkaShoyNs
  - js8 8y ago
    "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.
    - matthewaveryusa 8y ago
      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)
    - atoko 8y ago
      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.
  - goloroden 8y ago
    What might also be interesting is https://www.youtube.com/watch?v=rolfJR9ERxo https://www.youtube.com/watch?v=rolfJR9ERxo
linkmotif 8y ago
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 8y ago
  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 ;-)
  - corn_dog 8y ago
    Even if you know what they are you probably don't have the problem they solve :)
  - linkmotif 8y ago
    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 8y ago
      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 8y ago
        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.
martythemaniak 8y ago
"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 https://martinfowler.com/eaaDev/EventSourcing.html
- tchaffee 8y ago
  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.
blablabla123 8y ago
> 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.
michaelcampbell 8y ago
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.
politician 8y ago
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. ;-)
- tchaffee 8y ago
  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.
kayoone 8y ago
If you don't know what CQRS or event-sourcing is, you probably also have no usecase for this framework.
- sidlls 8y ago
  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.
- specialist 8y ago
  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.
manigandham 8y ago
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?
- vorpalhex 8y ago
  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.
  - manigandham 8y ago
    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.
    - vorpalhex 8y ago
      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.
      - manigandham 8y ago
        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.
- tchaffee 8y ago
  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.
TeMPOraL 8y ago
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.

goloroden 8y ago

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.

tchaffee 8y ago
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.
- goloroden 8y ago
  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/understanding-wolkenkit/why-wolkenkit/ https://docs.wolkenkit.io/3.0.0/getting-started/understandin... is a good place to start.
  - tchaffee 8y ago
    > 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.
    - goloroden 8y ago
      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).
matthewaveryusa 8y ago
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 https://www.youtube.com/watch?v=JHGkaShoyNs
- js8 8y ago
  "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.
  - matthewaveryusa 8y ago
    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)
  - atoko 8y ago
    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.
- goloroden 8y ago
  What might also be interesting is https://www.youtube.com/watch?v=rolfJR9ERxo https://www.youtube.com/watch?v=rolfJR9ERxo

linkmotif 8y ago

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 8y ago
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 ;-)
- corn_dog 8y ago
  Even if you know what they are you probably don't have the problem they solve :)
- linkmotif 8y ago
  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 8y ago
    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 8y ago
      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.

martythemaniak 8y ago

"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 https://martinfowler.com/eaaDev/EventSourcing.html

tchaffee 8y ago
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.

blablabla123 8y ago

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

michaelcampbell 8y ago

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.

politician 8y ago

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

tchaffee 8y ago
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.

kayoone 8y ago

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

sidlls 8y ago
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.
specialist 8y ago
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.

manigandham 8y ago

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?

vorpalhex 8y ago
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.
- manigandham 8y ago
  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.
  - vorpalhex 8y ago
    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.
    - manigandham 8y ago
      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.
tchaffee 8y ago
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.

TeMPOraL 8y ago

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.