1
00:00:05,280 --> 00:00:08,519
Speaker 1: Hey, Welcome to Adventures an Angler, the podcast where we

2
00:00:08,640 --> 00:00:12,240
keep you updated on all things Angler related. This show

3
00:00:12,359 --> 00:00:15,919
is produced by two companies, Top End Dovs and Void.

4
00:00:16,480 --> 00:00:18,640
Top and Devs is where we create top and doves.

5
00:00:18,679 --> 00:00:21,600
We get top and pay and recognition while working on

6
00:00:21,640 --> 00:00:26,519
interesting problems and making meaningful community contributions. An Void which

7
00:00:26,640 --> 00:00:31,320
provides remote design and software development services on the most

8
00:00:31,559 --> 00:00:36,520
client friendly structure, so clients only pay after the tasks

9
00:00:36,520 --> 00:00:41,000
are delivered and approved. In today's episode, we will be

10
00:00:41,039 --> 00:00:46,200
talking about events, most specifically event searching for those of

11
00:00:46,200 --> 00:00:48,799
you that may know the subject, and we'll be talking

12
00:00:48,840 --> 00:00:52,880
about the differences between what is considered events searching in

13
00:00:52,960 --> 00:00:56,960
the front end versus on the back end. My name

14
00:00:57,000 --> 00:00:59,759
is Lucas Paganini, your host in a podcast and joining

15
00:00:59,759 --> 00:01:04,359
me in today's episode is also the host Armand Vardanian.

16
00:01:05,959 --> 00:01:08,640
Speaker 2: Hello everyone, nice to look for another one.

17
00:01:10,200 --> 00:01:12,359
Speaker 1: The host Subrette.

18
00:01:11,760 --> 00:01:15,840
Speaker 3: Mishra, Hello everyone, and.

19
00:01:16,200 --> 00:01:21,159
Speaker 1: Our very special guest Louise Galias, which is the CEO

20
00:01:21,239 --> 00:01:24,599
and founder of Umbar. We'll be talking a little bit

21
00:01:24,680 --> 00:01:27,920
more about what number is, but basically what you have

22
00:01:27,959 --> 00:01:32,040
to know is that he is really an expert in

23
00:01:32,239 --> 00:01:35,719
event surcing. He knows a lot about that, and Umbar

24
00:01:36,000 --> 00:01:39,319
is a company one hundred percent focused on event surcing

25
00:01:39,359 --> 00:01:42,879
as well. So Louise, thank you so much for being here.

26
00:01:44,040 --> 00:01:46,359
Speaker 4: Yeah, hello everyone, really great to do. Not go with

27
00:01:46,400 --> 00:01:49,319
the fronten community. I'm Louise, founder of CEO of Lumbar,

28
00:01:49,439 --> 00:01:51,560
but you know, even though I'm the CEO, I'm very

29
00:01:51,640 --> 00:01:54,920
much an engineer, So looking forward to talking about a

30
00:01:55,000 --> 00:01:55,879
lot of software today.

31
00:01:57,439 --> 00:02:02,799
Speaker 1: Awesome, awesome, So Louis, I think just first you get

32
00:02:02,840 --> 00:02:05,680
started and give a bit more context to the audience.

33
00:02:06,120 --> 00:02:09,560
Could you do a quick pitch of Umbar and what

34
00:02:09,599 --> 00:02:13,000
it does, Which problems does it? Does it solve?

35
00:02:13,840 --> 00:02:14,120
Speaker 5: Yeah?

36
00:02:14,159 --> 00:02:18,680
Speaker 4: So you know when in front ends, to give some

37
00:02:18,759 --> 00:02:22,599
extra context, you will you have one one place where

38
00:02:22,599 --> 00:02:24,599
you're doing things right. You have the in memory state

39
00:02:24,639 --> 00:02:27,360
that you have on Chrome or Firefox or wherever you are,

40
00:02:27,680 --> 00:02:30,000
or even in your if you're using React Native, even

41
00:02:30,039 --> 00:02:32,879
in your device. When you have a back end, you

42
00:02:32,879 --> 00:02:35,680
have multiple moving parts to that back end, and when

43
00:02:35,680 --> 00:02:38,800
you are registering events you have to process them somehow.

44
00:02:39,759 --> 00:02:44,719
So that processing doesn't happen in a vacuum. It happens

45
00:02:44,719 --> 00:02:47,960
with a pipe in between different systems, and that pipe

46
00:02:48,000 --> 00:02:50,319
is really difficult to build the way that you connect

47
00:02:50,319 --> 00:02:52,280
events from one place to another, and that's what we

48
00:02:52,319 --> 00:02:55,319
do at Ambar. We focus on making that experience extremely

49
00:02:55,360 --> 00:02:58,240
easy for engineers, where they just write a few lines

50
00:02:58,240 --> 00:03:00,680
of code and then the pipes and the engines that

51
00:03:00,800 --> 00:03:06,439
move data around just come up magically awesome.

52
00:03:06,560 --> 00:03:11,639
Speaker 1: Okay, So now that we have this intro, I think

53
00:03:11,719 --> 00:03:16,000
we can start tackling the initial concepts that the audience

54
00:03:16,159 --> 00:03:19,120
must understand in order for us to go ahead with

55
00:03:19,159 --> 00:03:23,439
our discussion about events. So I guess the first major

56
00:03:23,520 --> 00:03:29,479
concept is, well, first, what are events specifically? Because talking

57
00:03:29,919 --> 00:03:34,680
with front end developers, there's the native concept of an event,

58
00:03:34,719 --> 00:03:37,560
which is basically like you clicked on a button so

59
00:03:37,639 --> 00:03:41,560
that triggered a click event, or you move your mouse

60
00:03:41,800 --> 00:03:46,639
so that triggered a mouse pointer event. So there's this

61
00:03:46,759 --> 00:03:51,039
native concept of events, which isn't completely different from what

62
00:03:51,080 --> 00:03:53,879
we're talking about here, right, but what we're talking about

63
00:03:54,000 --> 00:03:58,280
is a bit more generic than the native concept of

64
00:03:58,560 --> 00:04:02,080
events in the front end. And then after explaining the

65
00:04:02,120 --> 00:04:04,400
concept of events, I think we could also go to

66
00:04:04,680 --> 00:04:07,240
what is event sourcing specifically?

67
00:04:07,840 --> 00:04:08,319
Speaker 5: Yeah, so.

68
00:04:10,879 --> 00:04:12,599
Speaker 4: In the front end, like you were saying, you know,

69
00:04:12,680 --> 00:04:16,199
you have these click events. You know, you might hover

70
00:04:16,399 --> 00:04:20,720
over something and you use that to build state, right,

71
00:04:20,759 --> 00:04:24,240
to build what your application looks like, to build AHTML,

72
00:04:25,160 --> 00:04:29,120
load some CSS if you're loading it a synchronously, and

73
00:04:29,759 --> 00:04:33,480
all of this is done in a sort of flipped

74
00:04:33,519 --> 00:04:37,759
way from how you would have done it traditionally. And

75
00:04:37,800 --> 00:04:40,319
when I stay traditionally, right, I mean like nineteen ninety

76
00:04:40,360 --> 00:04:43,279
nine right where you would essentially just define your HTML

77
00:04:43,560 --> 00:04:46,519
and that's your state and you don't really have events

78
00:04:46,800 --> 00:04:49,800
in event sourcing. To now go to event sourcing, it's

79
00:04:49,879 --> 00:04:51,759
kind of the same concept, but on the back end,

80
00:04:52,120 --> 00:04:55,759
where instead of taking the state of today's applications, say

81
00:04:56,160 --> 00:04:59,000
you have a user with a username and email, you

82
00:04:59,079 --> 00:05:02,040
record your event, so you say something like I've just

83
00:05:02,079 --> 00:05:05,639
signed up, or I have just verified my email, or

84
00:05:05,720 --> 00:05:08,319
I have just purchased an item, or we have just

85
00:05:08,399 --> 00:05:12,000
dispatched an item from the warehouse to this customer. And

86
00:05:12,439 --> 00:05:15,399
when you register these events, you are able to then

87
00:05:15,480 --> 00:05:19,120
rebuild your state later on from those events in the

88
00:05:19,199 --> 00:05:22,399
same way that you would in a front But obviously

89
00:05:22,519 --> 00:05:24,800
the devil's in the details, because in the front and

90
00:05:24,879 --> 00:05:27,759
all you're doing is you're building this ephemeral state of

91
00:05:27,959 --> 00:05:31,160
what I'm displaying in the dome in the HTML, whereas

92
00:05:31,199 --> 00:05:33,279
in the back end it's something that you need for

93
00:05:33,360 --> 00:05:35,879
your application to run perfect perfect.

94
00:05:36,240 --> 00:05:40,560
Speaker 1: So it's basically the idea that, like, you may already

95
00:05:40,600 --> 00:05:44,600
be familiar with the flux concept. So in React you

96
00:05:44,639 --> 00:05:48,199
might be using reducts, and with Angler you might be

97
00:05:48,279 --> 00:05:52,279
using NGR acts or some sort of state management library.

98
00:05:52,759 --> 00:05:57,120
And so if you already have this concept, then you

99
00:05:57,160 --> 00:06:00,439
already understand what would be a custom event. And the

100
00:06:00,560 --> 00:06:04,839
idea with event sourcing is that one hundred percent of

101
00:06:04,879 --> 00:06:08,439
your stage is based on those events. So whenever you

102
00:06:08,600 --> 00:06:14,399
need to create the state, you just process the events, right,

103
00:06:14,920 --> 00:06:19,399
and you basically reduce the events based on the current state.

104
00:06:19,480 --> 00:06:22,079
So it's the same way in which we do it

105
00:06:22,120 --> 00:06:25,839
in NGRX and any of those state management libraries. But

106
00:06:26,040 --> 00:06:29,319
as you were mentioning in the beginning when you introduced MBAR,

107
00:06:29,639 --> 00:06:32,560
when you do that in the back end, it's a

108
00:06:32,600 --> 00:06:36,319
lot more complicated because you can't just have a function

109
00:06:36,439 --> 00:06:40,959
that takes the entire current state of the application as

110
00:06:41,079 --> 00:06:43,800
the first argument in the event as the second and

111
00:06:43,920 --> 00:06:47,839
returns the new state, because it's like the current state

112
00:06:47,920 --> 00:06:53,160
can be gigantic, right, So you're always trying to make

113
00:06:53,199 --> 00:06:56,800
it scalable and make it as fast as possible. That's

114
00:06:56,839 --> 00:06:57,839
basically it. Correct.

115
00:06:59,040 --> 00:07:00,480
Speaker 5: Yeah, that's it in a nutshell.

116
00:07:00,519 --> 00:07:04,519
Speaker 1: Yeah, absolutely awesome, awesome. All right, So now that we

117
00:07:04,639 --> 00:07:07,720
got the concepts out of the way, can you explain

118
00:07:07,759 --> 00:07:10,439
a little bit more like the challenges that we have

119
00:07:10,600 --> 00:07:14,199
with handling events and events sourcing in the back end? Like,

120
00:07:14,279 --> 00:07:16,720
of course there are those that we were just mentioning

121
00:07:16,759 --> 00:07:22,360
about the scalability, but I also imagine that sometimes you

122
00:07:22,439 --> 00:07:25,600
might want to deal with a small portion of the

123
00:07:25,800 --> 00:07:29,800
entire data just because you also need to consider the

124
00:07:29,839 --> 00:07:33,079
effort to transfer the data from the database. Right, So

