Speaker 1: Hey, Welcome to React Round Up, the podcast where we
Speaker 1: keep you updated on all things React related. This show
Speaker 1: is produced by Dpendeves and Onvoid. Topendeves is where you
Speaker 1: create top and Eves. We get top and pay and recognition.
Speaker 1: We're working on interesting problems in making meaningful community contributions
Speaker 1: an Onvoid, which offers remote design and software development services
Speaker 1: on the most client friendly business model, so clients only
Speaker 1: pay after tasks are delivered and true. In today's episode,
Speaker 1: we will be talking all about event searcing and the
Speaker 1: differences between what is considered event surcing in the front end,
Speaker 1: such as using reducts versus event searcing in the back end,
Speaker 1: which is a completely different game. My name is Lucas Paganini.
Speaker 1: Your hosts and the podcast. Joining me in today's episode
Speaker 1: are the also hosts, Chris Fruan, Hello everybody, Peter Ossa,
Speaker 1: Hi Evoon, and our very special guest which was also
Speaker 1: on our last episode of Adventures and Angler, another podcast
Speaker 1: also produced by Onvoid and Top and OUs if you're
Speaker 1: interested in that, which is Louise Galias, the CEO and
Speaker 1: founder of Onoid. Oh good, sorry, dude, I think you've
Speaker 1: got my company by mistake so the CEO and founder
Speaker 1: of Umbar.
Speaker 2: Yeah, we're not doing acquisitions at this time. Sorry. Yeah,
Speaker 2: hi everyone. My name is Louis Galias.
Speaker 3: I'm an engineer, even though i'm the CEO of the company.
Speaker 3: We help companies distribute data uh and do it in
Speaker 3: a way that's very easy and it has great applications
Speaker 3: and events sourcing, which is our current market focus.
Speaker 1: Awesome, awesome. Yes, Louise really is a mastermind behind events searching.
Speaker 1: He actually offers a free online core about event sourcing,
Speaker 1: So for those of you that are interested, you can
Speaker 1: go to mbar dot cloud slash EESC which stands for
Speaker 1: Event Sercing Course. And I met him because I did
Speaker 1: this course and I can vouch for it. It is
Speaker 1: really good. It is really well made, and I learned
Speaker 1: a tom from him, and I just thought, hey, dude,
Speaker 1: let's bring you to the podcast because I'm sure that
Speaker 1: this is going to be beneficial to a lot of developers.
Speaker 1: A lot of people don't have this context of how
Speaker 1: event searcing is done. It a lot of people don't
Speaker 1: even know what event searcing is like in fact and
Speaker 1: applied to the back end. So I think this is
Speaker 1: going to be really relevant for those of you that
Speaker 1: want to know more about the back end side of things.
Speaker 1: So just an FYII, this podcast episode is not going
Speaker 1: to be a lot about REACT, but we're going to
Speaker 1: do a lot of comparisons between event sercing and using
Speaker 1: reducts and all the flux patterns which are very commonly
Speaker 1: used alongwid REACT. But you will see that it's pretty
Speaker 1: different when you're doing that in the back end. All right,
Speaker 1: So Louise, let's start with some concepts. What do you
Speaker 1: think is relevant for us to define to the audience
Speaker 1: before we start talking about the rest of the subject.
Speaker 3: So I think it's a good idea to start with events, right,
Speaker 3: and the inversion that we have in events sourcing and
Speaker 3: similarly in redoucts as well, when you're using this in
Speaker 3: the front end, right, So as opposed to having an
Speaker 3: application where you are tracking state and modifying state in place,
Speaker 3: what you're doing is you're recording events, right, So if
Speaker 3: somebody makes a click, then you react to that event
Speaker 3: by saying, I'm going to modify my state in this way.
Speaker 3: So in this case, the state is really the primary, sorry,
Speaker 3: the secondary part of your application, and your events are
Speaker 3: the primary part.
Speaker 4: And.
Speaker 3: There are similarities in this regard, but there are definitely
Speaker 3: differences because in the front end, your application is very ephemeral. Right,
Speaker 3: if you have a browser window open right now, you
Speaker 3: close it, great, that's it, right, You don't Maybe you
Speaker 3: store some things in local storage, but beyond that everything
Speaker 3: is stored in the server. When you're using this pattern
Speaker 3: in the server, it's much different because now you have
Speaker 3: to think about storing those events and being able to
Speaker 3: build your state and keep track of it. So again
Speaker 3: the concepts to summarize what I've said, right, is that
Speaker 3: it's a similar inversion of the concepts, where now instead
Speaker 3: of having state as your source of truth, your events
Speaker 3: are your sorts of truth, and a state is a derivation.
Speaker 3: But despite those similarities, it's very different because you have
Speaker 3: to track your events in a permanent way as opposed
Speaker 3: to in a e firmeral way where you can do
Speaker 3: it in the front end with a single server, single core,
Speaker 3: single threat of JavaScript running perfect.
Speaker 1: Yeah, so there are like all the complexities that go
Speaker 1: along with dealing with those limitations, right, And okay, so
Speaker 1: Peter Chris, do you guys think there's any fundamentals that
Speaker 1: we should cover before we get into event sourcing. By
Speaker 1: the way, do YouTube feel comfortable with events sourcing any
Speaker 1: particular basic questions about it? We can definitely tackle that now. Yeah.
Speaker 5: So for me, I think the idea, I think I'm
Speaker 5: just trying to create like a parallel or like copy
Speaker 5: and contrasts. Yeah, so I think maybe maybe I may
Speaker 5: want to ask like the question. I think that's probably
Speaker 5: regarding like the principle behind events sourcing, maybe like maybe
Speaker 5: just another view kind of Yeah, I get that, yet
Speaker 5: it's it's at all maybe in the way that maybe
Speaker 5: like Fontain developers will relate to Yeah, I know you
Speaker 5: gave one about widows, but maybe something I don't say
Speaker 5: it's close to low level maybe could but is it
Speaker 5: like an event ball so those is eventv in yeah,
Speaker 5: this kind of concepts.
Speaker 3: Yeah, I.
Speaker 2: Yeah.
Speaker 3: So there are moving parts when you're doing this pattern
Speaker 3: in the back end, right, because when you're doing everything
Speaker 3: in the front and you can just do everything in memory,
Speaker 3: like I was saying, So when you think about how
Speaker 3: you're handling your events and how you're queuing them, when
Speaker 3: you are doing this in the front and right, you
Speaker 3: just have a you know, first in, first out queue
Speaker 3: and you handle messages like that, and then you apply
Speaker 3: them against your state. Right, okay, but how do you
Speaker 3: do that when you actually need them for search of
Speaker 3: that does this?
Speaker 2: There are equivalent parts on the back end.
Speaker 3: So for example, on your queue events that you have
Speaker 3: in the front and.
Speaker 2: You need a similar queue that is.
Speaker 3: More permanent infrastructure on the back end, there are differences
Speaker 3: where they are not quite the same the same things
Speaker 3: on the back end. So for example, in the back
Speaker 3: end you need to you need to store your events permanently, right,
Speaker 3: so you can quite draw the same parallels.
Speaker 2: Now, what I would say is from a benefit perspective, I.
Speaker 3: Think this is where I can draw the most parallels
Speaker 3: that when you have to reason about how your application
Speaker 3: is changing, it's easier to reason about the delta themselves
Speaker 3: than the state as a whole.
Speaker 2: So when you can isolate, hey, I'm only changing this
Speaker 2: one particular thing and it's going to affect my state.
Speaker 3: In this particularly defined way. Where your functions are essentially
Speaker 3: pure functions. Right, you have your state input, you have
Speaker 3: a state output, and then you have a pure function.
Speaker 3: That is, for me, state input is to state output
Speaker 3: with the delta. And this process of take going from
Speaker 3: state transitions from one to another and using that delta
Speaker 3: as the primary player in your system. This is what
Speaker 3: eventsourcing is all about, instead of focusing on the state
Speaker 3: as a whole and having this kind of weird thing
Speaker 3: where you have a giant function that is trying to
Speaker 3: do all sorts of crazy things and having all sorts
Speaker 3: of different case switch statements of you know, maybe.
Speaker 2: I want to do this, maybe I want to do that,
Speaker 2: maybe I want to use the service or the combination
Speaker 2: of the thing.
Speaker 3: No, just think about everything as a pure function where
Speaker 3: you have state input, state output and some delta in
Speaker 3: between and a function that is going to help because
Speaker 3: from that delta into the state input to state output transition.
Speaker 5: I think I think that's I think that's way much.
Speaker 5: So it's more like from what you describe, it's more
Speaker 5: like it's more like a permanent more like you permanent
Speaker 5: like we of like constantly getting like information that you
Speaker 5: may kind of put in your states. So it's just
Speaker 5: like I really say, is it this obviously like it's
Speaker 5: moll stop kind of right? Does it seem like that?
Speaker 1: Yeah?
Speaker 5: All right, all right, I think that makes sense. Yeah, yeah, Chris,
Speaker 5: do you have a new question on that? Bybe to
Speaker 5: create like parallel with that sound like you wanted.
Speaker 4: Yeah, I was laughing a bit back there when when
Speaker 4: Lucas mentioned there's people who probably don't even know what
Speaker 4: event sourcing is, and maybe one of those. So now
Speaker 4: I guess to not like just to be a total
Speaker 4: new but but maybe to relate to to kind of
Speaker 4: the front end and things like that. I guess the
Speaker 4: only the only thing like the buzzword I think of,
Speaker 4: but it's maybe not the exact same thing is I
Speaker 4: know there's these like these event I'm not even sure
Speaker 4: what they called, like event databases, but I feel like
Speaker 4: what you're doing is even more generalized then you don't.
Speaker 4: It may be just the architecture itself and you maybe
Speaker 4: don't need like a database and all this event driven thing.
Speaker 4: But but maybe what we could touch on a few
Speaker 4: times throughout the podcast is is like how it relates
Speaker 4: to the front end. I what I do know with
Speaker 4: the whole flux thing and the event event sourcing, why
Speaker 4: really it was made is kind of what you mentioned already.
Speaker 4: There's a great talk. Maybe I'll look it up and
Speaker 4: post it at the end of the show, but from
Speaker 4: why Facebook kind of came up with this and They
Speaker 4: probably didn't. They weren't the ones who invented it. But
Speaker 4: there when they were working on their chat, they had
Speaker 4: all these you know, a chat is super like state intensive.
Speaker 4: You have how many messages, you're are unread, number of people,
Speaker 4: all the stuff. And they found you know, doing it
Speaker 4: like without pure functions, without without event sourcing. Every time
Speaker 4: they tried to add a new feature, they would get
Speaker 4: regressions elsewhere in the state. But yeah, that's that's my
Speaker 4: to my extent of what I know about event sourcing,
Speaker 4: and and yeah, I don't know, I'm just kind of
Speaker 4: rambling on. Probably reflects how how little I know about this.
Speaker 3: No, but that's I think that's pretty much in line
Speaker 3: with the proposition of.
Speaker 2: It, right, because there is a there is a payment
Speaker 2: that you have to do.
Speaker 3: You have to pay the piper upfront, right, You have
Speaker 3: to put in some work to understand these concepts and
Speaker 3: get the infrastructure in place. I mean, if you think
Speaker 3: about it from the fronto perspective, right, imagine that you're
Speaker 3: transitioning from you know, some application that was built with
Speaker 3: pure HTML and some jQuery and it's you know, this
Speaker 3: giant monolith like mass, right, and then you say to
Speaker 3: the team, Hey, you know what, let's move this to
Speaker 3: a single page.
Speaker 2: Application based on reacting redox. Right. If you're doing that,
Speaker 2: you're going to have to pay some cost up front.
Speaker 2: You're going to have to.
Speaker 3: Educate people or get people that are already educated, and
Speaker 3: you're going to have to have some guardrails in some
Speaker 3: libraries and some abstractions that are going to help you
Speaker 3: deploy this.
Speaker 2: It's not something that you're going to do overnight.
Speaker 3: So the proposition with event sourcing, though, is that once
Speaker 3: you have paid that cost that you go. You essentially
Speaker 3: go slow at first, to go fast later at a
Speaker 3: sustainable rate where you're not eventually going to hit a wall.
Speaker 2: Because with these big applications where.
Speaker 3: You have a ball of a band aid on top
Speaker 3: of a ball of band aid, you essentially hit a
Speaker 3: wall at some point where you get so many regressions
Speaker 3: that you cannot develop anything. You have diminishing returns every
Speaker 3: time you ad a feature. So the proposition with event
Speaker 3: sourcing is that similarly, you have a cost to pay upfront,
Speaker 3: but with the benefit that after you've paid that cost,
Speaker 3: you'll be able to go very quickly because the system
Speaker 3: is easy to reason about. Despite the system growing disproportionately
Speaker 3: in the number of features.
Speaker 1: Now, how is that actually done in prect to this,
Speaker 1: because like interurity, this sounds great, This sounds like this
Speaker 1: will solve a lot of the complexities that big code
Speaker 1: bases have, which I think most of us know how
Speaker 1: that goes. Like most of us have work in a
Speaker 1: big co base, and despite all the good intentions of
Speaker 1: everyone of keeping the code organized, is just natural for
Speaker 1: things to get outdated because there are new patterns and
Speaker 1: you don't always come back to reflector the entire thing,
Speaker 1: and then you start getting parts that are considered legacy. Right,
Speaker 1: How in practice does what you were saying would work
Speaker 1: to avoid this complexity building up over time.
Speaker 3: So that's a great question because the reality of it,
Speaker 3: like with anything right, is that you get these promises
Speaker 3: and you have to know how these are going to
Speaker 3: come true.
Speaker 2: If they can come true in the first place.
Speaker 3: So firstly, I would highlight that, you know, I mean,
Speaker 3: I'm an engineer, I'm all about trade offs. I don't
Speaker 3: just preach and you know say you know this is
Speaker 3: going to be a silver bullet.
Speaker 2: There are no such things in engineering. Everybody who with
Speaker 2: some degree.
Speaker 3: Of experience knows that But that being said, when if
Speaker 3: you truly want to.
Speaker 2: Walk to the promised land, there are two aspects that
Speaker 2: you have to cover.
Speaker 3: One is a technical aspect, where you have your infrastructure
Speaker 3: and you have to know how to deploy that, how
Speaker 3: to set up your ci how to set up the
Speaker 3: different components that you need, like a place to store
Speaker 3: your events, a way to hew your events, a way
Speaker 3: to process your events, a way to react to your events,
Speaker 3: and you have to know how you're going to do
Speaker 3: that and make a plan for it. And second of all,
Speaker 3: it's the people aspect where you have to imboard people,
Speaker 3: introduce new way of thinking, perhaps on learn some of
Speaker 3: the patterns that they've been using. Everybody loves doing this
Speaker 3: great read of the delete kind of application because it's simple.
Speaker 3: There are a ton of frameworks like rails in Ruby.
Speaker 3: You know, you have frameworks in JavaScript as well. You
Speaker 3: have frameworks in PhD like Symphony and Larval that just
Speaker 3: help you do this great readup of the delete right.
Speaker 3: But if you're changing your way of thinking into thinking
Speaker 3: about the delta, doesn't thinking in pure functions. You need
Speaker 3: new obstructions and it's not just the technical implementation of
Speaker 3: those abtractions it's the convincing the people right, and luckily
Speaker 3: with events sourcing, once you do you know a modicum
Speaker 3: of training, you know, maybe two three weeks where you
Speaker 3: put in some serious time into studying it, you can
Speaker 3: get quite good. And assuming that you've set up the infrastructure,
Speaker 3: and if you've done that, and you do it with
Speaker 3: an initial part of your system, so you don't move
Speaker 3: everything at once.
Speaker 2: Of course, you don't do a big binary right, you move.
Speaker 3: A specific part of your system, and then once you're done,
Speaker 3: you'll be in a position where you.
Speaker 2: Turned your team to use events sourcing.
Speaker 3: You have moved a part of your system to eventsurcing
Speaker 3: because you thought it would deliver some business value, and
Speaker 3: hopefully you've set up the technical infrastructure concerns as well.
Speaker 3: Depending on how much you want to implement yourself, you
Speaker 3: can go from deploying things as quickly as you know,
Speaker 3: two to three weeks in terms of the infrastructure, plus
Speaker 3: pseudo three weeks in terms of training yourself and developing
Speaker 3: the first couple of features, to going over a year
Speaker 3: or two years if you really want to do everything
Speaker 3: from the ground up right. So, for example, when it
Speaker 3: comes to the infrastructure, you can build your own events store,
Speaker 3: and I know people that have actually interacted with the
Speaker 3: file system built the whole entire library to address the
Speaker 3: concern of the events store, and then they have to
Speaker 3: add in all these features like indexing, which if you
Speaker 3: just wrapped a traditional database you could get it essentially
Speaker 3: almost for free. Right when it comes to queuing systems,
Speaker 3: there are people that implement their own queuing systems.
Speaker 2: They use things like Rabin and Q and they customize
Speaker 2: on top of it, and there are abstractions out there.
Speaker 3: There's a range of obstructions and different sides of the
Speaker 3: spectrum in terms of how much you need to know. We,
Speaker 3: of course at Amber, we make it essentially as easy.
Speaker 3: We're on one side of the spectrum. It's as easy
Speaker 3: as it gets, right, but of course that comes at
Speaker 3: a cost where you have to pay for it.
Speaker 2: Right, But the.
Speaker 3: More you are comfortable with using the existing tooling, that's
Speaker 3: how they're like using posters, using my sequel, or using ambar,
Speaker 3: or using technologies to deploy web servers like cloud run
Speaker 3: or far Gate and not complicating your life, you know,
Speaker 3: doing your own Kubernetes deployment. If you just do it
Speaker 3: the simplest, the simplest way, and using system cooling, you
Speaker 3: can get set up in about a month and a
Speaker 3: half including technical time and training time.
Speaker 2: And I think that's quite and I've.
Speaker 3: Seen that in practice, and I think that's quite impressive
Speaker 3: for something where you need to flip everything. But people like,
Speaker 3: because we're engineers, we fall into the trap of, you know,
Speaker 3: I need to understand absolutely everything.
Speaker 2: We don't do this.
Speaker 3: If we're implementing a file storage, right, we don't need
Speaker 3: to understand how S three works.
Speaker 2: We just use it.
Speaker 3: So I would my general advice, after giving you the
Speaker 3: details of how to go about it, is pick your
Speaker 3: battles in what you need to learn, and learn the
Speaker 3: things that are going to make a difference for you
Speaker 3: as a business, not the things that are just you know,
Speaker 3: problems that are already sold.
Speaker 1: Okay, that's that does make sense. It is still a
Speaker 1: bit scary, but I think I agree with you, like
Speaker 1: we allow so many abstractions, especially JavaScript developers. We are
Speaker 1: so used to frameworks. There are just layers on top
Speaker 1: of layers and layers and layers of abstraction, and for
Speaker 1: some reason I still find it a bit weird to
Speaker 1: abstract and events fersaal layer. But I think this is
Speaker 1: more about the fact that I don't feel as comfortable
Speaker 1: with it doing natively to be okay with an abstraction,
Speaker 1: almost like I first wanted to understand the fundamentals of
Speaker 1: front end development before I went into frameworks that would
Speaker 1: abstract that way, so that I have the knowledge of
Speaker 1: what's going on under the hood. But you're also correct
Speaker 1: in the sense that I use mongo deb without knowing
Speaker 1: how it actually stores the data. I just use it.
Speaker 1: It almost feels like MongoDB is the lowest level, but
Speaker 1: it's not. It's like still a high level abstraction. Sequel
Speaker 1: is still a high level abstraction within how the data
Speaker 1: is actually stored and retrieved internally in the SQL database.
Speaker 1: So I think you touched on a good point from
Speaker 1: your experience dealing with people that are starting out with
Speaker 1: events sourcing. Is it also very common to have people
Speaker 1: that fear this abstraction layer and why do you think
Speaker 1: that is the case versus other abstractions that already exist
Speaker 1: and people are comfortable with. I think graph ql can
Speaker 1: be a good analogy because in a way, people are
Speaker 1: very comfortable with just creating rest API routes and just
Speaker 1: doing it, but express it. Although express is an abstraction,
Speaker 1: it does feel low level enough. I know that somebody
Speaker 1: is gonna hate on me because saying low level for
Speaker 1: something like express as whatever, but it does feel because
Speaker 1: you have a lot of control over how the handlers
Speaker 1: are being created versus if you're using an abstraction on
Speaker 1: top of Graphql. There are some very very opinionated ones,
Speaker 1: like a pole server being maybe one of the most
Speaker 1: opinionated ones. So maybe event sourcing can be compared to it,
Speaker 1: like events and abstractions in the back end could be
Speaker 1: compared to Graphql abstractions in the sense that you want
Speaker 1: to know how it's working under the hood, but at
Speaker 1: the same time, why do you need it? You know?
Speaker 2: Yeah, I think so.
Speaker 3: I mean it as everything, there's new ones always right,
Speaker 3: and I think it's a fair fair thing to call
Speaker 3: out graphql.
Speaker 2: Because yeah, you know, people like to understand it two
Speaker 2: different degrees.
Speaker 3: I would point out that in general, where I see
Speaker 3: people that are most excited about events sourcing and that
Speaker 3: spend the most.
Speaker 2: Time in learning it are people that are.
Speaker 3: Closer to the beginning of their careers, because it seems like,
Speaker 3: oh my gosh, there's so much technical content here. Right,
Speaker 3: some subjects you can only go so far before it
Speaker 3: starts feeling a little bit too abstract.
Speaker 2: There's too much.
Speaker 3: Mathematics and it so it's maybe a bit discouraging, Whereas
Speaker 3: event sourcing is quite rich in that there's a lot
Speaker 3: to learn, especially because today, and it's something we're trying
Speaker 3: to solve with our free course today. Learning events sourcing
Speaker 3: still feels like going to that planet that Luke Skywalker
Speaker 3: goes to in Star Wars to find Master Yoda, where it's,
Speaker 3: oh my gosh, I'm going to go and find some hermit.
Speaker 2: That's going to teach me all about this stuff.
Speaker 3: And that feels exciting, right because it feels quite unique,
Speaker 3: and I think that's the reason that people are wanting to,
Speaker 3: you know, dive deeper into it. But you know, I mean,
Speaker 3: I've been around for a bit and I can tell
Speaker 3: you that the most successful engineers that I know have
Speaker 3: all always known how to balance that out right, understand
Speaker 3: just enough and perhaps a little bit more to be
Speaker 3: able to judge that you know just enough so that
Speaker 3: you can then build something for your business, right, and
Speaker 3: you keep both of those in check. You obviously don't
Speaker 3: want to accrue too much technical debt, but at the
Speaker 3: same time you don't want to crue too much business.
Speaker 3: Then it's something that we talk about very little, right,
Speaker 3: Like what about there's technical that's sure, but there's business
Speaker 3: that as well, right where you're spending some time implementing
Speaker 3: some technical things that are pretty great, but at the
Speaker 3: cost of slowing down in the business, right, So you
Speaker 3: need to balance both of them now, And I would
Speaker 3: say that the engineers who will be the most successful
Speaker 3: of event sourcing are the ones that can make the
Speaker 3: distinction and understand that they need to get a little
Speaker 3: bit of both. Now, in the sense of the comparison
Speaker 3: to graph you out, I think something similar happens there
Speaker 3: right where there are engineers that understand how the how
Speaker 3: the runtime engine works and understand that and use it
Speaker 3: to for the better of their applications.
Speaker 2: But maybe you don't need.
Speaker 3: Right like maybe you need to understand it just to
Speaker 3: a degree, or maybe you only need one person in
Speaker 3: your team to understand that.
Speaker 2: Right.
Speaker 3: So there are parallels there, I'd say, And I would
Speaker 3: suggest with event sourcing to learn more about the parts
Speaker 3: that are relevant to the business and not the parts
Speaker 3: that are implementation details for which there are plenty of things,
Speaker 3: plenty of resources out there that could help you implement it.
Speaker 3: My recommendation is that maybe you get one person on
Speaker 3: your team to understand that very deeply and guide the
Speaker 3: rest of.
Speaker 2: It the team, but the rest of the team should
Speaker 2: just understand the.
Speaker 3: Business concepts and core building blocks from a coding perspective.
Speaker 1: Yeah, that does make it a lot of sense. Okay,
Speaker 1: let's talk a little bit more about the possible abstractions
Speaker 1: that exist to simplify the lives of people that are
Speaker 1: getting into events servicing. Of course, there's unbar right, and
Speaker 1: it solves a lot of a lot of problems. But
Speaker 1: besides that, and I think we can also talk a
Speaker 1: little bit more about that, like which exact problems this
Speaker 1: umbar would solve versus how you would do it work
Speaker 1: without it, But also are there other abstractions that you
Speaker 1: would recommend? And keep in mind that for people that
Speaker 1: are doing React on the front end, they are most usually,
Speaker 1: not always, but most usually also doing no JS in
Speaker 1: the back end. That is definitely the most popular stack
Speaker 1: for those for front end developers, So do you recommend
Speaker 1: any frameworks or libraries for those running no JASS in
Speaker 1: the back end? That would allow them to more quickly
Speaker 1: jumpstart an event sourcing back end.
Speaker 3: So I know that there are some frameworks that abstract
Speaker 3: events sourcing as a whole right, but unfortunately they can
Speaker 3: be quite opinionated and restrict you. What I would say
Speaker 3: that you should go and grab from a framework, and
Speaker 3: it doesn't necessarily have to be a framework for typescript,
Speaker 3: you can grab it from essentially any framework is the
Speaker 3: schema that you need for your event store, and you
Speaker 3: can either do something very similar to the schema that
Speaker 3: specialized events sourcing database like events for deb or axnic do,
Speaker 3: or you can go and look at certain really great
Speaker 3: libraries like message TV for example, UH or there's a
Speaker 3: proof in pH B, there's h events stalls, there is
Speaker 3: ecotne UH, and there's there are quite a few libraries
Speaker 3: that at least give you the schema and give you
Speaker 3: the patterns that you need. Beyond that, you don't need
Speaker 3: very much. Everything in events sourceing intends to be just
Speaker 3: a UH you know, implementing the same for patterns, or
Speaker 3: you're writing, reading, UH, processing or reacting with other events,
Speaker 3: and you don't really need.
Speaker 2: A framework for that.
Speaker 3: So what I say is the most important thing is
Speaker 3: just grabbing the schema uh and making that correct for
Speaker 3: the place where you're storing your events, and use a
Speaker 3: you know, pick up, pick a good good database, right,
Speaker 3: don't implement your own events or yourself. Just pick postcrists,
Speaker 3: pick my sequel, pick SQL server in jascript is probably
Speaker 3: very unlikely to pick seckl server maybe if you're doing
Speaker 3: dot net. But yeah, you can also pick no sequel
Speaker 3: events stores. I generally don't recommend those because they are
Speaker 3: a little bit harder to maintain.
Speaker 2: I recommend that.
Speaker 3: On the other side, when you're processing your events, you
Speaker 3: can also pick an event stor like AXNIC or events
Speaker 3: or dB that specialize in event sourcing.
Speaker 2: But the problem that is that sometimes you might.
Speaker 3: Want to have some cheat codes and they limit the
Speaker 3: functionality of the set of things that you can do.
Speaker 2: So if you ask me for.
Speaker 3: You know, as you know, classic stack, how I would
Speaker 3: do it today. I would just go and look at
Speaker 3: a schema and from one of these big libraries. I
Speaker 3: would use something like post christ to commit my events.
Speaker 3: I would use something like Ambar to do my messaging.
Speaker 3: And I would use Dynamo dB or COSMOSDB or whatever
Speaker 3: or Mongo DEB whatever.
Speaker 2: No sequel flavor you want for your processing.
Speaker 3: Because something key that I don't think I quite mentioned
Speaker 3: is that in events stressying, right, you need to build
Speaker 3: your state. In that state, you might need to rebuild it.
Speaker 2: So imagine and if you in your.
Speaker 3: In your application in the front end, I asked you
Speaker 3: take all the historical events and build the state from
Speaker 3: scratch and apply all those fear functions again and again
Speaker 3: and again and again. The place where you're depositing and
Speaker 3: storing that state needs to be very scalable. And but
Speaker 3: it doesn't need to have some consistency guarantees that you
Speaker 3: would need on your writing because you don't need You
Speaker 3: simply don't need those.
Speaker 2: So the easiest thing to do is just to use
Speaker 2: a no SQL database on that other end.
Speaker 3: So again, to summarize, take a nice schema by looking
Speaker 3: at the great libraries that are out there.
Speaker 2: You can just look them up.
Speaker 3: And I think stars of GitHub is a is a decent,
Speaker 3: decent heuristic. Pick Postcris, pick Amber or system that does
Speaker 3: something like Umbar if you take our course will tell
Speaker 3: you how to implement it yourself, and then pick Dynamo
Speaker 3: deb for your read model storage.
Speaker 1: Okay, perfect. I think this is a pretty good for
Speaker 1: people that want to start and try it out. What
Speaker 1: about you, Peter creates any specific questions this far?
Speaker 5: Yeah, no really, I think it is kind of will
Speaker 5: explain actually the uses the use kiss on then like
Speaker 5: also advice on when to use it, on how to
Speaker 5: use it. I think that was kind of core.
Speaker 2: Yeah, that's fair. So I'd say that you need to
Speaker 2: so in our.
Speaker 3: Course we cover the pros and cons right, and we
Speaker 3: cover benefits and drawbacks and when it's a good idea
Speaker 3: to use it. If your application is going to be
Speaker 3: changing very often, so if your requirements change all the time.
Speaker 2: Consider eventsurcing.
Speaker 3: If your application has a process driven feature set, so
Speaker 3: you know you're handling money and your state is changing
Speaker 3: all the time, you're shipping items.
Speaker 2: You need to track where things are.
Speaker 3: Consider event sourcing if you need to have auditability just
Speaker 3: by design, so if you're financial services, event surcing is
Speaker 3: almost a requirement.
Speaker 2: You need to have some sort of leisure, like when
Speaker 2: you're doing accounting.
Speaker 4: And.
Speaker 3: If you think that you need to have a capability
Speaker 3: to debug more easily and you want that speed.
Speaker 2: If all of those things line up, then events sourcing
Speaker 2: is for you. However, there are some drawbacks. The community
Speaker 2: is small, so you don't.
Speaker 3: Have a lot of help if you want to get
Speaker 3: people to actually collaborate with you so they answer your questions.
Speaker 2: It's not like every it's not like react or.
Speaker 3: The community is very small, So I recommend that you
Speaker 3: know that upfront and that you educate yourself. But if
Speaker 3: you can get past that initial cost of education and
Speaker 3: a little bit of infrastructure setup, and you have a
Speaker 3: changing application, you have auditability requirements, or you have a
Speaker 3: very complex feature set that is very process driven, then
Speaker 3: consider event sourcing. But as with everything, the devil's and
Speaker 3: details and you should use critical thinking.
Speaker 2: Now, as for how to.
Speaker 3: Do it well, the recommendation would be talk to people
Speaker 3: that have done it before.
Speaker 5: Yeah, that's that's for size grouds. That's weird. Do you
Speaker 5: have any question as well?
Speaker 4: Yeah, Louis who basically kind of answered my question already
Speaker 4: now I was going to ask. So we talked about
Speaker 4: kind of how it can event sourcing can kind of
Speaker 4: simplify or at least make it easier for your organization
Speaker 4: to reduce regressions or over complex functions, and then you
Speaker 4: kind of I was thinking that, of course, auditing is
Speaker 4: naturally easier you have you have an event for everything
Speaker 4: that happens. Are there any other I guess like easy
Speaker 4: wins or advantages you could mention that you can think
Speaker 4: of with event sourcing versus something like the traditional monolith
Speaker 4: crud application.
Speaker 3: Yeah. So it helps you decouple things as well, and
Speaker 3: it helps you read, so it helps you reason about things, right,
Speaker 3: it helps you decouple.
Speaker 2: Your teams, and it just really.
Speaker 3: It really as an organization, right when you're a certain size,
Speaker 3: it means that you don't have to bother other people.
Speaker 3: So it's not only about the capability that you have
Speaker 3: to reason about it just yourself, but also the capability
Speaker 3: that you have to reason about it independently from others.
Speaker 1: Awesome. Yeah, Okay, of course, guys, we only really touch
Speaker 1: the surface. There is a lot more that we could
Speaker 1: talk about in terms of event sourcing, especially like how
Speaker 1: to scale it, and like the common structures that companies
Speaker 1: like big companies use to scale their their distributed systems,
Speaker 1: and also some of the other drawbacks of distributed systems,
Speaker 1: like the fact that you don't get consistency immediately, so
Speaker 1: it might take a little while for the entire system
Speaker 1: to process the request. So once you Right now, we
Speaker 1: are very used to making a post request and then
Speaker 1: making a gut right immediately after that and expecting the
Speaker 1: data to be there because we just made a post request.
Speaker 1: With distributed systems, that might not be the case, at
Speaker 1: least immediately, because you basically send the event and it
Speaker 1: takes a while for everything to process that event and
Speaker 1: update the read layers so that the data is actually
Speaker 1: there for you to retrieve. So there are definitely some
Speaker 1: some other complexities that go with that go with this approach,
Speaker 1: but there's also a lot of scalability benefits as well,
Speaker 1: and we didn't even touched on that yet, but I
Speaker 1: wanted to know if this is a subject that you
Speaker 1: guys think we can we can briefly touch upon before
Speaker 1: wrapping up, because I'm also looking at the time and
Speaker 1: I don't want to make this too extensive for the audience,
Speaker 1: but perhaps we could at least touch upon that, just
Speaker 1: so that people are aware of the drawbacks of going
Speaker 1: in that route.
Speaker 3: So let me perhaps at least get the party started
Speaker 3: and try to be succinct and short and sweet with it.
Speaker 3: So with events or thing you are picking where your scalability, how.
Speaker 2: To implement your scalability.
Speaker 3: So if you think about scalability, right, if you need
Speaker 3: to do things in parallel, you cannot do it in
Speaker 3: such a way. Parallel is the opposite of sequential, right.
Speaker 3: So if you're doing you know, the hash of a
Speaker 3: hash of a hash of a hash of a hash
Speaker 3: of a hash, well, you need the results in order
Speaker 3: to be able to calculate the next hash, right, and
Speaker 3: so on and so forth. So if you are just
Speaker 3: doing an eternal hash of the same thing, you can't
Speaker 3: really scale them, right, because it's just the same I
Speaker 3: think that you have to do in a single thread.
Speaker 2: Now, in events sorting, you're essentially picking.
Speaker 3: Where those boundaries are, right, and you say, you know
Speaker 3: what I have.
Speaker 2: I'm going to simplify it and just call it an.
Speaker 3: Entity, but you specify where those scalability boundaries are.
Speaker 2: So, for example, you say, you know what, I'm going.
Speaker 3: To process all the events for a user profile, not
Speaker 3: just for a user for a user profile, just in
Speaker 3: the same stream. I'm going to process all the events
Speaker 3: for a certain dispatchment from the warehouse, all in the
Speaker 3: same stream. I'm going to process a bank account all
Speaker 3: in the same stream. Or maybe I don't want to
Speaker 3: process the bank account in the same stream. Maybe what
Speaker 3: I want to do is process all the events for
Speaker 3: the same account cycle for the month in the same stream.
Speaker 3: And it essentially makes you think from the get go
Speaker 3: of where those boundaries lie, so that you can know
Speaker 3: where you can paralyze the work and which events will
Speaker 3: be a synchronous and which ones will be asynchronous. So
Speaker 3: if you have something that's happening side the same user profile,
Speaker 3: for example, you might have some validation rules that allow
Speaker 3: you to say, hey, I can only you know, become
Speaker 3: a I can only add a secondary email if I
Speaker 3: verified my first or for example, that's you know, a
Speaker 3: simple validation rule that you could do transactionally. Now you
Speaker 3: cannot quite do a validation against, you know, something that
Speaker 3: is not in that same stream of events and an
Speaker 3: events sorting. You essentially are asked from the get go
Speaker 3: think about where your boundaries are so that.
Speaker 2: If you do need to scale your system, you have
Speaker 2: already built it.
Speaker 3: Build your system in such a way that you recognize
Speaker 3: what's asynchronous and comes from other streams, and it is
Speaker 3: synchronous and comes from the same stream.
Speaker 1: Yep, that's a that's a very very succent way to
Speaker 1: put it definitely a lot of This also opens up
Speaker 1: a lot of other questions. But again, if anyone wants
Speaker 1: to dive do g onto that, they can just sign
Speaker 1: up for the free course that Umbar offers. So just
Speaker 1: go to Umbar dot cloud slash e s C for
Speaker 1: which stands for Events Sourcing Course and then you can
Speaker 1: sign up for a free course so long as it's
Speaker 1: remaining free. So definitely don't don't take too long to
Speaker 1: do it because as I said before, I do think
Speaker 1: that Louis should start charting for that, so make sure
Speaker 1: you do it well. He's still doing it for free
Speaker 1: because there's a ton of value pack onto that, all right,
Speaker 1: So I think that for me, maybe we can start
Speaker 1: wrapping it up. And before I do so, Chris Peter,
Speaker 1: do you guys are good? Do you want to make
Speaker 1: any any last questions on this subject?
Speaker 5: Yeah, I'm good, I think he answered. Yeah, Louis answered
Speaker 5: every question perfectly.
Speaker 2: Yeah, that was good.
Speaker 4: On one last question, maybe it's not even applicable. How
Speaker 4: how do you look at or yeah? Is it even
Speaker 4: a consideration when you have a sort of migration, right,
Speaker 4: so you have your entity. I don't know I have
Speaker 4: first first name in last name. Let's say I have
Speaker 4: middle name. Now is that just become a new event
Speaker 4: or are there different strategies or or how does that
Speaker 4: look in event sourcing?
Speaker 3: So it forces you to recognize this right away, right
Speaker 3: because in.
Speaker 2: Traditional applications, what do you do?
Speaker 3: You add a column to the database and you leave
Speaker 3: it empty, right, and you make it knowable and very interesting.
Speaker 3: It's something simple where something similar, sorry, where you have
Speaker 3: to now reason about, well, what does my current state
Speaker 3: look like if I have never had a middle name event.
Speaker 3: So what you would traditionally do is you would add
Speaker 3: new event altogether where in your sign of.
Speaker 2: Maybe you require that middle name.
Speaker 3: And if if you can now see that there will
Speaker 3: be times where you have this new sign up version
Speaker 3: and times where a user hasn't done that sign of verse.
Speaker 3: But you immediately recognize and you can see in your
Speaker 3: in your pure functions again that you can go from
Speaker 3: a state of having no middle name to a state
Speaker 3: of having a middle name.
Speaker 2: Maybe you can delete.
Speaker 3: Your middle name as well, but you have to recognize
Speaker 3: that because you haven't only had events that can create
Speaker 3: a user profile with a middle name. You have to
Speaker 3: recognize in those functions that you could create a user
Speaker 3: that doesn't have a middle name, And it's that explicitness
Speaker 3: that forces you to think about your application. And if
Speaker 3: you're now asking about the way that I would implement it,
Speaker 3: if I would to do a migration, I would do
Speaker 3: a new event right that that includes this middle name,
Speaker 3: and then I would have to go then go and
Speaker 3: handle modify my pure functions that allow me to determine
Speaker 3: the new state. If the question were to come more
Speaker 3: from how would I migrate from out of event sourcing
Speaker 3: into events sourcing?
Speaker 2: Normally you go through a migration path.
Speaker 3: Where you say, Okay, I have these entities and I'm
Speaker 3: gonna on board them, right, so you would have something
Speaker 3: like the first event ever, something.
Speaker 2: Like onboarded user profile or.
Speaker 3: Something like that, or imported it or whatever it is,
Speaker 3: and then you would slowly build those events for the
Speaker 3: rest of your system and migrate your application slowly, slowly
Speaker 3: into event sourcing. But it's actually more common to not
Speaker 3: start out with an old feature but to start with
Speaker 3: a new feature, because then you can reap the benefits
Speaker 3: right away.
Speaker 1: All right, all right, awesome, So before we wrap things up,
Speaker 1: let's just do a quick round of promos. Louise, do
Speaker 1: you want to do you want to start?
Speaker 2: Sure? So yeah. My name is Louis. I'm founder and
Speaker 2: CEO of Ambar.
Speaker 3: We are a data streaming company focused particularly on architectures
Speaker 3: like event sourcing.
Speaker 2: We are offering a free course before we sell you anything,
Speaker 2: we like to provide you with a law of value.
Speaker 3: So if you go to Ambar, which is a m
Speaker 3: b R dot cloud slash e SC, you can take
Speaker 3: our free events sourcing course. I will hope that it
Speaker 3: can remain free for as long as possible. And it's intense.
Speaker 3: It's about a week worth of time. It's not you know,
Speaker 3: it's especially three hours a day that you should expect
Speaker 3: to invest. But you should come out of it very
Speaker 3: confident that you know you can do it in production.
Speaker 2: And if you don't feel confident.
Speaker 3: Anyway, we are there in a SLA community as well
Speaker 3: to help you out anyway. Again, that's Ambar, a m
Speaker 3: b A R dot cloud slash esc awesome.
Speaker 1: Thank you. I also sent it in the comments section
Speaker 1: for those of you that are listening from YouTube or
Speaker 1: any other streaming platforms. Peter, how about you? Okay?
Speaker 5: Yeah, for the I don't have any I think yeah
Speaker 5: all right?
Speaker 4: And Chris, yeah, I'll just post that the YouTube video
Speaker 4: of the Facebook talk I mentioned. If you search YouTube,
Speaker 4: that's the title here. I think rethinking web app development
Speaker 4: at Facebook, And yeah, it talks about what I mentioned,
Speaker 4: how they ran into a bunch of problems with their
Speaker 4: chat and then they kind of evolved into this basically
Speaker 4: event sourcing methodology.
Speaker 1: So it's quite interesting. Awesome, awesome. Yeah, it does help
Speaker 1: a lot to see use cases from big companies. For
Speaker 1: any of you that want to know which companies are
Speaker 1: doing distributed systems, you can just look on YouTube or
Speaker 1: Google and you will see that actually most of the
Speaker 1: big ones are doing it, because once you get to
Speaker 1: a level where you need to serve billions of requests,
Speaker 1: then there aren't really many other choices besides doing that.
Speaker 1: I mean, at least not until we hit reliable quantum computing.
Speaker 1: But until then, I think we're actually going to need
Speaker 1: a lot of distributed systems in order to scale to
Speaker 1: the size that those big companies are scaling too. So
Speaker 1: you can be sure that for example, Twitter or Instagram,
Speaker 1: they are running distributed systems to be able to serve
Speaker 1: users in the scale that they are serving. So yeah,
Speaker 1: it is definitely really interesting to learn about that. I also,
Speaker 1: just to wrap things up, also want to say that
Speaker 1: once I first learned about event searcing and CQRS, which
Speaker 1: is a pattern that it's basically a pattern on top
Speaker 1: of events searching, I really thought, Okay, this is the
Speaker 1: Holy grill, and I need to stop all that I'm
Speaker 1: doing and from now on I have to write every
Speaker 1: back end this way. And I just want to let
Speaker 1: you all know that you also don't need to go
Speaker 1: that bath. So it is really beautiful. It is really
Speaker 1: amazing and scalable and very flexible, but you also can't
Speaker 1: keep doing things the way that you're doing. Just know
Speaker 1: that once you start really worrying about the scale of
Speaker 1: your application in a big way, and you also have
Speaker 1: the auditability concerns that Louis was mentioning, like you need
Speaker 1: to have this track record of everything that is happening
Speaker 1: in the application, then this is a really excellent solution.
Speaker 1: But you don't need to already start with it on
Speaker 1: your next hobby project, but do definitely study more about it.
Speaker 1: Be aware of this pattern so that once you feel
Speaker 1: that it is the right pattern to apply for a
Speaker 1: given project, then you already know that it exists and
Speaker 1: how you can apply it, all right, So that's going
Speaker 1: to be it for me. I'm going to promote onvoid
Speaker 1: dot com. It is my company as well, so I
Speaker 1: am a bit biased to say it, but from experience
Speaker 1: to talking to our clients, they always say that we
Speaker 1: really are different from everything that they have found in
Speaker 1: the market thus far. So if you're interested in a
Speaker 1: very client friendly business model for companies that are looking
Speaker 1: for design services or software development services, especially front end development,
Speaker 1: which is what we do really really well with Angular
Speaker 1: and width React, definitely check out onvoid dot com. It's
Speaker 1: you and voib dot com. All right, that's it for me,
Speaker 1: Thank you, and I've seen you in the next one. Bye.