4 ms·

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 recog

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

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

tchaffee 8y ago

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.