125
00:07:33,120 --> 00:07:37,120
maybe like you have your entire state, but as you

126
00:07:37,240 --> 00:07:40,680
iterate on the state, you might only want to retrieve

127
00:07:40,959 --> 00:07:44,480
small portions of it to run your calculations. Also, there's

128
00:07:44,519 --> 00:07:47,319
a problem that everything is a synchronous. So these are

129
00:07:47,360 --> 00:07:49,160
just some of the things that are coming to my mind.

130
00:07:49,519 --> 00:07:53,040
But which are the ones that come to your mind

131
00:07:53,079 --> 00:07:56,360
in terms of the complexity of implementing an event sourcing

132
00:07:56,480 --> 00:07:57,959
system in the back end.

133
00:07:58,600 --> 00:08:01,480
Speaker 4: Yeah, So the big difference is that your state is

134
00:08:01,519 --> 00:08:03,759
not aphemeral. If you have a single page application on

135
00:08:03,800 --> 00:08:06,480
the front end and you just do a reload. You

136
00:08:06,600 --> 00:08:08,759
might just hit the back end points again to get

137
00:08:08,800 --> 00:08:11,959
some state, right, and that's essentially your database, right, But

138
00:08:12,920 --> 00:08:14,319
there's not much going on in there.

139
00:08:14,360 --> 00:08:14,519
Speaker 5: Right.

140
00:08:14,560 --> 00:08:17,079
Speaker 4: You might get some user details, you might get some cookies,

141
00:08:17,079 --> 00:08:22,160
some things, but that's it, and then you have essentially

142
00:08:22,199 --> 00:08:26,560
a clean rebuild. If you're using these tools like greducs,

143
00:08:26,600 --> 00:08:29,040
where you have some state, you might have some events,

144
00:08:29,040 --> 00:08:32,000
and then if someone clicks then you might return on

145
00:08:32,000 --> 00:08:35,679
a new state. The difference in the back end is

146
00:08:35,720 --> 00:08:38,399
that you now have to have the state for all

147
00:08:38,440 --> 00:08:40,799
your users, so that you have a new state of

148
00:08:40,799 --> 00:08:43,639
the application at any given time and have the ability

149
00:08:43,679 --> 00:08:48,159
to retrieve subsets of that state. So, for example, if

150
00:08:48,399 --> 00:08:50,320
I have a bunch of users that are signing up,

151
00:08:50,720 --> 00:08:52,840
I don't want to return to a user on a

152
00:08:52,879 --> 00:08:55,919
back and end point information about another user. Necessarily, I

153
00:08:55,960 --> 00:08:58,399
might just want to return information to them about them.

154
00:08:59,000 --> 00:09:01,480
And if I'm going to do that, I'm going to

155
00:09:01,559 --> 00:09:03,440
need to say those events somewhere and then have a

156
00:09:03,480 --> 00:09:08,720
way to execute that function in a cast way of sorts.

157
00:09:08,799 --> 00:09:13,799
So instead of recording the events and then getting all

158
00:09:13,799 --> 00:09:15,639
the events in my system and running them through a

159
00:09:15,679 --> 00:09:17,840
function and every time I get an AHDP requests in

160
00:09:17,879 --> 00:09:20,639
the back end, I return to them a result based

161
00:09:20,679 --> 00:09:22,279
on all the events in the system. What I would

162
00:09:22,320 --> 00:09:24,440
do is I would pre process those events, so it

163
00:09:24,480 --> 00:09:28,279
would be building the state of the application on an

164
00:09:28,320 --> 00:09:32,399
ongoing basis and then retrieving the state from somewhere dynamically

165
00:09:32,440 --> 00:09:36,240
whenever somebody makes an HDP request. And that's markedly different

166
00:09:36,240 --> 00:09:38,279
from the front end when you you know, at the

167
00:09:38,279 --> 00:09:41,320
beginning of the load, if you press F five or reload,

168
00:09:41,840 --> 00:09:44,000
you fetch your state, you know, and then everything lives

169
00:09:44,240 --> 00:09:46,480
in very much in isolation.

170
00:09:47,320 --> 00:09:49,919
Speaker 1: Yeah. Yeah, that does make a ton of sense, like

171
00:09:50,000 --> 00:09:52,679
the fact that you actually have the data of all

172
00:09:52,720 --> 00:09:56,799
the users, not just whatso that is indeed a gigantic complexity.

173
00:09:57,399 --> 00:09:59,679
Super d I noticed that you were going to say.

174
00:09:59,519 --> 00:10:03,039
Speaker 3: Something, so yeah, I was just asking, like, that's to

175
00:10:03,120 --> 00:10:07,159
be clear to me and for everyone. So so the

176
00:10:07,480 --> 00:10:10,720
Amber can be a use case in between your like

177
00:10:10,840 --> 00:10:15,159
suppose you are consuming to some services, some excellent services.

178
00:10:15,360 --> 00:10:20,480
HUMBER can be clear play in between your services and

179
00:10:20,519 --> 00:10:23,440
your ey and to handle the pier events.

180
00:10:23,480 --> 00:10:26,360
Speaker 4: Yeah, yeah, precisely. So the software we built is in

181
00:10:26,399 --> 00:10:30,639
response to this, the need in events sourcing in particular

182
00:10:30,679 --> 00:10:33,559
where you need to communicate between different components, or sometimes

183
00:10:33,639 --> 00:10:35,879
you need to kick off as a synchronous process. So

184
00:10:36,200 --> 00:10:38,600
you know, if you have a click event on the

185
00:10:38,639 --> 00:10:40,960
front end, you process it right then and there, right

186
00:10:40,960 --> 00:10:45,039
in memory. Right, that's fine, cool, done right. But in

187
00:10:45,080 --> 00:10:47,960
the case of a sign up, you might need to

188
00:10:47,960 --> 00:10:50,279
send a welcome email and you don't want to do

189
00:10:50,320 --> 00:10:55,120
that in the same request a day later, and you

190
00:10:55,159 --> 00:10:57,720
want to kick off a process that is a synchronous

191
00:10:58,000 --> 00:11:00,639
And you might have sometimes where you need one service

192
00:11:00,679 --> 00:11:03,759
to understand that, hey, this person signed up, they have

193
00:11:04,440 --> 00:11:08,320
this hash password that they stored in the identity service.

194
00:11:08,639 --> 00:11:11,600
I'm the authentication service or the API gateway, so I

195
00:11:11,639 --> 00:11:14,159
need to know what the hash password of someone is

196
00:11:14,200 --> 00:11:16,279
and I need to listen to those events. So this

197
00:11:16,360 --> 00:11:22,000
whole produced consume a pattern or publish, subscribe. When you're

198
00:11:22,000 --> 00:11:23,759
doing it on the front end, you can do it

199
00:11:23,919 --> 00:11:26,039
in memory, all of it in one place, where this

200
00:11:27,480 --> 00:11:30,720
queue of events is just one very big queue, or

201
00:11:30,799 --> 00:11:32,519
not one very big que but one very easy to

202
00:11:32,519 --> 00:11:36,120
process queue, single threaded. Whereas when you want to distribute

203
00:11:36,120 --> 00:11:38,919
things and scale them and partition them so that you

204
00:11:38,960 --> 00:11:40,840
can paralyze your work.

205
00:11:41,440 --> 00:11:42,639
Speaker 5: Doing that is complicated.

206
00:11:43,000 --> 00:11:44,840
Speaker 4: So what we do is we act as a bridge

207
00:11:45,080 --> 00:11:47,200
where you say, look, this is where my events are

208
00:11:47,200 --> 00:11:49,320
being stored, and this is where I want them to

209
00:11:49,320 --> 00:11:51,679
be processed and everything in between.

210
00:11:52,240 --> 00:11:54,159
Speaker 5: We just make it work.

211
00:11:54,200 --> 00:11:56,879
Speaker 4: So those pipes as well as the ingress and the egress,

212
00:11:57,399 --> 00:11:59,879
we have that out of the box with correctness guarantees.

213
00:12:00,120 --> 00:12:01,759
And that's the premise of the product that it saves

214
00:12:01,799 --> 00:12:04,720
you a lot of time from having to build those yourselfs.

215
00:12:04,320 --> 00:12:08,799
Speaker 3: So does this like the Amber also provide like you said,

216
00:12:08,919 --> 00:12:14,759
just logging for example, sending mails or passward so you

217
00:12:14,799 --> 00:12:18,240
also provide some boilerplate even sourcing as well, or it

218
00:12:18,440 --> 00:12:21,240
just the you know, to you just pass the data

219
00:12:21,279 --> 00:12:22,519
and handle the data.

220
00:12:23,240 --> 00:12:25,320
Speaker 5: Yeah, the latter. So we just we focus.

221
00:12:25,480 --> 00:12:30,399
Speaker 4: We have one laser focused goal of making that experience

222
00:12:30,480 --> 00:12:33,480
really easy. Because people will have all sorts of different schemas.

223
00:12:33,679 --> 00:12:36,440
They might have all sorts of actions, and what we

224
00:12:36,519 --> 00:12:38,440
do is we give you a layer that allows you

225
00:12:38,519 --> 00:12:43,240
to simplify doing whatever action you want. Two things that

226
00:12:43,320 --> 00:12:46,679
engineers are very used to writing to a database and

227
00:12:46,720 --> 00:12:49,600
respond to AHTDP requests. Everybody and engineer in the world

228
00:12:49,679 --> 00:12:51,840
can do those two things. So we are taking those

229
00:12:51,840 --> 00:12:54,080
as APIs so that then if you want to send

230
00:12:54,080 --> 00:12:56,080
a mail, if you want to connect to Mailchimp, if

231
00:12:56,120 --> 00:12:58,200
you want to connect to Snowflake, if you want to

232
00:12:58,399 --> 00:12:59,919
whatever you want to do, if you want to connect

233
00:12:59,919 --> 00:13:02,679
to your own database, to another database, to a search database,

234
00:13:03,080 --> 00:13:03,639
all of that is.

235
00:13:03,639 --> 00:13:03,960
Speaker 5: Up to you.

236
00:13:04,600 --> 00:13:07,000
Speaker 4: But we give you the guarantees that you will get

237
00:13:07,039 --> 00:13:09,039
the messages. You will get them in order, you will

238
00:13:09,039 --> 00:13:11,240
get them in a scalable fashion. We will not bring

239
00:13:11,279 --> 00:13:15,799
your system down. It's obviously communicating securely. All of those

240
00:13:15,840 --> 00:13:18,320
things that normally take you months to do, we do

241
00:13:18,440 --> 00:13:20,799
them for you in five minutes, where you just say

242
00:13:20,879 --> 00:13:21,919
this is my configuration.

243
00:13:22,480 --> 00:13:23,879
Speaker 5: Bam, magic, It's done.

244
00:13:25,679 --> 00:13:30,240
Speaker 6: I wanted to talk about the actual.

245
00:13:31,440 --> 00:13:33,360
Speaker 2: Implementation more different.

246
00:13:33,759 --> 00:13:37,399
Speaker 6: Let's say, so we talked about event sourcing, and I

247
00:13:37,440 --> 00:13:43,080
have to confess that before our today's episode started, I

248
00:13:43,080 --> 00:13:46,759
didn't know what even sourcing meant. But when I read

249
00:13:46,799 --> 00:13:48,840
a bit about it, I understood that I kind of

250
00:13:48,919 --> 00:13:51,600
knew about it, that just didn't know what it was called.

