WEBVTT 1 00:00:05.240 --> 00:00:08.599 Hey, Welcome to React Round Up, the podcast where we 2 00:00:08.679 --> 00:00:11.759 keep you updated on all things React related. This show 3 00:00:11.800 --> 00:00:15.480 is produced by Dpendeves and Onvoid. Topendeves is where you 4 00:00:15.599 --> 00:00:18.320 create top and Eves. We get top and pay and recognition. 5 00:00:18.359 --> 00:00:22.079 We're working on interesting problems in making meaningful community contributions 6 00:00:22.320 --> 00:00:26.440 an Onvoid, which offers remote design and software development services 7 00:00:26.760 --> 00:00:30.160 on the most client friendly business model, so clients only 8 00:00:30.239 --> 00:00:34.920 pay after tasks are delivered and true. In today's episode, 9 00:00:35.000 --> 00:00:38.280 we will be talking all about event searcing and the 10 00:00:38.320 --> 00:00:42.359 differences between what is considered event surcing in the front end, 11 00:00:42.520 --> 00:00:47.560 such as using reducts versus event searcing in the back end, 12 00:00:47.640 --> 00:00:52.399 which is a completely different game. My name is Lucas Paganini. 13 00:00:52.439 --> 00:00:55.479 Your hosts and the podcast. Joining me in today's episode 14 00:00:55.759 --> 00:01:02.119 are the also hosts, Chris Fruan, Hello everybody, Peter Ossa, 15 00:01:02.880 --> 00:01:08.359 Hi Evoon, and our very special guest which was also 16 00:01:08.799 --> 00:01:12.400 on our last episode of Adventures and Angler, another podcast 17 00:01:12.519 --> 00:01:15.120 also produced by Onvoid and Top and OUs if you're 18 00:01:15.159 --> 00:01:18.840 interested in that, which is Louise Galias, the CEO and 19 00:01:19.000 --> 00:01:23.840 founder of Onoid. Oh good, sorry, dude, I think you've 20 00:01:23.879 --> 00:01:27.319 got my company by mistake so the CEO and founder 21 00:01:27.359 --> 00:01:27.959 of Umbar. 22 00:01:28.840 --> 00:01:34.400 Yeah, we're not doing acquisitions at this time. Sorry. Yeah, 23 00:01:34.480 --> 00:01:36.480 hi everyone. My name is Louis Galias. 24 00:01:36.519 --> 00:01:38.840 I'm an engineer, even though i'm the CEO of the company. 25 00:01:39.359 --> 00:01:43.120 We help companies distribute data uh and do it in 26 00:01:43.159 --> 00:01:45.879 a way that's very easy and it has great applications 27 00:01:45.879 --> 00:01:49.120 and events sourcing, which is our current market focus. 28 00:01:49.480 --> 00:01:56.599 Awesome, awesome. Yes, Louise really is a mastermind behind events searching. 29 00:01:57.280 --> 00:02:01.239 He actually offers a free online core about event sourcing, 30 00:02:01.519 --> 00:02:03.359 So for those of you that are interested, you can 31 00:02:03.400 --> 00:02:08.400 go to mbar dot cloud slash EESC which stands for 32 00:02:08.520 --> 00:02:12.439 Event Sercing Course. And I met him because I did 33 00:02:12.479 --> 00:02:14.840 this course and I can vouch for it. It is 34 00:02:15.120 --> 00:02:18.639 really good. It is really well made, and I learned 35 00:02:18.680 --> 00:02:21.599 a tom from him, and I just thought, hey, dude, 36 00:02:21.919 --> 00:02:24.400 let's bring you to the podcast because I'm sure that 37 00:02:24.479 --> 00:02:27.879 this is going to be beneficial to a lot of developers. 38 00:02:28.000 --> 00:02:31.759 A lot of people don't have this context of how 39 00:02:31.840 --> 00:02:34.080 event searcing is done. It a lot of people don't 40 00:02:34.080 --> 00:02:36.960 even know what event searcing is like in fact and 41 00:02:37.039 --> 00:02:39.599 applied to the back end. So I think this is 42 00:02:39.680 --> 00:02:42.280 going to be really relevant for those of you that 43 00:02:43.000 --> 00:02:45.759 want to know more about the back end side of things. 44 00:02:46.039 --> 00:02:49.680 So just an FYII, this podcast episode is not going 45 00:02:49.680 --> 00:02:51.840 to be a lot about REACT, but we're going to 46 00:02:51.879 --> 00:02:56.159 do a lot of comparisons between event sercing and using 47 00:02:56.319 --> 00:03:00.719 reducts and all the flux patterns which are very commonly 48 00:03:00.840 --> 00:03:03.560 used alongwid REACT. But you will see that it's pretty 49 00:03:03.560 --> 00:03:06.879 different when you're doing that in the back end. All right, 50 00:03:07.080 --> 00:03:11.599 So Louise, let's start with some concepts. What do you 51 00:03:11.639 --> 00:03:15.159 think is relevant for us to define to the audience 52 00:03:15.199 --> 00:03:19.080 before we start talking about the rest of the subject. 53 00:03:19.759 --> 00:03:22.599 So I think it's a good idea to start with events, right, 54 00:03:22.639 --> 00:03:25.520 and the inversion that we have in events sourcing and 55 00:03:25.840 --> 00:03:29.960 similarly in redoucts as well, when you're using this in 56 00:03:29.960 --> 00:03:33.560 the front end, right, So as opposed to having an 57 00:03:33.560 --> 00:03:37.360 application where you are tracking state and modifying state in place, 58 00:03:37.599 --> 00:03:39.439 what you're doing is you're recording events, right, So if 59 00:03:39.439 --> 00:03:44.439 somebody makes a click, then you react to that event 60 00:03:44.599 --> 00:03:47.560 by saying, I'm going to modify my state in this way. 61 00:03:47.879 --> 00:03:52.800 So in this case, the state is really the primary, sorry, 62 00:03:52.800 --> 00:03:55.400 the secondary part of your application, and your events are 63 00:03:55.439 --> 00:03:56.439 the primary part. 64 00:03:56.719 --> 00:03:56.879 And. 65 00:03:58.680 --> 00:04:02.439 There are similarities in this regard, but there are definitely 66 00:04:02.439 --> 00:04:05.840 differences because in the front end, your application is very ephemeral. Right, 67 00:04:06.159 --> 00:04:08.759 if you have a browser window open right now, you 68 00:04:08.800 --> 00:04:11.240 close it, great, that's it, right, You don't Maybe you 69 00:04:11.280 --> 00:04:15.280 store some things in local storage, but beyond that everything 70 00:04:15.319 --> 00:04:17.800 is stored in the server. When you're using this pattern 71 00:04:17.800 --> 00:04:21.000 in the server, it's much different because now you have 72 00:04:21.079 --> 00:04:23.240 to think about storing those events and being able to 73 00:04:23.279 --> 00:04:27.480 build your state and keep track of it. So again 74 00:04:28.040 --> 00:04:30.800 the concepts to summarize what I've said, right, is that 75 00:04:31.040 --> 00:04:35.560 it's a similar inversion of the concepts, where now instead 76 00:04:35.600 --> 00:04:38.240 of having state as your source of truth, your events 77 00:04:38.240 --> 00:04:40.319 are your sorts of truth, and a state is a derivation. 78 00:04:40.839 --> 00:04:44.480 But despite those similarities, it's very different because you have 79 00:04:44.519 --> 00:04:48.920 to track your events in a permanent way as opposed 80 00:04:48.920 --> 00:04:50.399 to in a e firmeral way where you can do 81 00:04:50.399 --> 00:04:53.000 it in the front end with a single server, single core, 82 00:04:53.680 --> 00:04:56.120 single threat of JavaScript running perfect. 83 00:04:56.240 --> 00:04:58.639 Yeah, so there are like all the complexities that go 84 00:04:58.720 --> 00:05:04.920 along with dealing with those limitations, right, And okay, so 85 00:05:05.079 --> 00:05:09.199 Peter Chris, do you guys think there's any fundamentals that 86 00:05:09.199 --> 00:05:11.839 we should cover before we get into event sourcing. By 87 00:05:11.839 --> 00:05:15.839 the way, do YouTube feel comfortable with events sourcing any 88 00:05:16.120 --> 00:05:21.120 particular basic questions about it? We can definitely tackle that now. Yeah. 89 00:05:21.199 --> 00:05:24.839 So for me, I think the idea, I think I'm 90 00:05:24.920 --> 00:05:27.920 just trying to create like a parallel or like copy 91 00:05:27.920 --> 00:05:33.240 and contrasts. Yeah, so I think maybe maybe I may 92 00:05:33.279 --> 00:05:36.600 want to ask like the question. I think that's probably 93 00:05:36.639 --> 00:05:41.600 regarding like the principle behind events sourcing, maybe like maybe 94 00:05:42.120 --> 00:05:45.000 just another view kind of Yeah, I get that, yet 95 00:05:45.199 --> 00:05:48.000 it's it's at all maybe in the way that maybe 96 00:05:48.079 --> 00:05:51.759 like Fontain developers will relate to Yeah, I know you 97 00:05:51.839 --> 00:05:55.800 gave one about widows, but maybe something I don't say 98 00:05:55.800 --> 00:05:57.879 it's close to low level maybe could but is it 99 00:05:58.000 --> 00:06:01.000 like an event ball so those is eventv in yeah, 100 00:06:01.040 --> 00:06:02.079 this kind of concepts. 101 00:06:02.120 --> 00:06:02.600 Yeah, I. 102 00:06:05.240 --> 00:06:05.519 Yeah. 103 00:06:05.560 --> 00:06:08.040 So there are moving parts when you're doing this pattern 104 00:06:08.079 --> 00:06:09.959 in the back end, right, because when you're doing everything 105 00:06:10.079 --> 00:06:12.759 in the front and you can just do everything in memory, 106 00:06:12.759 --> 00:06:14.879 like I was saying, So when you think about how 107 00:06:14.920 --> 00:06:17.360 you're handling your events and how you're queuing them, when 108 00:06:17.399 --> 00:06:18.879 you are doing this in the front and right, you 109 00:06:18.879 --> 00:06:22.680 just have a you know, first in, first out queue 110 00:06:22.680 --> 00:06:25.160 and you handle messages like that, and then you apply 111 00:06:25.199 --> 00:06:27.240 them against your state. Right, okay, but how do you 112 00:06:27.279 --> 00:06:28.839 do that when you actually need them for search of 113 00:06:28.879 --> 00:06:29.319 that does this? 114 00:06:29.720 --> 00:06:31.759 There are equivalent parts on the back end. 115 00:06:31.800 --> 00:06:35.000 So for example, on your queue events that you have 116 00:06:35.040 --> 00:06:35.720 in the front and. 117 00:06:35.639 --> 00:06:37.600 You need a similar queue that is. 118 00:06:37.560 --> 00:06:41.199 More permanent infrastructure on the back end, there are differences 119 00:06:41.199 --> 00:06:44.360 where they are not quite the same the same things 120 00:06:44.360 --> 00:06:46.399 on the back end. So for example, in the back 121 00:06:46.480 --> 00:06:50.079 end you need to you need to store your events permanently, right, 122 00:06:50.120 --> 00:06:52.079 so you can quite draw the same parallels. 123 00:06:53.360 --> 00:06:57.439 Now, what I would say is from a benefit perspective, I. 124 00:06:57.399 --> 00:06:59.639 Think this is where I can draw the most parallels 125 00:06:59.639 --> 00:07:02.720 that when you have to reason about how your application 126 00:07:02.839 --> 00:07:06.959 is changing, it's easier to reason about the delta themselves 127 00:07:07.279 --> 00:07:08.439 than the state as a whole. 128 00:07:08.639 --> 00:07:11.120 So when you can isolate, hey, I'm only changing this 129 00:07:11.319 --> 00:07:14.120 one particular thing and it's going to affect my state. 130 00:07:13.920 --> 00:07:17.120 In this particularly defined way. Where your functions are essentially 131 00:07:17.160 --> 00:07:19.399 pure functions. Right, you have your state input, you have 132 00:07:19.439 --> 00:07:21.480 a state output, and then you have a pure function. 133 00:07:21.519 --> 00:07:23.720 That is, for me, state input is to state output 134 00:07:23.959 --> 00:07:28.439 with the delta. And this process of take going from 135 00:07:28.519 --> 00:07:33.480 state transitions from one to another and using that delta 136 00:07:33.680 --> 00:07:37.480 as the primary player in your system. This is what 137 00:07:37.519 --> 00:07:39.959 eventsourcing is all about, instead of focusing on the state 138 00:07:40.000 --> 00:07:42.040 as a whole and having this kind of weird thing 139 00:07:42.079 --> 00:07:44.639 where you have a giant function that is trying to 140 00:07:44.680 --> 00:07:46.959 do all sorts of crazy things and having all sorts 141 00:07:46.959 --> 00:07:50.439 of different case switch statements of you know, maybe. 142 00:07:50.240 --> 00:07:51.600 I want to do this, maybe I want to do that, 143 00:07:51.680 --> 00:07:53.240 maybe I want to use the service or the combination 144 00:07:53.279 --> 00:07:54.240 of the thing. 145 00:07:54.439 --> 00:07:56.639 No, just think about everything as a pure function where 146 00:07:56.639 --> 00:07:59.279 you have state input, state output and some delta in 147 00:07:59.360 --> 00:08:01.399 between and a function that is going to help because 148 00:08:01.439 --> 00:08:04.399 from that delta into the state input to state output transition. 149 00:08:05.480 --> 00:08:07.839 I think I think that's I think that's way much. 150 00:08:07.879 --> 00:08:10.720 So it's more like from what you describe, it's more 151 00:08:10.800 --> 00:08:16.680 like it's more like a permanent more like you permanent 152 00:08:17.040 --> 00:08:21.360 like we of like constantly getting like information that you 153 00:08:21.399 --> 00:08:24.079 may kind of put in your states. So it's just 154 00:08:24.160 --> 00:08:27.399 like I really say, is it this obviously like it's 155 00:08:27.600 --> 00:08:29.720 moll stop kind of right? Does it seem like that? 156 00:08:30.399 --> 00:08:30.560 Yeah? 157 00:08:32.000 --> 00:08:36.240 All right, all right, I think that makes sense. Yeah, yeah, Chris, 158 00:08:36.240 --> 00:08:38.360 do you have a new question on that? Bybe to 159 00:08:38.639 --> 00:08:41.039 create like parallel with that sound like you wanted. 160 00:08:42.840 --> 00:08:45.200 Yeah, I was laughing a bit back there when when 161 00:08:45.399 --> 00:08:47.559 Lucas mentioned there's people who probably don't even know what 162 00:08:47.600 --> 00:08:51.679 event sourcing is, and maybe one of those. So now 163 00:08:51.840 --> 00:08:55.159 I guess to not like just to be a total 164 00:08:55.240 --> 00:08:57.720 new but but maybe to relate to to kind of 165 00:08:57.759 --> 00:09:00.039 the front end and things like that. I guess the 166 00:09:00.080 --> 00:09:03.679 only the only thing like the buzzword I think of, 167 00:09:03.960 --> 00:09:06.080 but it's maybe not the exact same thing is I 168 00:09:06.120 --> 00:09:10.679 know there's these like these event I'm not even sure 169 00:09:10.720 --> 00:09:13.639 what they called, like event databases, but I feel like 170 00:09:13.679 --> 00:09:16.799 what you're doing is even more generalized then you don't. 171 00:09:17.600 --> 00:09:20.360 It may be just the architecture itself and you maybe 172 00:09:20.399 --> 00:09:23.440 don't need like a database and all this event driven thing. 173 00:09:24.200 --> 00:09:26.559 But but maybe what we could touch on a few 174 00:09:26.559 --> 00:09:29.600 times throughout the podcast is is like how it relates 175 00:09:29.600 --> 00:09:31.519 to the front end. I what I do know with 176 00:09:31.600 --> 00:09:37.200 the whole flux thing and the event event sourcing, why 177 00:09:37.440 --> 00:09:39.639 really it was made is kind of what you mentioned already. 178 00:09:40.399 --> 00:09:42.279 There's a great talk. Maybe I'll look it up and 179 00:09:42.320 --> 00:09:44.320 post it at the end of the show, but from 180 00:09:44.440 --> 00:09:47.679 why Facebook kind of came up with this and They 181 00:09:47.720 --> 00:09:49.840 probably didn't. They weren't the ones who invented it. But 182 00:09:50.360 --> 00:09:53.000 there when they were working on their chat, they had 183 00:09:53.039 --> 00:09:56.200 all these you know, a chat is super like state intensive. 184 00:09:56.279 --> 00:10:00.279 You have how many messages, you're are unread, number of people, 185 00:10:00.320 --> 00:10:04.159 all the stuff. And they found you know, doing it 186 00:10:04.759 --> 00:10:08.360 like without pure functions, without without event sourcing. Every time 187 00:10:08.360 --> 00:10:09.960 they tried to add a new feature, they would get 188 00:10:10.000 --> 00:10:15.559 regressions elsewhere in the state. But yeah, that's that's my 189 00:10:16.159 --> 00:10:19.480 to my extent of what I know about event sourcing, 190 00:10:19.559 --> 00:10:22.879 and and yeah, I don't know, I'm just kind of 191 00:10:22.960 --> 00:10:25.720 rambling on. Probably reflects how how little I know about this. 192 00:10:27.240 --> 00:10:29.360 No, but that's I think that's pretty much in line 193 00:10:29.399 --> 00:10:30.720 with the proposition of. 194 00:10:30.639 --> 00:10:33.480 It, right, because there is a there is a payment 195 00:10:33.480 --> 00:10:34.039 that you have to do. 196 00:10:34.120 --> 00:10:35.759 You have to pay the piper upfront, right, You have 197 00:10:35.840 --> 00:10:38.240 to put in some work to understand these concepts and 198 00:10:38.399 --> 00:10:40.919 get the infrastructure in place. I mean, if you think 199 00:10:40.960 --> 00:10:43.440 about it from the fronto perspective, right, imagine that you're 200 00:10:43.440 --> 00:10:46.360 transitioning from you know, some application that was built with 201 00:10:46.399 --> 00:10:49.480 pure HTML and some jQuery and it's you know, this 202 00:10:49.639 --> 00:10:53.879 giant monolith like mass, right, and then you say to 203 00:10:53.919 --> 00:10:55.919 the team, Hey, you know what, let's move this to 204 00:10:56.159 --> 00:10:57.080 a single page. 205 00:10:56.840 --> 00:10:59.919 Application based on reacting redox. Right. If you're doing that, 206 00:11:00.080 --> 00:11:01.480 you're going to have to pay some cost up front. 207 00:11:01.480 --> 00:11:02.039 You're going to have to. 208 00:11:02.120 --> 00:11:05.440 Educate people or get people that are already educated, and 209 00:11:05.519 --> 00:11:08.399 you're going to have to have some guardrails in some 210 00:11:09.440 --> 00:11:11.759 libraries and some abstractions that are going to help you 211 00:11:11.799 --> 00:11:12.279 deploy this. 212 00:11:12.519 --> 00:11:14.159 It's not something that you're going to do overnight. 213 00:11:14.679 --> 00:11:17.440 So the proposition with event sourcing, though, is that once 214 00:11:17.480 --> 00:11:20.480 you have paid that cost that you go. You essentially 215 00:11:20.559 --> 00:11:23.120 go slow at first, to go fast later at a 216 00:11:23.200 --> 00:11:25.759 sustainable rate where you're not eventually going to hit a wall. 217 00:11:25.919 --> 00:11:28.360 Because with these big applications where. 218 00:11:28.159 --> 00:11:30.360 You have a ball of a band aid on top 219 00:11:30.399 --> 00:11:33.039 of a ball of band aid, you essentially hit a 220 00:11:33.080 --> 00:11:35.240 wall at some point where you get so many regressions 221 00:11:35.279 --> 00:11:37.879 that you cannot develop anything. You have diminishing returns every 222 00:11:37.919 --> 00:11:40.039 time you ad a feature. So the proposition with event 223 00:11:40.080 --> 00:11:43.279 sourcing is that similarly, you have a cost to pay upfront, 224 00:11:43.480 --> 00:11:46.840 but with the benefit that after you've paid that cost, 225 00:11:47.039 --> 00:11:49.639 you'll be able to go very quickly because the system 226 00:11:49.840 --> 00:11:55.279 is easy to reason about. Despite the system growing disproportionately 227 00:11:55.679 --> 00:11:56.759 in the number of features. 228 00:11:57.080 --> 00:12:00.320 Now, how is that actually done in prect to this, 229 00:12:00.519 --> 00:12:03.240 because like interurity, this sounds great, This sounds like this 230 00:12:03.279 --> 00:12:05.879 will solve a lot of the complexities that big code 231 00:12:05.919 --> 00:12:09.600 bases have, which I think most of us know how 232 00:12:09.639 --> 00:12:11.879 that goes. Like most of us have work in a 233 00:12:11.919 --> 00:12:16.360 big co base, and despite all the good intentions of 234 00:12:16.399 --> 00:12:20.320 everyone of keeping the code organized, is just natural for 235 00:12:20.480 --> 00:12:23.480 things to get outdated because there are new patterns and 236 00:12:23.519 --> 00:12:26.480 you don't always come back to reflector the entire thing, 237 00:12:27.120 --> 00:12:32.159 and then you start getting parts that are considered legacy. Right, 238 00:12:33.240 --> 00:12:38.720 How in practice does what you were saying would work 239 00:12:38.879 --> 00:12:42.480 to avoid this complexity building up over time. 240 00:12:44.120 --> 00:12:46.919 So that's a great question because the reality of it, 241 00:12:47.000 --> 00:12:49.039 like with anything right, is that you get these promises 242 00:12:49.080 --> 00:12:50.480 and you have to know how these are going to 243 00:12:50.480 --> 00:12:51.480 come true. 244 00:12:51.600 --> 00:12:53.000 If they can come true in the first place. 245 00:12:53.360 --> 00:12:56.679 So firstly, I would highlight that, you know, I mean, 246 00:12:56.720 --> 00:12:58.720 I'm an engineer, I'm all about trade offs. I don't 247 00:12:58.759 --> 00:13:00.559 just preach and you know say you know this is 248 00:13:00.559 --> 00:13:01.799 going to be a silver bullet. 249 00:13:02.000 --> 00:13:04.320 There are no such things in engineering. Everybody who with 250 00:13:04.399 --> 00:13:05.039 some degree. 251 00:13:04.840 --> 00:13:09.399 Of experience knows that But that being said, when if 252 00:13:09.399 --> 00:13:12.399 you truly want to. 253 00:13:12.320 --> 00:13:16.159 Walk to the promised land, there are two aspects that 254 00:13:16.200 --> 00:13:17.000 you have to cover. 255 00:13:17.120 --> 00:13:19.679 One is a technical aspect, where you have your infrastructure 256 00:13:19.720 --> 00:13:21.799 and you have to know how to deploy that, how 257 00:13:21.840 --> 00:13:23.399 to set up your ci how to set up the 258 00:13:23.440 --> 00:13:26.279 different components that you need, like a place to store 259 00:13:26.320 --> 00:13:28.279 your events, a way to hew your events, a way 260 00:13:28.320 --> 00:13:31.159 to process your events, a way to react to your events, 261 00:13:31.200 --> 00:13:33.559 and you have to know how you're going to do 262 00:13:33.600 --> 00:13:35.919 that and make a plan for it. And second of all, 263 00:13:36.200 --> 00:13:38.879 it's the people aspect where you have to imboard people, 264 00:13:38.919 --> 00:13:41.720 introduce new way of thinking, perhaps on learn some of 265 00:13:41.720 --> 00:13:44.440 the patterns that they've been using. Everybody loves doing this 266 00:13:44.600 --> 00:13:47.360 great read of the delete kind of application because it's simple. 267 00:13:47.559 --> 00:13:51.039 There are a ton of frameworks like rails in Ruby. 268 00:13:51.960 --> 00:13:56.679 You know, you have frameworks in JavaScript as well. You 269 00:13:56.679 --> 00:13:59.919 have frameworks in PhD like Symphony and Larval that just 270 00:14:00.120 --> 00:14:02.639 help you do this great readup of the delete right. 271 00:14:02.879 --> 00:14:05.159 But if you're changing your way of thinking into thinking 272 00:14:05.159 --> 00:14:07.519 about the delta, doesn't thinking in pure functions. You need 273 00:14:07.559 --> 00:14:10.440 new obstructions and it's not just the technical implementation of 274 00:14:10.440 --> 00:14:14.399 those abtractions it's the convincing the people right, and luckily 275 00:14:14.679 --> 00:14:17.480 with events sourcing, once you do you know a modicum 276 00:14:17.519 --> 00:14:20.159 of training, you know, maybe two three weeks where you 277 00:14:20.240 --> 00:14:23.320 put in some serious time into studying it, you can 278 00:14:23.360 --> 00:14:26.879 get quite good. And assuming that you've set up the infrastructure, 279 00:14:27.279 --> 00:14:29.600 and if you've done that, and you do it with 280 00:14:29.679 --> 00:14:31.879 an initial part of your system, so you don't move 281 00:14:31.919 --> 00:14:32.600 everything at once. 282 00:14:32.639 --> 00:14:35.320 Of course, you don't do a big binary right, you move. 283 00:14:35.200 --> 00:14:38.200 A specific part of your system, and then once you're done, 284 00:14:38.360 --> 00:14:40.399 you'll be in a position where you. 285 00:14:40.039 --> 00:14:41.799 Turned your team to use events sourcing. 286 00:14:42.200 --> 00:14:44.600 You have moved a part of your system to eventsurcing 287 00:14:44.600 --> 00:14:47.360 because you thought it would deliver some business value, and 288 00:14:47.399 --> 00:14:51.799 hopefully you've set up the technical infrastructure concerns as well. 289 00:14:52.120 --> 00:14:55.320 Depending on how much you want to implement yourself, you 290 00:14:55.320 --> 00:14:57.159 can go from deploying things as quickly as you know, 291 00:14:57.320 --> 00:14:59.679 two to three weeks in terms of the infrastructure, plus 292 00:14:59.679 --> 00:15:02.720 pseudo three weeks in terms of training yourself and developing 293 00:15:02.759 --> 00:15:05.279 the first couple of features, to going over a year 294 00:15:05.399 --> 00:15:07.360 or two years if you really want to do everything 295 00:15:07.360 --> 00:15:09.360 from the ground up right. So, for example, when it 296 00:15:09.399 --> 00:15:12.200 comes to the infrastructure, you can build your own events store, 297 00:15:12.240 --> 00:15:14.799 and I know people that have actually interacted with the 298 00:15:14.799 --> 00:15:18.440 file system built the whole entire library to address the 299 00:15:18.480 --> 00:15:20.120 concern of the events store, and then they have to 300 00:15:20.159 --> 00:15:22.919 add in all these features like indexing, which if you 301 00:15:23.039 --> 00:15:27.120 just wrapped a traditional database you could get it essentially 302 00:15:27.120 --> 00:15:30.120 almost for free. Right when it comes to queuing systems, 303 00:15:30.159 --> 00:15:32.399 there are people that implement their own queuing systems. 304 00:15:32.399 --> 00:15:36.440 They use things like Rabin and Q and they customize 305 00:15:36.440 --> 00:15:39.360 on top of it, and there are abstractions out there. 306 00:15:39.960 --> 00:15:42.240 There's a range of obstructions and different sides of the 307 00:15:42.279 --> 00:15:44.960 spectrum in terms of how much you need to know. We, 308 00:15:45.159 --> 00:15:48.559 of course at Amber, we make it essentially as easy. 309 00:15:48.600 --> 00:15:50.679 We're on one side of the spectrum. It's as easy 310 00:15:50.679 --> 00:15:52.120 as it gets, right, but of course that comes at 311 00:15:52.159 --> 00:15:53.240 a cost where you have to pay for it. 312 00:15:53.320 --> 00:15:55.080 Right, But the. 313 00:15:55.120 --> 00:15:59.440 More you are comfortable with using the existing tooling, that's 314 00:15:59.440 --> 00:16:03.840 how they're like using posters, using my sequel, or using ambar, 315 00:16:04.200 --> 00:16:07.840 or using technologies to deploy web servers like cloud run 316 00:16:07.960 --> 00:16:10.840 or far Gate and not complicating your life, you know, 317 00:16:10.919 --> 00:16:14.120 doing your own Kubernetes deployment. If you just do it 318 00:16:14.240 --> 00:16:18.120 the simplest, the simplest way, and using system cooling, you 319 00:16:18.159 --> 00:16:19.600 can get set up in about a month and a 320 00:16:19.639 --> 00:16:21.799 half including technical time and training time. 321 00:16:23.120 --> 00:16:24.799 And I think that's quite and I've. 322 00:16:24.559 --> 00:16:26.840 Seen that in practice, and I think that's quite impressive 323 00:16:26.840 --> 00:16:30.039 for something where you need to flip everything. But people like, 324 00:16:30.080 --> 00:16:32.200 because we're engineers, we fall into the trap of, you know, 325 00:16:32.279 --> 00:16:34.000 I need to understand absolutely everything. 326 00:16:34.840 --> 00:16:35.399 We don't do this. 327 00:16:35.519 --> 00:16:37.759 If we're implementing a file storage, right, we don't need 328 00:16:37.759 --> 00:16:39.080 to understand how S three works. 329 00:16:39.080 --> 00:16:39.759 We just use it. 330 00:16:40.559 --> 00:16:43.279 So I would my general advice, after giving you the 331 00:16:43.279 --> 00:16:45.159 details of how to go about it, is pick your 332 00:16:45.240 --> 00:16:47.840 battles in what you need to learn, and learn the 333 00:16:47.879 --> 00:16:49.480 things that are going to make a difference for you 334 00:16:49.519 --> 00:16:52.159 as a business, not the things that are just you know, 335 00:16:52.320 --> 00:16:53.519 problems that are already sold. 336 00:16:53.799 --> 00:16:57.159 Okay, that's that does make sense. It is still a 337 00:16:57.200 --> 00:17:02.759 bit scary, but I think I agree with you, like 338 00:17:02.879 --> 00:17:08.599 we allow so many abstractions, especially JavaScript developers. We are 339 00:17:08.680 --> 00:17:12.440 so used to frameworks. There are just layers on top 340 00:17:12.480 --> 00:17:16.640 of layers and layers and layers of abstraction, and for 341 00:17:16.680 --> 00:17:20.240 some reason I still find it a bit weird to 342 00:17:20.319 --> 00:17:23.079 abstract and events fersaal layer. But I think this is 343 00:17:23.200 --> 00:17:26.200 more about the fact that I don't feel as comfortable 344 00:17:26.319 --> 00:17:30.839 with it doing natively to be okay with an abstraction, 345 00:17:31.000 --> 00:17:37.680 almost like I first wanted to understand the fundamentals of 346 00:17:38.119 --> 00:17:41.759 front end development before I went into frameworks that would 347 00:17:41.759 --> 00:17:45.960 abstract that way, so that I have the knowledge of 348 00:17:46.079 --> 00:17:49.119 what's going on under the hood. But you're also correct 349 00:17:49.119 --> 00:17:51.880 in the sense that I use mongo deb without knowing 350 00:17:51.960 --> 00:17:55.279 how it actually stores the data. I just use it. 351 00:17:55.279 --> 00:17:58.960 It almost feels like MongoDB is the lowest level, but 352 00:17:59.039 --> 00:18:03.680 it's not. It's like still a high level abstraction. Sequel 353 00:18:03.880 --> 00:18:08.400 is still a high level abstraction within how the data 354 00:18:08.519 --> 00:18:12.480 is actually stored and retrieved internally in the SQL database. 355 00:18:12.960 --> 00:18:15.559 So I think you touched on a good point from 356 00:18:15.559 --> 00:18:19.559 your experience dealing with people that are starting out with 357 00:18:19.759 --> 00:18:24.319 events sourcing. Is it also very common to have people 358 00:18:24.359 --> 00:18:29.480 that fear this abstraction layer and why do you think 359 00:18:30.039 --> 00:18:35.559 that is the case versus other abstractions that already exist 360 00:18:35.640 --> 00:18:38.599 and people are comfortable with. I think graph ql can 361 00:18:38.640 --> 00:18:43.119 be a good analogy because in a way, people are 362 00:18:43.279 --> 00:18:49.480 very comfortable with just creating rest API routes and just 363 00:18:49.559 --> 00:18:53.240 doing it, but express it. Although express is an abstraction, 364 00:18:53.480 --> 00:18:58.759 it does feel low level enough. I know that somebody 365 00:18:58.799 --> 00:19:00.920 is gonna hate on me because saying low level for 366 00:19:01.039 --> 00:19:05.200 something like express as whatever, but it does feel because 367 00:19:05.240 --> 00:19:09.000 you have a lot of control over how the handlers 368 00:19:09.000 --> 00:19:13.440 are being created versus if you're using an abstraction on 369 00:19:13.480 --> 00:19:17.960 top of Graphql. There are some very very opinionated ones, 370 00:19:18.119 --> 00:19:20.839 like a pole server being maybe one of the most 371 00:19:20.880 --> 00:19:26.079 opinionated ones. So maybe event sourcing can be compared to it, 372 00:19:26.279 --> 00:19:29.200 like events and abstractions in the back end could be 373 00:19:29.279 --> 00:19:33.279 compared to Graphql abstractions in the sense that you want 374 00:19:33.319 --> 00:19:36.599 to know how it's working under the hood, but at 375 00:19:36.599 --> 00:19:39.519 the same time, why do you need it? You know? 376 00:19:40.319 --> 00:19:41.720 Yeah, I think so. 377 00:19:42.000 --> 00:19:46.000 I mean it as everything, there's new ones always right, 378 00:19:46.079 --> 00:19:50.200 and I think it's a fair fair thing to call 379 00:19:50.240 --> 00:19:52.599 out graphql. 380 00:19:52.440 --> 00:19:55.279 Because yeah, you know, people like to understand it two 381 00:19:55.279 --> 00:19:56.079 different degrees. 382 00:19:56.640 --> 00:20:00.680 I would point out that in general, where I see 383 00:20:00.720 --> 00:20:03.480 people that are most excited about events sourcing and that 384 00:20:03.559 --> 00:20:04.680 spend the most. 385 00:20:04.400 --> 00:20:06.640 Time in learning it are people that are. 386 00:20:06.599 --> 00:20:09.319 Closer to the beginning of their careers, because it seems like, 387 00:20:09.359 --> 00:20:12.319 oh my gosh, there's so much technical content here. Right, 388 00:20:12.359 --> 00:20:15.319 some subjects you can only go so far before it 389 00:20:15.359 --> 00:20:16.799 starts feeling a little bit too abstract. 390 00:20:16.799 --> 00:20:17.440 There's too much. 391 00:20:17.359 --> 00:20:19.759 Mathematics and it so it's maybe a bit discouraging, Whereas 392 00:20:19.799 --> 00:20:22.119 event sourcing is quite rich in that there's a lot 393 00:20:22.160 --> 00:20:26.680 to learn, especially because today, and it's something we're trying 394 00:20:26.680 --> 00:20:30.400 to solve with our free course today. Learning events sourcing 395 00:20:30.480 --> 00:20:36.000 still feels like going to that planet that Luke Skywalker 396 00:20:36.039 --> 00:20:40.240 goes to in Star Wars to find Master Yoda, where it's, 397 00:20:40.279 --> 00:20:42.400 oh my gosh, I'm going to go and find some hermit. 398 00:20:42.119 --> 00:20:43.599 That's going to teach me all about this stuff. 399 00:20:43.680 --> 00:20:46.640 And that feels exciting, right because it feels quite unique, 400 00:20:47.000 --> 00:20:50.119 and I think that's the reason that people are wanting to, 401 00:20:50.599 --> 00:20:54.720