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