251
00:13:52,960 --> 00:13:56,039
So and I think this part will be also useful

252
00:13:56,039 --> 00:13:56,960
for the listeners.

253
00:13:58,159 --> 00:13:59,279
Speaker 2: Let's just clear it up.

254
00:13:59,559 --> 00:14:03,120
Speaker 6: I will try to explain what it is and you Louise,

255
00:14:03,200 --> 00:14:05,720
you know it better, please correct me and let me

256
00:14:05,759 --> 00:14:10,039
know if that is correct. So figure out if that's true. So, yeah,

257
00:14:10,279 --> 00:14:14,679
essentially it's a way of storing the state. And I'm

258
00:14:14,679 --> 00:14:16,759
saying it an absurct plate, doesn't matter where it is.

259
00:14:16,799 --> 00:14:18,600
But usually of course it goes on the back end

260
00:14:18,639 --> 00:14:22,559
because they have a database and instead of just saving

261
00:14:22,679 --> 00:14:26,759
your let's say current or latest state. Instead of just

262
00:14:26,840 --> 00:14:31,039
having a database that says, okay, the user is this name,

263
00:14:31,200 --> 00:14:34,799
this last name, this password, and so on, you state,

264
00:14:35,879 --> 00:14:38,960
you save snapshots of everything that has ever happened to

265
00:14:39,080 --> 00:14:43,600
a user, right, So essentially you get events like change password,

266
00:14:43,720 --> 00:14:46,679
user changed password that means something in terms of how

267
00:14:46,720 --> 00:14:50,080
the data change. You have like the user registered, user

268
00:14:50,240 --> 00:14:52,919
disabled their account, and so on and so on, and.

269
00:14:52,840 --> 00:14:54,720
Speaker 2: You store these events.

270
00:14:55,039 --> 00:14:59,600
Speaker 6: You keep them in this consequential state so that you

271
00:14:59,600 --> 00:15:03,759
can so sort of look up when what happened, right,

272
00:15:04,039 --> 00:15:06,879
and you can like reconstruct.

273
00:15:06,480 --> 00:15:09,200
Speaker 2: A situation of how the state looks.

274
00:15:09,200 --> 00:15:11,159
Speaker 6: You can take a look at how the state looks

275
00:15:11,240 --> 00:15:14,960
right now, right, and you can also say, like what

276
00:15:15,360 --> 00:15:18,960
did this user look like seven days ago, for example,

277
00:15:19,120 --> 00:15:22,639
before they change the password or disabled the contents.

278
00:15:22,240 --> 00:15:26,480
Speaker 2: On let me know if that's the correct understanding.

279
00:15:27,279 --> 00:15:29,399
Speaker 5: Yeah, that understanding is spot on.

280
00:15:30,440 --> 00:15:32,480
Speaker 4: I think in practice it differs a little bit in

281
00:15:32,600 --> 00:15:36,519
that this time machine functionality, we don't use it as often,

282
00:15:36,519 --> 00:15:39,879
so people love talking about this one and the reading

283
00:15:39,919 --> 00:15:42,039
material that you probably looked at. It's one of the

284
00:15:42,039 --> 00:15:45,799
things that everybody loves to preach about. But really need,

285
00:15:45,879 --> 00:15:47,960
right is you need your current state, So there's no

286
00:15:48,039 --> 00:15:50,399
getting away from that. You still need to know what

287
00:15:50,519 --> 00:15:53,720
if someone's current half password or what is someone's current

288
00:15:53,799 --> 00:15:56,759
user name, what is someone's current email, how many parks

289
00:15:56,799 --> 00:16:00,000
have they bought? What is their credit balance, their debit,

290
00:16:00,399 --> 00:16:04,080
those sort of things. But the advantage with event sourcing

291
00:16:04,120 --> 00:16:07,799
is that you can decouple all these concerns. So normally

292
00:16:08,320 --> 00:16:11,720
you would have one big user table that says this

293
00:16:11,799 --> 00:16:14,559
user has these properties, right, But sometimes they might mean

294
00:16:14,600 --> 00:16:17,840
different things. So for example, you might have what someone's

295
00:16:17,879 --> 00:16:21,039
email is and whether it's confirmed or not confirmed, right,

296
00:16:21,360 --> 00:16:23,480
Whereas if you have the events that say, hey, this

297
00:16:23,840 --> 00:16:26,720
person asked to register with his email and then they

298
00:16:26,759 --> 00:16:29,960
confirmed it, that information is very precise, right, and you

299
00:16:30,000 --> 00:16:32,639
don't have to have some weird interpretation of If the

300
00:16:32,679 --> 00:16:35,159
table looks like this, then it means this. So with

301
00:16:35,240 --> 00:16:40,440
event sourcing, you're inverting the concept of you know, what's

302
00:16:40,440 --> 00:16:43,840
happening in your application from going to this really fuzzy

303
00:16:44,279 --> 00:16:47,000
way where you can really distinguish what's in your data storage,

304
00:16:47,200 --> 00:16:50,879
to being very explicit about what's happening. And the main function,

305
00:16:50,960 --> 00:16:54,759
of course is to convert into current state, not quite

306
00:16:55,360 --> 00:16:58,279
to do this time machine kind of traveling, and that's good.

307
00:16:58,320 --> 00:17:00,480
You can still use it for that, and you can

308
00:17:00,600 --> 00:17:03,240
run some nice analytics on it and it works out

309
00:17:03,320 --> 00:17:05,720
very nicely for that. But the idea is that by

310
00:17:05,759 --> 00:17:09,200
being explicit about what's happening in your application, it's a

311
00:17:09,240 --> 00:17:12,359
lot easier to reason about how to build that application. So,

312
00:17:12,440 --> 00:17:15,559
for example, if you are signing up and you want

313
00:17:15,599 --> 00:17:17,880
to have a store of what you know, just a

314
00:17:17,920 --> 00:17:21,519
simple map of this user, idea has this hash password,

315
00:17:21,559 --> 00:17:24,559
so that when you're doing authentication you can just very

316
00:17:24,559 --> 00:17:26,799
clearly look user I D matches this password.

317
00:17:27,079 --> 00:17:28,960
Speaker 5: Great if you have.

318
00:17:29,039 --> 00:17:31,319
Speaker 4: A table that has a bunch of other fields and

319
00:17:31,359 --> 00:17:35,039
that has different functionality in it, and you know, you

320
00:17:35,160 --> 00:17:38,079
might have old passwords that you're storing in there just

321
00:17:38,119 --> 00:17:41,920
to check that someone doesn't sign up again with the

322
00:17:41,960 --> 00:17:45,440
same or doesn't change their password to an old password.

323
00:17:45,920 --> 00:17:48,480
Speaker 5: If you're doing this kind of stuff, it gets very.

324
00:17:48,400 --> 00:17:52,599
Speaker 4: Unwieldy when you have so many different functionalities and you

325
00:17:52,680 --> 00:17:54,920
have one big state and you don't know how to

326
00:17:54,960 --> 00:17:57,759
interpret it. Whereas if you're explicit about your events and

327
00:17:57,799 --> 00:17:59,839
you get it wrong, all you have to do is

328
00:17:59,839 --> 00:18:02,279
you build a new model that interprets those events and

329
00:18:02,279 --> 00:18:03,839
you say, you know what, I'm going to switch from

330
00:18:03,839 --> 00:18:06,680
this old model to this new model. And that's the

331
00:18:06,680 --> 00:18:11,079
big advantage with events sourcing because it improves your system

332
00:18:11,160 --> 00:18:15,240
so that it's more understand understandable. And in turn, what

333
00:18:15,319 --> 00:18:18,319
that does is in the real world application, you as

334
00:18:18,359 --> 00:18:20,680
an engineer can go a lot faster because you don't

335
00:18:20,680 --> 00:18:22,200
have to understand absolutely everything.

336
00:18:22,240 --> 00:18:24,599
Speaker 5: You just have to understand the specific feature you're working on.

337
00:18:26,599 --> 00:18:29,240
Speaker 6: My big takeaway from what you just said is that

338
00:18:29,359 --> 00:18:33,920
I don't need to store stupid bullian properties to confirm

339
00:18:34,000 --> 00:18:35,720
if the.

340
00:18:35,079 --> 00:18:39,279
Speaker 2: User has the or the confirms and stuffing. Just have

341
00:18:39,400 --> 00:18:39,839
the event.

342
00:18:39,920 --> 00:18:42,920
Speaker 6: If there has been no event of I don't know,

343
00:18:43,519 --> 00:18:46,880
disabling the account, then the user is enabled.

344
00:18:47,279 --> 00:18:49,880
Speaker 4: Right, yeah, exactly, And you can you know, you can

345
00:18:50,000 --> 00:18:52,599
build those models where you know you want to confirm

346
00:18:52,640 --> 00:18:54,960
what someone's current state is so you can still build those,

347
00:18:55,880 --> 00:18:59,920
but events essentially help you make impossible states impossible. If

348
00:18:59,920 --> 00:19:01,880
I can say it like that, you know how sometimes

349
00:19:02,960 --> 00:19:06,400
have different bullions and you know this bullion number one

350
00:19:06,480 --> 00:19:09,359
can only be true if bullion number two is false

351
00:19:09,640 --> 00:19:11,640
and you have this kind of weird state and events

352
00:19:11,680 --> 00:19:13,279
are thing. There's none of that where you have like

353
00:19:13,319 --> 00:19:15,440
some weird model. If you get your model wrong and

354
00:19:15,480 --> 00:19:17,160
you want to change it, you don't have to do migration.

355
00:19:17,440 --> 00:19:19,200
All you have to do is you have to reinterpret

356
00:19:19,240 --> 00:19:21,799
your events. And because those events are really explicit, you're

357
00:19:21,839 --> 00:19:24,200
not doing silly things exactly like you said, where you have,

358
00:19:24,599 --> 00:19:27,119
you know, a bullion of whether this person is activated,

359
00:19:27,119 --> 00:19:28,519
and you have to understand what's going on.

360
00:19:28,559 --> 00:19:31,799
Speaker 6: I can I can see that in a very very

361
00:19:31,839 --> 00:19:35,319
small capacity in front. And for example, if I'm doing

362
00:19:35,480 --> 00:19:40,279
HTP requests and it's just an idea, I work with events.

363
00:19:40,319 --> 00:19:42,839
For example, I have report progress, I have error, I

364
00:19:42,880 --> 00:19:45,440
have loading states and so on, and if I were

365
00:19:45,480 --> 00:19:48,599
just using bullions, I would have I could possibly have

366
00:19:48,640 --> 00:19:51,440
this impossible state of there is an error I or

367
00:19:51,799 --> 00:19:54,599
request is finished and there is an error, but for

368
00:19:54,640 --> 00:19:58,240
some reason, the loading bullion is still true. Which doesn't

369
00:19:58,279 --> 00:20:01,240
make sense. It's not loading it more, there's error. But

370
00:20:01,960 --> 00:20:04,559
if I interpreted it like a stream of events, like

371
00:20:05,440 --> 00:20:10,160
loading started, and then you see this error or completion

372
00:20:10,240 --> 00:20:12,960
of the request and it's not possible to have this

373
00:20:13,200 --> 00:20:16,759
loading true or whatever if you're moving away from the stuff.

374
00:20:17,599 --> 00:20:20,559
I'm not saying it's like literally event sourcing, but it's

375
00:20:20,559 --> 00:20:21,400
like the same idea.

376
00:20:22,039 --> 00:20:24,079
Speaker 4: Yeah, it's the same idea. So, I mean, if you

377
00:20:24,119 --> 00:20:25,960
think about the functions that you use in the front

378
00:20:26,079 --> 00:20:28,200
end when you're using this type of pattern with events,

379
00:20:28,640 --> 00:20:31,400
you always have to return some state, right, so you

380
00:20:31,440 --> 00:20:36,400
get state into state. You cannot go from state into nothing, right.

381
00:20:37,440 --> 00:20:42,359
And if your state itself has a model that in

382
00:20:42,400 --> 00:20:44,440
the back end when you're doing events sourcing, if the

383
00:20:44,480 --> 00:20:48,119
state has something that you don't like, all you have

384
00:20:48,200 --> 00:20:50,720
to do is you have to take your events and

385
00:20:50,839 --> 00:20:55,960
essentially reinterpret them and say, my new model for state

386
00:20:56,079 --> 00:20:58,680
is going to be dismal, whereas in the old way

387
00:20:59,039 --> 00:21:01,920
you would have to mike rate your old state into

388
00:21:01,960 --> 00:21:05,079
your news state by doing some sort of crazy contraption

389
00:21:05,160 --> 00:21:07,200
where you interpret that state as like Okay, if this

390
00:21:07,319 --> 00:21:09,240
bullion is this, and this bullion is this, then this

391
00:21:09,400 --> 00:21:11,599
users and then you do this gigantic migration.

392
00:21:11,680 --> 00:21:12,440
Speaker 5: It's really painful.

393
00:21:12,440 --> 00:21:14,160
Speaker 4: You have to do it bit by bit, whereas if

394
00:21:14,200 --> 00:21:17,759
you just have to rewrite the function that interprets state

395
00:21:18,519 --> 00:21:20,720
conversion from old state to news state, that's much easier

396
00:21:20,720 --> 00:21:20,880
to do.

397
00:21:22,319 --> 00:21:25,680
Speaker 2: This makes a lot of sense. I actually kind of

398
00:21:25,799 --> 00:21:26,119
like it.

399
00:21:26,599 --> 00:21:30,599
Speaker 6: Although this does create lots of stuff in the storage

400
00:21:30,599 --> 00:21:34,720
where you store the events, right, it was very more redundant.

401
00:21:35,119 --> 00:21:39,559
Speaker 4: Yeah, you would think that that it is considerably more redundant,

402
00:21:39,640 --> 00:21:42,920
but in general, you get I mean, it's really hard

403
00:21:42,960 --> 00:21:45,599
to give you a hard estimate, right, but I would

404
00:21:45,599 --> 00:21:48,079
say that your storage would go by you know, maybe

405
00:21:48,319 --> 00:21:51,960
five to ten x because you're now storing history if

406
00:21:52,519 --> 00:21:55,319
you were in a position where you weren't previously storing history.

407
00:21:55,720 --> 00:21:58,640
But a lot of applications, what they do they'll have

408
00:21:58,720 --> 00:22:01,839
a user table and someone comes in from compliance and

409
00:22:01,880 --> 00:22:04,880
they'll say, you know what, I need to have an audiologue.

410
00:22:05,119 --> 00:22:08,319
And then what they do is every time the road changes,

411
00:22:08,680 --> 00:22:11,440
they store a new copy of that role. So now

412
00:22:11,480 --> 00:22:14,119
they have a table that has every single version of

413
00:22:14,119 --> 00:22:17,160
that row you've ever had. The problem is that now

414
00:22:17,279 --> 00:22:20,079
that pattern is considerably worse because now you're gonna go

415
00:22:20,160 --> 00:22:23,279
from storing your state to every time the state changes,

416
00:22:23,480 --> 00:22:25,759
you're gonna store your old state and your new state,

417
00:22:25,920 --> 00:22:29,079
not just a diff Imagine if in a commit right

418
00:22:29,119 --> 00:22:31,680
you were storing the previous code base every time, you

419
00:22:31,680 --> 00:22:34,839
don't do it like that, right, you store diffs every time.

420
00:22:34,920 --> 00:22:38,039
So in events sourcing, you're essentially doing a diff of

421
00:22:38,480 --> 00:22:41,079
every time that my system is changing is changing with

422
00:22:41,160 --> 00:22:44,759
this deferential event in. This means that even though sure

423
00:22:44,799 --> 00:22:47,160
you're storing the history, you at least don't stort it

424
00:22:47,160 --> 00:22:51,000
in such a way where you're being redundant. So if

425
00:22:51,039 --> 00:22:53,240
you ever are in a normal application and you need

426
00:22:53,279 --> 00:22:56,640
to have some sort of auditability, your storage might go

427
00:22:56,759 --> 00:22:59,039
up by one hundred x, whereas an event sourcing, you know,

428
00:22:59,079 --> 00:23:00,920
maybe you'll get five extra tens.

429
00:23:02,359 --> 00:23:06,519
Speaker 6: I see that it also is way more explicit, Right,

430
00:23:06,720 --> 00:23:08,880
So if I were just to start the history of

431
00:23:09,079 --> 00:23:12,920
one row, there would be like a million ways of

432
00:23:12,960 --> 00:23:16,480
interpreting why certain day changed. Right, So I don't know

433
00:23:16,559 --> 00:23:19,079
if the user changed their status, or an edmin changed

434
00:23:19,119 --> 00:23:21,920
their status, or something else entirely happened. I just know

435
00:23:22,039 --> 00:23:24,559
that one role was true and now it's false, but

436
00:23:24,880 --> 00:23:26,400
could mean a bunch.

437
00:23:26,200 --> 00:23:30,319
Speaker 4: Of things yep, exactly, So even if you know who

438
00:23:30,359 --> 00:23:31,640
did it, you don't know the reason.

439
00:23:32,839 --> 00:23:33,079
Speaker 1: Yeah.

440
00:23:33,720 --> 00:23:34,799
Speaker 2: Yeah.

441
00:23:35,680 --> 00:23:42,640
Speaker 1: Also another another nice saying is the scalability benefits of

442
00:23:42,799 --> 00:23:50,000
event sourcing because by leveraging events as your main source

443
00:23:50,079 --> 00:23:56,920
of state creation, then you can basically scale infinitely because

444
00:23:57,440 --> 00:24:02,000
you start from the assumption that every event is immutable.

445
00:24:03,000 --> 00:24:07,319
Like it's not like we currently approach state in the

446
00:24:07,359 --> 00:24:09,440
back end, which is there's the current state and we're

447
00:24:09,440 --> 00:24:14,079
always making mutations and inserting or updating or deleting things

448
00:24:14,079 --> 00:24:18,759
from there. You you just think of you have this

449
00:24:19,079 --> 00:24:24,200
long stream of events and they are in a sequence.

450
00:24:25,160 --> 00:24:27,720
I would say I would just be careful to stay

451
00:24:27,759 --> 00:24:32,480
timeline because Louise can tell a little bit more about that. Like,

452
00:24:32,519 --> 00:24:35,680
one of the common mistakes that people do at events

453
00:24:35,720 --> 00:24:41,440
surcing is using a timestamp to determine the order of

454
00:24:41,480 --> 00:24:45,440
the event, because that actually can lead to two issues.

455
00:24:45,519 --> 00:24:50,160
It's not we can't one hundred percent rely on time stamps,

456
00:24:50,440 --> 00:24:52,519
but Louise can tell a little bit more about that.

457
00:24:52,559 --> 00:24:57,079
But it's basically like, you have this sequential list of

458
00:24:57,200 --> 00:25:02,000
events that are immutable, so you can store them in databases.

459
00:25:02,039 --> 00:25:06,440
There are built to deal with the fact that the

460
00:25:06,519 --> 00:25:10,559
data doesn't need to be deleted or mutated, like of

461
00:25:10,599 --> 00:25:12,759
course you want to have the ability of doing that

462
00:25:12,799 --> 00:25:14,680
in case you need to do a migration or something.

463
00:25:14,720 --> 00:25:22,640
But the database can be very optimized for replication and

464
00:25:22,960 --> 00:25:28,039
reading the events. So that allows for a lot of optimizations.

465
00:25:28,079 --> 00:25:31,279
And then you can just listen to the database of

466
00:25:31,319 --> 00:25:37,839
events and create other and have other databases that generate

467
00:25:37,960 --> 00:25:43,680
what we would call queries, like they're basically views of

468
00:25:43,799 --> 00:25:47,279
your state that are optimized just for reading the state,

469
00:25:47,839 --> 00:25:52,240
and they are generated based on parsing the events that

470
00:25:52,279 --> 00:25:56,839
are relevant to generating that state. So it's very very scalable.

471
00:25:56,880 --> 00:26:02,640
There are multiple ways of like it's scaling or infrastructure

472
00:26:02,680 --> 00:26:09,319
to handle billions of users. But you also you lose

473
00:26:09,359 --> 00:26:12,240
a little bit of the what would be the technical term,

474
00:26:12,240 --> 00:26:15,519
and you get eventual consistency. Is that correctly, So you

475
00:26:15,559 --> 00:26:18,680
don't get like something that happens immediately, but you know

476
00:26:18,759 --> 00:26:21,119
that eventually the state is going to be what it's

477
00:26:21,160 --> 00:26:21,799
supposed to be.

478
00:26:23,079 --> 00:26:26,240
Speaker 4: Yeah, so in distributed systems, so for context as well.

479
00:26:26,279 --> 00:26:29,279
My background is mainly in distributed systems and back end

480
00:26:29,799 --> 00:26:36,440
and when you are paralyzing some work, you you cannot

481
00:26:37,000 --> 00:26:41,200
paralyze work that is acting on the same thing.

482
00:26:41,359 --> 00:26:41,519
Speaker 5: Right.

483
00:26:41,559 --> 00:26:44,759
Speaker 4: So for example, if you're doing something like calculating the

484
00:26:44,960 --> 00:26:48,680
digits of pie and you're you know, you need to

485
00:26:49,440 --> 00:26:54,880
your competition needs to be increasingly more accurate you, I mean,

486
00:26:54,880 --> 00:26:56,680
maybe I'm a Semusian would correct me here. I don't

487
00:26:56,680 --> 00:26:59,680
think that there's a way to paralyze it. And if

488
00:26:59,720 --> 00:27:03,279
you're calculating, for example, a hash of a hash of

489
00:27:03,279 --> 00:27:05,519
a hash of a hash of a hash, you can't

490
00:27:05,559 --> 00:27:08,960
really paralyze that, right, because you're acting on a single thing.

491
00:27:09,240 --> 00:27:10,480
Speaker 5: So an event sourcing, what.

492
00:27:10,400 --> 00:27:15,759
Speaker 4: We do is we say, we very explicitly say what

493
00:27:16,119 --> 00:27:19,720
our unit of paralalism is. So, for example, if you

494
00:27:19,839 --> 00:27:22,759
have it's kind of like an entity, but not really,

495
00:27:22,799 --> 00:27:26,279
we call them argates and events sourcing, but for the

496
00:27:26,319 --> 00:27:28,319
purpose of today, I'm just going to call them entities.

497
00:27:28,559 --> 00:27:30,160
And if you have an entity and you have events

498
00:27:30,359 --> 00:27:34,640
on that entity, and you are acting just on the entity,

499
00:27:35,039 --> 00:27:38,880
then you can paralyze the work across many entities, right,

500
00:27:38,880 --> 00:27:41,039
So one server could be acting even on one entity

501
00:27:41,279 --> 00:27:43,160
on its own. So when it's building a view model

502
00:27:43,480 --> 00:27:47,839
of the world, you have a single server processing subset

503
00:27:47,880 --> 00:27:50,000
of the entities. And that means that the more servers

504
00:27:50,039 --> 00:27:53,400
you are, the more entities you can process. Now, something

505
00:27:53,440 --> 00:27:55,880
to note is that when it comes to an entity,

506
00:27:56,480 --> 00:27:59,559
you do get a consistency boundary there. So you can say,

507
00:27:59,640 --> 00:28:04,039
I'm going to do a transaction where when you're storing events,

508
00:28:04,279 --> 00:28:07,240
where I'm going to make sure that before I add

509
00:28:07,279 --> 00:28:11,200
an event to withdraw two hundred dollars, I want to

510
00:28:11,200 --> 00:28:13,599
make sure that this person has deposited at least two

511
00:28:13,640 --> 00:28:14,359
hundred dollars.

512
00:28:14,680 --> 00:28:15,720
Speaker 5: And you can do that.

513
00:28:16,240 --> 00:28:17,960
Speaker 4: It's there's a little bit of nuance on how you

514
00:28:17,960 --> 00:28:20,319
would do it, but you essentially can do that on

515
00:28:20,359 --> 00:28:23,160
a transactional basis, and you can also say I'm going

516
00:28:23,200 --> 00:28:28,480
to transactionally do things between two two different entities. But

517
00:28:28,599 --> 00:28:31,359
the important thing is that you have now made very

518
00:28:31,400 --> 00:28:35,400
explicit what your unit of peralism is. So in a

519
00:28:35,440 --> 00:28:38,599
traditional system where you have states stored in some tables,

520
00:28:38,880 --> 00:28:41,240
you would have to figure out how do I make

521
00:28:41,599 --> 00:28:44,839
my tables scale, how can I distribute this, how can

522
00:28:44,880 --> 00:28:48,200
I shard my database right? And there are some solutions

523
00:28:48,200 --> 00:28:49,920
that help you with this, but in this case, you're

524
00:28:49,960 --> 00:28:52,759
making it extremely explicit. So it allows you to scale

525
00:28:53,039 --> 00:28:56,839
on the view side because you can build your view

526
00:28:56,880 --> 00:29:01,640
models in parallel, almost arbitrarily across however many servers you want.

527
00:29:02,119 --> 00:29:04,480
And then on the right side, it gives you a

528
00:29:04,559 --> 00:29:06,839
unit of parallysm where you have to be very explicit

529
00:29:06,920 --> 00:29:11,039
about what you're doing transactions and if you need to

530
00:29:11,079 --> 00:29:13,519
go even one level higher, and you know, scale the

531
00:29:13,599 --> 00:29:16,039
right side quite a bit. And we have this thing

532
00:29:16,079 --> 00:29:18,519
called event stores for where we store our events. If

533
00:29:18,519 --> 00:29:20,640
you need to scale that, then there are ways of

534
00:29:20,680 --> 00:29:23,119
sharding it right. But the nice thing is that you're

535
00:29:23,200 --> 00:29:25,279
usually using the right tool for the job because on

536
00:29:25,319 --> 00:29:27,839
the right side you generally don't need to scale that much.

537
00:29:28,079 --> 00:29:30,839
If you're doing ten thousand events per second, like transactional

538
00:29:31,039 --> 00:29:34,039
actual events where people are editing their state, you're a

539
00:29:34,079 --> 00:29:37,559
really big company, right And most companies, even I've worked

540
00:29:37,559 --> 00:29:41,079
with companies that are doing finance or logistics, even they

541
00:29:41,279 --> 00:29:44,039
don't have more than one hundred events per second. So

542
00:29:45,480 --> 00:29:48,480
if they only have one hundred events per second, they

543
00:29:48,480 --> 00:29:50,720
are completely fined with having a place where they store

544
00:29:50,759 --> 00:29:53,519
their events, which doesn't need it's a single server, right,

545
00:29:53,519 --> 00:29:54,720
a single poster systance.

546
00:29:55,000 --> 00:29:56,839
Speaker 5: But this might not be the case for their views.

547
00:29:57,039 --> 00:29:59,079
Speaker 4: Their views, they might have a lot of people viewing

548
00:29:59,119 --> 00:30:02,440
things all the time fetching the current state, or they

549
00:30:02,519 --> 00:30:05,599
might be building new views and processing old events that

550
00:30:05,680 --> 00:30:07,759
needs to scale and an event soort thing you separate

551
00:30:07,759 --> 00:30:10,279
it all together. But yeah, the system scales quite well

552
00:30:10,279 --> 00:30:13,279
from an infrastructure perspective. And the other thing, which I

553
00:30:13,279 --> 00:30:16,400
think is the onstole benefit, is that it scales from

554
00:30:16,400 --> 00:30:20,039
a team perspective, where because you're decoupling your system, people

555
00:30:20,119 --> 00:30:22,920
can work on different components without having to bother each other.

556
00:30:24,200 --> 00:30:26,799
Speaker 1: I think we could also talk a little bit more

557
00:30:26,839 --> 00:30:32,519
about how those which technologies actually are used for event

558
00:30:32,640 --> 00:30:37,440
sourcing generally, and how those things are wired up together.

559
00:30:37,640 --> 00:30:43,559
Like I briefly touch on the subject of separating the

560
00:30:43,559 --> 00:30:48,559
the querium and the actions, which I think is called

561
00:30:48,559 --> 00:30:53,279
the command layer if I recovery rrectly, So how is

562
00:30:53,319 --> 00:30:58,160
that generally done and which technologies are generally used? Like

563
00:30:58,240 --> 00:31:00,759
I also mentioned that we could have a database. There

564
00:31:00,759 --> 00:31:06,839
are that is optimized for storing and distributing events. Which

565
00:31:07,319 --> 00:31:12,720
databases are generally used? Like what is the typical anatomy

566
00:31:12,839 --> 00:31:15,400
of a distributed system at a large company?

567
00:31:16,039 --> 00:31:22,200
Speaker 5: I love the word anatomy, it's so fitting the typical.

568
00:31:22,359 --> 00:31:25,359
Speaker 4: So I'll give you the components and then I'll dive

569
00:31:25,400 --> 00:31:27,720
a little bit deeper into them. So first of all,

570
00:31:27,759 --> 00:31:31,279
you need web servers, right. You need web servers as

571
00:31:31,279 --> 00:31:35,680
the API for some front end, right. And you need

572
00:31:36,160 --> 00:31:39,400
a place to store your events, and you need places

573
00:31:39,440 --> 00:31:41,119
to store your views, your.

574
00:31:41,279 --> 00:31:43,359
Speaker 5: Read models we call them more projections.

575
00:31:44,200 --> 00:31:47,720
Speaker 4: And you need a way to connect the place where

576
00:31:47,759 --> 00:31:49,920
you store your events with the place where you're going

577
00:31:49,960 --> 00:31:54,039
to be processing to build those views. And so if

578
00:31:54,079 --> 00:31:55,559
you think of it as a chain, right, you have,

579
00:31:55,920 --> 00:31:57,599
first of all, you have the web servers, then you

580
00:31:57,680 --> 00:32:00,559
have the events store. Then after that you have some

581
00:32:00,599 --> 00:32:04,519
sort of middleware connection with some queuing system that is

582
00:32:04,559 --> 00:32:07,119
then offloading things to the next part, which is the

583
00:32:07,160 --> 00:32:09,160
workers that are going to be building the view models.

584
00:32:09,440 --> 00:32:11,920
Then the view models themselves are different databases where you

585
00:32:11,920 --> 00:32:14,079
can pick whatever you want, and then the web servers

586
00:32:14,119 --> 00:32:16,440
against that we're at the beginning connects to those view models.

587
00:32:16,599 --> 00:32:19,359
So in the first layer and web servers, you can

588
00:32:19,480 --> 00:32:22,079
use whatever you want, and any any language that can

589
00:32:22,119 --> 00:32:24,759
connect to a database will will do, and that can

590
00:32:24,799 --> 00:32:28,680
receive ACDP requests. On the database side, where you're storing

591
00:32:28,680 --> 00:32:33,039
your events, you normally go for a single leader database

592
00:32:33,119 --> 00:32:37,640
unless you need extreme scale if you need, because it

593
00:32:37,720 --> 00:32:41,200
provides you some very nice transactional ways of doing things

594
00:32:41,240 --> 00:32:43,119
that you don't have to implement yourself if you're using

595
00:32:43,119 --> 00:32:45,799
no sql, So for that you would use my sqel

596
00:32:45,920 --> 00:32:50,160
Postcris SQL server. There are a couple of events sourcing

597
00:32:50,240 --> 00:32:54,039
database that are just specific storages for events sourcing called

598
00:32:54,319 --> 00:32:57,240
events re dB and Exonic. There are a couple of

599
00:32:57,400 --> 00:32:59,759
libraries as well that you can take to make a

600
00:33:00,039 --> 00:33:03,640
postgris look more like those databases. In my experience, I

601
00:33:03,680 --> 00:33:06,599
haven't had a need. In fact, if anything, there are

602
00:33:06,599 --> 00:33:11,119
a couple of missing features out of the specialty providers,

603
00:33:11,240 --> 00:33:15,799
So I tend to steer for using postgris first, my

604
00:33:15,920 --> 00:33:18,839
Squel second, and then sql server if it's a Microsoft

605
00:33:18,880 --> 00:33:22,640
shop and they love using everything Microsoft anyway.

606
00:33:22,720 --> 00:33:23,440
Speaker 5: So that's on the.

607
00:33:25,319 --> 00:33:29,279
Speaker 4: Event store, on the worker that is going to be

608
00:33:29,480 --> 00:33:32,519
consuming from the event store and putting things into a queue. Again,

609
00:33:32,559 --> 00:33:34,319
it can be anything as long as it can connect

610
00:33:34,319 --> 00:33:37,559
to a database. For the Q itself, you would use

611
00:33:37,559 --> 00:33:41,559
something like Kafka or rabbit MQ. The problem with using

612
00:33:41,559 --> 00:33:44,079
something like rabbit mq, and it's a warning I give people,

613
00:33:44,279 --> 00:33:47,400
is that rabbit mq is ephemeral, So if you want

614
00:33:47,440 --> 00:33:50,079
to reload your events and process things from the beginning

615
00:33:50,079 --> 00:33:53,119
of time, you have to go bother your original events storre,

616
00:33:53,400 --> 00:33:56,240
which is why I recommend having a que that has

617
00:33:56,240 --> 00:33:59,440
not epherminal storage. Kafka works really well for this, but

618
00:33:59,480 --> 00:34:00,400
it is a very.

619
00:34:00,240 --> 00:34:02,920
Speaker 5: Painful to set up. That's why we build a company, right.

620
00:34:03,799 --> 00:34:07,079
Speaker 4: And then you have the layer that reads from the queue,

621
00:34:07,359 --> 00:34:09,920
and you would have a worker there as well. And

622
00:34:09,960 --> 00:34:14,280
for that again, anything anything goes, and what our job

623
00:34:14,280 --> 00:34:16,400
at Ambar has been right is to take those three

624
00:34:16,400 --> 00:34:21,000
middle parts, the worker that is reading from the events

625
00:34:21,119 --> 00:34:23,480
or putting it into the queue, and the queue then

626
00:34:23,559 --> 00:34:25,119
takes it to that other worker that is going to

627
00:34:25,119 --> 00:34:28,360
be doing some processing. We abstract those three points, right.

628
00:34:29,480 --> 00:34:31,960
And then for the re databases, you can have anything

629
00:34:31,960 --> 00:34:34,880
you want. You can use postcras, you can use elastic search,

630
00:34:34,920 --> 00:34:39,199
you can use DynamoDB. In general. For the views, I

631
00:34:39,280 --> 00:34:43,280
recommend using no sequel because in the views you want

632
00:34:43,320 --> 00:34:43,559
to be.

633
00:34:43,519 --> 00:34:44,800
Speaker 5: Able to rebuild them really quickly.

634
00:34:44,920 --> 00:34:46,920
Speaker 4: So if you make a mistake and you want to

635
00:34:46,960 --> 00:34:50,320
release a new bug fix, you don't and you're processing

636
00:34:50,320 --> 00:34:52,400
your events from the beginning of time, you want to

637
00:34:52,400 --> 00:34:54,239
be able to do let in parallel. And if you

638
00:34:54,280 --> 00:34:56,519
do it in parallel, but your database is a bottleneck

639
00:34:56,519 --> 00:35:00,320
where you're storing your views, then that's problematic. So if

640
00:35:00,360 --> 00:35:03,960
you choose a no SQL database uh, and you think about.

641
00:35:03,679 --> 00:35:06,159
Speaker 5: Consistency as well and about.

642
00:35:06,559 --> 00:35:10,760
Speaker 4: Doing things in a transactional way wherever you need, then

643
00:35:10,760 --> 00:35:12,960
that's fine. The database is gonna work, it's gonna scale.

644
00:35:13,480 --> 00:35:14,159
Speaker 5: I tend to go.

645
00:35:14,239 --> 00:35:17,039
Speaker 4: So if I were to pick my ideal stack, I

646
00:35:17,079 --> 00:35:19,239
would pick Postgress for storing events.

647
00:35:19,360 --> 00:35:22,440
Speaker 5: I would pick Dynamo DV for storing my views. Uh.

648
00:35:22,480 --> 00:35:24,679
And then obviously I'm biased, so I would pick Amber

649
00:35:24,760 --> 00:35:25,280
in the middle.

650
00:35:25,639 --> 00:35:28,119
Speaker 4: And if you have to know what we use in number,

651
00:35:28,119 --> 00:35:31,000
because number is obviously not just a magic box. Our

652
00:35:31,039 --> 00:35:36,519
connectors are written in a rust In Haskell stack uh,

653
00:35:36,559 --> 00:35:39,480
and we use Kafka as the as the middle will

654
00:35:39,639 --> 00:35:42,960
layer for the for the cues. But I think that

655
00:35:43,519 --> 00:35:47,480
the simplest way to to do this, Like if you're

656
00:35:47,559 --> 00:35:50,039
using Amber, you essentially not only have to pick your

657
00:35:50,199 --> 00:35:53,440
place with your store events, your web server, and your

658
00:35:53,960 --> 00:35:57,360
view model storage. Where I would pick Postgress, my favorite

659
00:35:57,400 --> 00:36:00,800
language for back end, and then I would pick a

660
00:36:01,280 --> 00:36:03,519
database for the view modals, which would just be dynamo, tob.

661
00:36:04,920 --> 00:36:08,440
Speaker 1: I think it's interesting that you mentioned that there is

662
00:36:08,480 --> 00:36:13,519
a database that is dedicated just for events searching, which

663
00:36:13,559 --> 00:36:18,039
is events stard B, but you actually don't recommend using it.

664
00:36:18,639 --> 00:36:19,480
Why is that the.

665
00:36:19,400 --> 00:36:24,760
Speaker 4: Case, Yeah, so you know it's because it's so. As engineers,

666
00:36:24,800 --> 00:36:26,639
I think it's a good product. But as engineers, we

667
00:36:26,679 --> 00:36:28,559
tend to use the right tool for the job, and

668
00:36:28,719 --> 00:36:30,960
the right tools for the job sometimes depends on what

669
00:36:31,039 --> 00:36:31,320
we know.

670
00:36:31,960 --> 00:36:35,000
Speaker 5: And I understand traditional.

671
00:36:34,559 --> 00:36:38,079
Speaker 4: Databases quite well because I have a very hefty computer

672
00:36:38,119 --> 00:36:43,440
science background, and there are capabilities that I don't have

673
00:36:43,800 --> 00:36:47,360
with events or dB. So it's more because one I

674
00:36:47,400 --> 00:36:49,760
know how to do things in traditional databases and two

675
00:36:49,760 --> 00:36:51,440
because there are some missing capabilities.

676
00:36:51,800 --> 00:36:54,920
Speaker 5: So the events urcing world can be quite dogmatic.

677
00:36:54,480 --> 00:36:57,800
Speaker 4: Where if you go into the forums or the discords

678
00:36:57,880 --> 00:37:00,719
or the slacks and you ask people questions, they will

679
00:37:00,719 --> 00:37:03,719
tell you must only do it this particular way. However,

680
00:37:04,440 --> 00:37:06,280
in practice, right you know, as engineers, we need to

681
00:37:06,320 --> 00:37:07,880
make tradeoffs, and everything's a tradeoff.

682
00:37:07,880 --> 00:37:09,679
Speaker 5: There are no silver bullets, and.

683
00:37:09,559 --> 00:37:13,280
Speaker 4: The problem with an database that specialized in events surcing

684
00:37:13,360 --> 00:37:15,280
is that they make a lot of those decisions for you.

685
00:37:15,639 --> 00:37:18,000
So if you ever need to break the rules, and

686
00:37:18,039 --> 00:37:19,559
you know why you're doing it, and you know that

687
00:37:19,599 --> 00:37:22,280
in this case, actually it's better to break the rule

688
00:37:22,320 --> 00:37:23,599
because if you don't break the rule, it's going to

689
00:37:23,679 --> 00:37:24,280
be much worse.

690
00:37:24,719 --> 00:37:25,000
Speaker 5: Then.

691
00:37:25,320 --> 00:37:27,760
Speaker 4: Those databases don't give you the flexibility to do that.

692
00:37:28,119 --> 00:37:32,039
And it's why I don't like the set schema, the

693
00:37:32,119 --> 00:37:35,119
fact that the APIs are meant to work a specific way.

694
00:37:35,800 --> 00:37:39,800
I cannot do a transaction with a separate with a

695
00:37:39,800 --> 00:37:44,559
separate table, and these type of things steer me away

696
00:37:44,559 --> 00:37:48,280
from a custom specialized database for events sourcing.

697
00:37:49,079 --> 00:37:52,599
Speaker 1: Gotcha, Okay, So it's not that it's a bad choice,

698
00:37:52,719 --> 00:37:56,960
is just a bit to opinionated. And also you have

699
00:37:57,000 --> 00:37:59,599
all this background that allows you to do whatever you

700
00:37:59,639 --> 00:38:02,119
want at a more general database.

701
00:38:02,679 --> 00:38:04,800
Speaker 4: Yeah, I would recommend for people that don't have the

702
00:38:04,840 --> 00:38:06,960
background to grab a nice library. So there are some

703
00:38:07,039 --> 00:38:10,320
nice libraries out there that will grab things, wrap things

704
00:38:10,360 --> 00:38:13,559
like postgrads or my sequel and give you something off

705
00:38:13,559 --> 00:38:15,400
the shelf or you don't have to figure out the schema.

706
00:38:16,920 --> 00:38:18,599
And also, you know, to be fair, if you are

707
00:38:18,599 --> 00:38:21,119
going to be doing events sourcing, instead of going for

708
00:38:21,199 --> 00:38:24,320
something that's like super opinionated and then you say, you

709
00:38:24,320 --> 00:38:25,840
know what, I'm not gonna learn about it because I'm

710
00:38:25,840 --> 00:38:28,679
just gonna use the opinionated tool. You're still gonna make mistakes,

711
00:38:28,840 --> 00:38:31,559
so it's better to get the extra education. And then

712
00:38:31,599 --> 00:38:33,199
in that case, you're probably gonna want to do your

713
00:38:33,239 --> 00:38:37,079
own schema anyway. So big word of warning here. Events

714
00:38:37,079 --> 00:38:38,880
sourcing is not a silver bullet. There's a lot of

715
00:38:38,920 --> 00:38:41,239
knowledge that you need to implement it. It helps a

716
00:38:41,280 --> 00:38:43,559
lot once you get that knowledge, but you should get

717
00:38:43,559 --> 00:38:44,199
that knowledge.

718
00:38:44,559 --> 00:38:50,239
Speaker 1: Okay, that makes a ton of sense. Well we are sorry,

719
00:38:50,239 --> 00:38:51,199
go ahead, sirretch No.

720
00:38:51,199 --> 00:38:55,360
Speaker 3: No, I was asking like it may be a practical question.

721
00:38:58,079 --> 00:39:02,159
Suppose someone has a small mid level e commas I'm

722
00:39:02,199 --> 00:39:04,840
just taking an example of e commerce application and they

723
00:39:04,840 --> 00:39:08,559
have already built it. Now they want to scale because

724
00:39:08,599 --> 00:39:11,920
they are getting some traffic and all. So according to

725
00:39:12,760 --> 00:39:16,440
if they want to now migrate from traditional way of

726
00:39:16,559 --> 00:39:21,360
handling data to event sourcing, like approx how many days

727
00:39:21,360 --> 00:39:24,119
are how many months it should take them.

728
00:39:23,920 --> 00:39:26,639
Speaker 5: To Yeah, so it is it is a big migration.

729
00:39:27,280 --> 00:39:29,960
Speaker 4: I don't Again, I'm an engineer, right, so I'm even

730
00:39:29,960 --> 00:39:33,840
though I'm the chief salesperson in the company, I'm very

731
00:39:33,880 --> 00:39:36,920
realistic I don't like over selling concepts or tools.

732
00:39:37,199 --> 00:39:39,719
Speaker 5: I want to give you the real deal. So look, the.

733
00:39:39,679 --> 00:39:42,320
Speaker 4: Way that you would do such a transition is you

734
00:39:42,360 --> 00:39:44,440
would do it piece by piece. So you would move

735
00:39:44,480 --> 00:39:47,760
the first piece over. If you have tools out there,

736
00:39:47,760 --> 00:39:50,639
like if you're using things like ambar, and you have

737
00:39:50,679 --> 00:39:54,480
a good library for postgris, and you have some good

738
00:39:54,480 --> 00:39:58,199
practices internally already where you're deploying infrastructure's code, so.

739
00:39:58,159 --> 00:40:00,079
Speaker 5: You already know how to use their from any you

740
00:40:00,119 --> 00:40:01,199
have some base knowledge.

741
00:40:01,599 --> 00:40:04,599
Speaker 4: Then adding event sourcing to a specific part of your application,

742
00:40:04,760 --> 00:40:08,679
like to your you know, to your order tracking for example,

743
00:40:09,039 --> 00:40:11,559
this should be relatively simple. It should be something that

744
00:40:11,599 --> 00:40:13,840
you can get done in two or three weeks with

745
00:40:14,280 --> 00:40:19,199
one or two people, if you know the theory right.

746
00:40:19,480 --> 00:40:21,679
The education part takes a little bit of time. I

747
00:40:21,719 --> 00:40:25,320
would say that for someone who's starting from scratch and

748
00:40:25,519 --> 00:40:29,000
they have some backend knowledge of how databases work and

749
00:40:29,000 --> 00:40:33,400
how web applications work, and maybe roughly two or three weeks,

750
00:40:33,480 --> 00:40:36,400
they can get to a very good position where if

751
00:40:36,400 --> 00:40:38,440
they've been you know, obviously those two or three weeks,

752
00:40:38,440 --> 00:40:40,400
you could spread them through the year, right, But it

753
00:40:40,440 --> 00:40:44,639
takes about that long to get to get into shape, right,

754
00:40:44,639 --> 00:40:46,559
So if you don't know anything about events sourcing, you're

755
00:40:46,920 --> 00:40:48,480
just coming into it right now, and you need to

756
00:40:48,480 --> 00:40:50,679
move the first part of your application over. It's going

757
00:40:50,760 --> 00:40:52,679
to take you two or three weeks of education and

758
00:40:52,719 --> 00:40:55,199
maybe another two or three weeks of implementation just to

759
00:40:55,280 --> 00:40:58,440
move one part, and thereafter you can start moving the

760
00:40:58,440 --> 00:40:59,400
other parts.

761
00:41:00,079 --> 00:41:00,840
Speaker 7: Yeah.

762
00:41:01,159 --> 00:41:04,679
Speaker 3: Yeah, completely makes sense. Like if you have a micro service,

763
00:41:04,760 --> 00:41:08,639
maybe just pick one part of that micro service and

764
00:41:08,679 --> 00:41:12,159
slowly Yeah, but all the services make sense.

765
00:41:12,480 --> 00:41:20,039
Speaker 1: Awesome. We are approaching forty forty five minutes, and I

766
00:41:20,079 --> 00:41:21,960
want to make sure that we are covering the most

767
00:41:22,000 --> 00:41:26,800
important pieces of the subject because this is way too extensive,

768
00:41:27,039 --> 00:41:31,559
like this could be an entire course instead of a podcast, which,

769
00:41:31,679 --> 00:41:35,719
by the way, it is a course. So Louise, maybe

770
00:41:35,719 --> 00:41:38,599
you can talk a little bit more about that. But

771
00:41:39,239 --> 00:41:42,519
I'm thinking I would like you to tell a little

772
00:41:42,519 --> 00:41:44,920
bit about the course that you guys have about even

773
00:41:45,000 --> 00:41:48,320
sourcing for those that may want to deeper dive into that.

774
00:41:48,960 --> 00:41:53,760
And also if there's anything that maybe we haven't asked

775
00:41:53,960 --> 00:41:56,239
and that you think it's really important that you want

776
00:41:56,239 --> 00:42:00,400
to touch upon or talk about for the audience.

777
00:42:01,079 --> 00:42:04,079
Speaker 4: Yeah, So I think I've mentioned a few of these,

778
00:42:04,119 --> 00:42:07,880
but I would like to put them together in one place.

779
00:42:07,920 --> 00:42:10,320
Speaker 5: So in events ersain, we have benefits and we have drawbacks.

780
00:42:10,360 --> 00:42:13,760
Speaker 4: Right, The benefits are that your application is much more auditable,

781
00:42:13,840 --> 00:42:16,440
it's a lot easier to debug things, it's a lot

782
00:42:16,480 --> 00:42:18,519
easier to fix the bugs. It gives you a lot

783
00:42:18,519 --> 00:42:22,000
of flexibility when your requirements change all the time. It

784
00:42:22,000 --> 00:42:26,119
can mad really complex domains, and it's much more explicit

785
00:42:26,159 --> 00:42:29,119
about how you're writing your application. It's easier to understand.

786
00:42:29,440 --> 00:42:32,519
But there are drawbacks. And the drawbacks are that you

787
00:42:32,599 --> 00:42:35,519
have to learn and you have to unlearn some things

788
00:42:35,559 --> 00:42:38,760
as well, so you have to know new patterns. You

789
00:42:38,880 --> 00:42:43,960
might not be able to get your team on board

790
00:42:44,039 --> 00:42:47,440
with this concept, and you have to convince people as

791
00:42:47,440 --> 00:42:49,039
well of using it, and you have to explain your

792
00:42:49,039 --> 00:42:55,000
reasoning why. And furthermore, the community is quite small at

793
00:42:55,000 --> 00:42:57,159
the time. So you know, if you take something like

794
00:42:57,239 --> 00:43:02,239
react or Angular, you know, you get so much attention

795
00:43:02,360 --> 00:43:04,679
over the world over these topics, whereas for events sourcing,

796
00:43:04,760 --> 00:43:07,679
it's a much smaller community. Like we have you know,

797
00:43:08,119 --> 00:43:11,599
specific there are no specific events sourcing conferences really that

798
00:43:11,719 --> 00:43:15,400
happen on a yearly basis. Sometimes some people organize some

799
00:43:16,000 --> 00:43:17,960
and you might have a couple of books here and

800
00:43:18,000 --> 00:43:21,599
there that reference it. The best the best material on

801
00:43:22,280 --> 00:43:24,840
events sourcing out there is spread all over the place.

802
00:43:25,400 --> 00:43:29,320
Speaker 5: And that means that if you want to if you want.

803
00:43:29,159 --> 00:43:32,159
Speaker 4: To get into event sourcing, you have to be a

804
00:43:32,159 --> 00:43:36,599
bit like uh, you know, like Luke Skywalker in Star Wars,

805
00:43:36,679 --> 00:43:38,960
right that ghosts and finds this little green man in

806
00:43:39,000 --> 00:43:41,599
the middle of nowhere and ask ask him a bunch

807
00:43:41,599 --> 00:43:43,920
of questions and then you know, finally learns the ways

808
00:43:43,960 --> 00:43:45,480
of the forest. Right, So it's a bit like that,

809
00:43:45,800 --> 00:43:48,159
and that experience is not great, and that's actually why

810
00:43:48,280 --> 00:43:50,760
why so this is a nice transition to the course

811
00:43:50,800 --> 00:43:53,400
that we think that there's a big need in the

812
00:43:53,400 --> 00:43:56,519
community to put everything together in one place and allow

813
00:43:56,599 --> 00:43:59,239
people to ask questions on a very ad hoc basis

814
00:43:59,239 --> 00:44:01,280
where they you know, they might be struggling with one

815
00:44:01,320 --> 00:44:03,920
part or another. So we put together a free course

816
00:44:03,960 --> 00:44:08,599
because we're really invested in this community, and essentially people

817
00:44:08,719 --> 00:44:13,159
just take a week to go through it. It's one

818
00:44:13,199 --> 00:44:14,519
and a half hours in the morning, one and a

819
00:44:14,559 --> 00:44:20,079
half hours in the afternoon, and after five days you

820
00:44:20,199 --> 00:44:21,880
get to be in a very good place, and we

821
00:44:21,920 --> 00:44:24,519
have a community as well on slack where people can

822
00:44:24,519 --> 00:44:28,440
come in and ask questions. But I don't want to

823
00:44:29,440 --> 00:44:32,119
overseell just all the benefits. I want to mention that

824
00:44:32,360 --> 00:44:36,079
it does take work to get onboarded, and it does

825
00:44:36,199 --> 00:44:43,920
take It does take a little bit of of perseverance. Right,

826
00:44:43,960 --> 00:44:46,280
It's not simple, and we want to make this better

827
00:44:46,320 --> 00:44:48,239
and you know, tomorrow, we want to make it a

828
00:44:48,280 --> 00:44:50,239
world where you can get started with events sourcing in

829
00:44:50,239 --> 00:44:50,760
five minutes.

830
00:44:51,039 --> 00:44:52,599
Speaker 5: But that's just not the reality today.

831
00:44:53,639 --> 00:44:56,039
Speaker 1: Yep. I love that, by the way, I love the

832
00:44:56,079 --> 00:45:00,559
fact that you guys offer this guide for people that

833
00:45:00,719 --> 00:45:04,440
want to learn more about it. I myself have tried

834
00:45:04,480 --> 00:45:07,880
to learn events searching for so many years, consumed so

835
00:45:08,039 --> 00:45:13,159
much content, and still when I did the course that

836
00:45:13,239 --> 00:45:17,960
you guys have, it was such a big difference from

837
00:45:18,000 --> 00:45:22,159
my previous attempts of learning. It is just there is

838
00:45:22,239 --> 00:45:27,639
no direct comparison, honestly, and the fact that this is

839
00:45:28,199 --> 00:45:32,079
at least currently offered for free, which I personally don't

840
00:45:32,119 --> 00:45:35,480
think it should always be offered for free. I think

841
00:45:35,519 --> 00:45:38,679
it should eventually start charging for it because it is

842
00:45:39,159 --> 00:45:42,679
a lot of valuable content. But yeah, the fact that

843
00:45:42,719 --> 00:45:46,400
it is currently offered for free. Is such a gigantic opportunity.

844
00:45:46,599 --> 00:45:51,360
Anyone that currently wants to learn should definitely check it out.

845
00:45:52,039 --> 00:45:56,239
By the way, how can people apply for that? Is

846
00:45:56,280 --> 00:46:01,039
that still open for people that want so?

847
00:46:01,079 --> 00:46:06,639
Speaker 4: Our domain is Ambar Alpha Mama, Bravo Alpha Romeo dot

848
00:46:06,719 --> 00:46:09,360
cloud and then the link for the course is just

849
00:46:09,480 --> 00:46:13,719
amber dot cloud slash ESC where ESC stands for Events

850
00:46:13,760 --> 00:46:14,400
Sourcing Course.

851
00:46:14,679 --> 00:46:18,119
Speaker 5: So we just head to that page. There's a registration.

852
00:46:19,159 --> 00:46:21,480
Speaker 4: The next session start next week and then the one

853
00:46:21,519 --> 00:46:23,800
after that, and we run it into time zone so

854
00:46:23,840 --> 00:46:24,559
that people from.

855
00:46:24,440 --> 00:46:27,480
Speaker 5: All over the world can join. So that's for free.

856
00:46:27,639 --> 00:46:31,599
Speaker 4: I think it will remain free for as long as

857
00:46:31,679 --> 00:46:34,039
the company remains small enough that we can afford to

858
00:46:35,320 --> 00:46:37,239
do it. I think at some point we might change it.

859
00:46:37,280 --> 00:46:39,960
But the benefit is that we are also getting customers

860
00:46:39,960 --> 00:46:42,559
out of it. So they're doing event sourcing, they come

861
00:46:42,599 --> 00:46:44,360
to us and they figure out, oh my gosh, you know,

862
00:46:44,400 --> 00:46:46,679
these people really know how to do this stuff, and

863
00:46:46,679 --> 00:46:49,679
then they use our technology, and obviously we.

864
00:46:49,559 --> 00:46:51,719
Speaker 5: Make money out of that, so we do it out.

865
00:46:51,599 --> 00:46:53,239
Speaker 4: Of the kindness of our hearts as well, but because

866
00:46:53,280 --> 00:46:57,119
we're also interested in getting customers eventually, so if and

867
00:46:57,199 --> 00:46:59,119
I think it will be the case that we get

868
00:46:59,320 --> 00:47:01,760
enough customers out of it to make it worth our while.

869
00:47:02,199 --> 00:47:04,239
As long as we can keep getting customers out of it,

870
00:47:04,320 --> 00:47:06,119
will keep it free. And it might be that that

871
00:47:06,159 --> 00:47:07,800
means that it's just free content forever.

872
00:47:10,320 --> 00:47:15,960
Speaker 1: Awesome, awesome, Well let's hope for that, all right, guys,

873
00:47:16,119 --> 00:47:19,639
Arman Subrette. Before we wrap up, do you have any

874
00:47:19,760 --> 00:47:22,440
specific questions you want to make for Louise.

875
00:47:24,199 --> 00:47:25,960
Speaker 3: Our Just think I really joined the court.

876
00:47:27,320 --> 00:47:30,360
Speaker 5: In the next one. Fantastic.

877
00:47:30,480 --> 00:47:31,039
Speaker 2: I would love.

878
00:47:31,400 --> 00:47:33,800
Speaker 6: I would love to say the same, but I'm swamped

879
00:47:33,840 --> 00:47:36,559
with different stuff. But I would definite to look into

880
00:47:36,599 --> 00:47:39,280
it because this at least the approach. I'm not working

881
00:47:39,320 --> 00:47:42,480
on the back hand, but I can see how this approach,

882
00:47:42,599 --> 00:47:46,920
this mindset can help solve lots of problems on the

883
00:47:46,960 --> 00:47:47,719
front end too.

884
00:47:48,320 --> 00:47:50,719
Speaker 2: I was just thinking, on the top of.

885
00:47:50,599 --> 00:47:52,960
Speaker 6: My head, what would I do with, for example, I

886
00:47:53,000 --> 00:47:59,119
had state management and tries to implement undo redo functionality

887
00:47:59,119 --> 00:48:01,840
on the big, bigger scale, Like I have a form

888
00:48:01,960 --> 00:48:04,519
that has important stuff and I want to be able

889
00:48:04,559 --> 00:48:08,039
to I want to give the user the ability to

890
00:48:08,199 --> 00:48:09,760
kind of like revert.

891
00:48:09,400 --> 00:48:12,880
Speaker 7: Back see what they did, maybe see history or something

892
00:48:13,400 --> 00:48:16,800
and I feel like storing the snippets of changes and

893
00:48:17,360 --> 00:48:22,920
using RXGS powers can like you can really simplify or code.

894
00:48:22,920 --> 00:48:26,480
Speaker 6: I've read articles where people implemented like Underreadey functionality or

895
00:48:26,480 --> 00:48:29,639
stuff like that with angirex, and was lots of ugly

896
00:48:29,679 --> 00:48:34,519
code because instead of thinking in terms of storing the

897
00:48:34,599 --> 00:48:37,280
history of changes, it was more like, well, every time

898
00:48:37,320 --> 00:48:40,320
the state changes, let's pick that snapshot, put somewhere, pick

899
00:48:40,360 --> 00:48:41,840
that snapshot and put somewhere.

900
00:48:41,880 --> 00:48:42,480
Speaker 2: And then.

901
00:48:44,760 --> 00:48:47,559
Speaker 6: The random access memory is also not the incidet, so

902
00:48:47,719 --> 00:48:50,679
it would probably be better if we could find sort

903
00:48:50,719 --> 00:48:54,519
of language to use in those situations. And this would

904
00:48:54,559 --> 00:48:58,840
also allow me to kind of keeping single the server.

905
00:48:58,960 --> 00:49:02,239
You know, when you like own Google docs, you type

906
00:49:02,239 --> 00:49:04,880
a bunch of stuff and then on the top there

907
00:49:04,920 --> 00:49:07,519
is an I can that sometimes synchronizes with the server

908
00:49:07,639 --> 00:49:10,960
and says that, okay, this is stored in the Google drive, right,

909
00:49:11,360 --> 00:49:14,079
So that's functional to you. Also can do you can

910
00:49:14,360 --> 00:49:16,960
find the lazy snapshot that went to the backhand, and

911
00:49:17,119 --> 00:49:20,320
in some timeframe you can just fool the other history

912
00:49:20,440 --> 00:49:22,719
and send an update to the bayhand.

913
00:49:22,920 --> 00:49:24,920
Speaker 2: So there's lots of stuff. You can store it in

914
00:49:25,000 --> 00:49:25,800
the index.

915
00:49:25,480 --> 00:49:28,239
Speaker 6: TPS and the user can have under read the functionality

916
00:49:28,280 --> 00:49:30,400
even if they like close the page and reopen it.

917
00:49:30,599 --> 00:49:33,199
Speaker 2: There's lots of stuff that this mindset. I really like it.

918
00:49:33,239 --> 00:49:37,679
I've never tried doing it in my projects, but.

919
00:49:37,960 --> 00:49:42,159
Speaker 6: It was really fascinating. So thank you for shining some

920
00:49:42,280 --> 00:49:43,199
light on this topic.

921
00:49:44,079 --> 00:49:46,199
Speaker 5: Great, glad you enjoyed that.

922
00:49:46,239 --> 00:49:52,639
Speaker 1: Awesome. Okay, so let's start wrapping up before we finalize everything,

923
00:49:52,880 --> 00:49:55,800
let's just do a quick round of promos. So I'm

924
00:49:55,800 --> 00:50:00,920
gonna go first with just promoting the producers of the podcast.

925
00:50:01,480 --> 00:50:05,840
So I'm going to promote top and Devs and onvoid.

926
00:50:06,039 --> 00:50:11,840
So if you're interested in other other podcasts about technology,

927
00:50:11,920 --> 00:50:15,440
maybe not necessarily just angular, but front end in general,

928
00:50:15,639 --> 00:50:20,480
or maybe even React and other subjects that might be

929
00:50:20,559 --> 00:50:23,280
more in the back end side of things, definitely do

930
00:50:23,440 --> 00:50:26,599
check out the catalog of podcasts in Top and Devs.

931
00:50:27,039 --> 00:50:31,400
And if you are a company or you are working

932
00:50:31,440 --> 00:50:33,719
at a company that is looking for more developers, that

933
00:50:33,800 --> 00:50:38,559
needs help to develop the system faster, or just swamped

934
00:50:38,599 --> 00:50:41,920
with a lot of things, then definitely consider reaching out

935
00:50:42,000 --> 00:50:46,880
to onvoid. It is un void dot com. They are

936
00:50:46,960 --> 00:50:51,880
basically offering remote design and software development services, but in

937
00:50:51,960 --> 00:50:56,199
a very very client friendly business model, so definitely check

938
00:50:56,239 --> 00:51:00,800
out that. If you or someone you know is looking

939
00:51:00,840 --> 00:51:03,840
for similar services. Amen, how about you.

940
00:51:06,119 --> 00:51:09,519
Speaker 6: Yeah, if you have been listening to the postcads and

941
00:51:09,639 --> 00:51:13,920
previous episodes where I featured, then you probably heard that

942
00:51:15,239 --> 00:51:16,320
I wrote a book.

943
00:51:16,119 --> 00:51:18,360
Speaker 2: On Angular with the money in publication.

944
00:51:19,440 --> 00:51:21,840
Speaker 6: With all the new stuff going on in the framework,

945
00:51:23,039 --> 00:51:25,519
we figured out it would be great if there was

946
00:51:25,800 --> 00:51:30,039
a sort of handbook for Angular developers, especially the ones

947
00:51:30,079 --> 00:51:34,000
that for unfortunate reasons, we're stuck on older versions and

948
00:51:34,079 --> 00:51:38,239
have issues and don't have much experience with the new

949
00:51:38,239 --> 00:51:40,639
things because they work on older versions.

950
00:51:41,760 --> 00:51:43,840
Speaker 2: So that's why I wrote Modern Angular.

951
00:51:45,280 --> 00:51:48,559
Speaker 6: It's available in early access now, so if you purchase

952
00:51:48,559 --> 00:51:50,639
the book, you will get the ebook, and in the future,

953
00:51:50,639 --> 00:51:52,960
when the book goes into print, you will get the

954
00:51:53,280 --> 00:51:57,840
print version if you buy that option. And I'm happy

955
00:51:57,840 --> 00:52:01,199
to say that we're finally in the copying phases the book,

956
00:52:01,360 --> 00:52:04,280
So now the copy editors are going for the book,

957
00:52:04,559 --> 00:52:09,079
fixing out every little bits of grammar and text, and

958
00:52:09,320 --> 00:52:11,519
we have done a couple of chapters, so hopefully in

959
00:52:11,639 --> 00:52:15,679
several weeks the book will finally go into print. And

960
00:52:17,800 --> 00:52:20,800
I myself am very eager to finally hold it in

961
00:52:20,840 --> 00:52:23,679
my hand, and hopefully if you haven't checked it out,

962
00:52:24,920 --> 00:52:30,039
we'll leave link. I'll be happy if I learned the

963
00:52:30,039 --> 00:52:31,360
book has been helpful to anyone.

964
00:52:32,320 --> 00:52:34,639
Speaker 1: Awesome, awesome, how about you, Sugrett.

965
00:52:35,760 --> 00:52:38,880
Speaker 3: Yeah, I'd like to promote my channel with its fun

966
00:52:38,880 --> 00:52:42,320
and furistic this's cool, guy, was.

967
00:52:42,320 --> 00:52:48,400
Speaker 1: That okay, which, by the way, also has a lot

968
00:52:48,440 --> 00:52:52,039
of content about Angler, So it's a very angular focused

969
00:52:53,159 --> 00:52:58,360
YouTube channel where those interested and Louise, how about you,

970
00:52:58,639 --> 00:52:59,360
what's gonna be.

971
00:52:59,360 --> 00:53:04,039
Speaker 4: Your You know, I would tell you that you can

972
00:53:04,039 --> 00:53:07,119
go and use our product, right, but look, ultimately I

973
00:53:07,199 --> 00:53:11,000
am focused on giving value first, so even before telling you, look,

974
00:53:11,000 --> 00:53:11,559
go give.

975
00:53:11,480 --> 00:53:14,000
Speaker 5: Us some money and use our cloud service. Now take

976
00:53:14,039 --> 00:53:14,559
our course.

977
00:53:15,280 --> 00:53:18,360
Speaker 4: It's nice to meet people face to face. I'm still

978
00:53:18,440 --> 00:53:21,559
one of the instructors. Sometimes you can find the course

979
00:53:21,559 --> 00:53:25,360
at ambar a m B A R dot cloud slash

980
00:53:25,559 --> 00:53:29,880
e sc and I would love to see people there

981
00:53:30,400 --> 00:53:33,679
and it's free, so you know, you can buy our

982
00:53:33,719 --> 00:53:36,360
service later, but take the course the courses free.

983
00:53:38,119 --> 00:53:43,800
Speaker 1: Awesome, Okay, okay, man, guys, thank you so much for

984
00:53:45,119 --> 00:53:47,920
being on the show. Louise, thank you so much for

985
00:53:47,960 --> 00:53:52,039
your time. This was really great. We talked for almost

986
00:53:52,079 --> 00:53:55,880
an hour and honestly we didn't even scratch this purpose.

987
00:53:56,519 --> 00:53:59,840
I definitely recommend anyone that is interested in diving to

988
00:54:00,719 --> 00:54:05,400
check out the course. If you're listening from YouTube, then

989
00:54:05,559 --> 00:54:08,400
there's the comments section and we left the link to

990
00:54:08,480 --> 00:54:13,760
the course, but again is MBAR dot cloud slash esc,

991
00:54:14,679 --> 00:54:17,960
so definitely check out that if you're interested in learning

992
00:54:18,000 --> 00:54:22,039
more about events sourcing. Again, thank you so much, and

993
00:54:22,119 --> 00:54:26,400
for those that stayed up until the very end, thank

994
00:54:26,440 --> 00:54:28,440
you so much for your time and I will see

995
00:54:28,440 --> 00:54:31,159
you in the next episode.