Structuring Node.js Applications: Event Loop, Metrics, and Efficient Processing Techniques

WEBVTT
1
00:00:05.480 --> 00:00:09.199
Hello everybody, and welcome to a super exciting episode of
2
00:00:09.400 --> 00:00:13.720
JavaScript Jabber. Today on our panel, we have a j O'Neill.
3
00:00:14.439 --> 00:00:17.120
Yo ya yo coming at you live, healthy and well
4
00:00:17.280 --> 00:00:18.960
from the perfect temperature in the shed.
5
00:00:20.399 --> 00:00:25.280
It's been a while and me I'm your host today,
6
00:00:25.480 --> 00:00:28.600
Dan Shapier from Tel Aviv in Israel. And today our
7
00:00:28.640 --> 00:00:37.479
guests are Matteo Colina Hi, Matteo, Hello everyone, James Snell Hi, James, Hello,
8
00:00:38.359 --> 00:00:40.960
and Michael Dawson Hi Michael, Hi.
9
00:00:40.799 --> 00:00:41.359
How are you doing?
10
00:00:42.520 --> 00:00:45.280
And today we brought you all over to talk about
11
00:00:45.320 --> 00:00:51.039
this excellent article post you know that you've written. I
12
00:00:51.079 --> 00:00:53.320
loved it very much, to the extent that as soon
13
00:00:53.359 --> 00:00:55.880
as I saw it, I contacted Matteo and told him
14
00:00:56.039 --> 00:00:58.280
you have to come on our show to talk about this.
15
00:00:59.399 --> 00:01:01.520
All you guys is out there should also read it
16
00:01:01.640 --> 00:01:04.480
regardless of what we talk about it here. And it's
17
00:01:04.519 --> 00:01:08.719
called the nine Note Pillars Nine Principles for doing no
18
00:01:08.879 --> 00:01:14.079
JS Right in enterprise environments. As I said, this is
19
00:01:14.120 --> 00:01:17.319
an awesome article. Who wants to start talking about it?
20
00:01:17.879 --> 00:01:19.359
So just go read it? I mean it is.
21
00:01:19.439 --> 00:01:20.159
Yeah.
22
00:01:20.439 --> 00:01:24.680
Okay, let me start these articles cars from an idea,
23
00:01:25.439 --> 00:01:30.319
from start from experience, Okay, start from at the key
24
00:01:31.439 --> 00:01:36.879
the experience of you know, developers do no JS all
25
00:01:36.920 --> 00:01:39.640
the time. They think they know no JS, and they
26
00:01:39.680 --> 00:01:41.239
don't know no no js.
27
00:01:42.799 --> 00:01:46.120
Okay, that's pretty unfortunate statement.
28
00:01:46.920 --> 00:01:49.560
It's no, it's true, it's true. It's absolutely true. You know,
29
00:01:50.120 --> 00:01:53.280
Mitteil and I, you know, when both of our previous
30
00:01:53.319 --> 00:01:55.920
employment we were working with a lot of consulting work,
31
00:01:55.959 --> 00:02:00.519
going out with customers and seeing the same problem over
32
00:02:00.560 --> 00:02:03.280
and over and over again, and in every single case,
33
00:02:03.319 --> 00:02:06.439
it always came down to folks not really understanding how
34
00:02:06.760 --> 00:02:11.199
node worked internally, like you know, what what how does
35
00:02:11.199 --> 00:02:12.080
the event loop workers?
36
00:02:12.120 --> 00:02:15.319
And I thinks it just occurred to me that I
37
00:02:15.439 --> 00:02:20.719
skipped a very important point while starting this conversation, and
38
00:02:20.800 --> 00:02:23.840
that's like who you guys are and why it is
39
00:02:23.879 --> 00:02:27.759
that you guys actually do know so much about how
40
00:02:27.879 --> 00:02:31.599
node works and how it should be used. So maybe
41
00:02:31.840 --> 00:02:35.479
you should, you guys should do a brief introduction of yourselves.
42
00:02:36.680 --> 00:02:38.599
Yeah, yeah, we can do that. I'm going a good
43
00:02:38.599 --> 00:02:43.719
person and let the guys go next year. So James,
44
00:02:43.800 --> 00:02:45.879
now I've been you know, I'm currently with cloud Flaer
45
00:02:45.879 --> 00:02:50.400
work on the workers run time. But you know, a
46
00:02:50.400 --> 00:02:53.360
lot longer than that. I've been involved with NOTE, coming
47
00:02:53.439 --> 00:02:58.039
up almost on ten years involved with Node, and at
48
00:02:58.039 --> 00:03:00.400
the end of this year will be exactly ten years
49
00:03:02.159 --> 00:03:04.840
prior to my current player. You know, you know, Matteo
50
00:03:04.879 --> 00:03:08.319
and I were doing all kinds of consulting work around node,
51
00:03:09.439 --> 00:03:13.919
use of Node, how to do things correctly, help people
52
00:03:13.919 --> 00:03:18.800
with performance, performance problems they're having, that kind of thing.
53
00:03:18.960 --> 00:03:22.560
But also just I've been contributing a lot to NOTE.
54
00:03:22.639 --> 00:03:24.439
So a lot of the things like the r L
55
00:03:24.680 --> 00:03:26.719
you know, the original euro parts are not the original,
56
00:03:26.840 --> 00:03:30.479
but the w G H and HB two and a
57
00:03:30.479 --> 00:03:32.639
bunch of other things that have been involved with with
58
00:03:32.639 --> 00:03:33.680
with adding. So that's me.
59
00:03:33.759 --> 00:03:36.520
That's my fact part in your roles. That must be
60
00:03:36.599 --> 00:03:37.159
so easy.
61
00:03:38.199 --> 00:03:43.120
Yeah, no, you can, I recommend for for a future episode.
62
00:03:43.319 --> 00:03:46.639
Get yagis on here. He did the the eight of
63
00:03:46.879 --> 00:03:49.199
RL implementation that NOTE now uses and he can tell
64
00:03:49.199 --> 00:03:51.159
you why it's not easy at all.
65
00:03:51.560 --> 00:03:54.719
So yeah, I know I was just being faspicious.
66
00:03:55.599 --> 00:03:56.840
Yeah, I'm Michael Dawson.
67
00:03:56.960 --> 00:03:59.520
I'm the NODS lead for rad Hot and IBM, and
68
00:04:00.039 --> 00:04:03.000
I got you know, if I actually got involved in
69
00:04:03.039 --> 00:04:06.240
the project around the same time that James Hayes and
70
00:04:06.319 --> 00:04:09.199
so been working for a very long time in the project,
71
00:04:09.240 --> 00:04:12.360
a member of the technical Steering Committee, working a whole
72
00:04:12.400 --> 00:04:16.800
bunch of the different working groups, particular like note at
73
00:04:16.879 --> 00:04:18.920
on API is one of the ones that I'm pretty
74
00:04:18.920 --> 00:04:21.959
active in in the build working group. And I think
75
00:04:22.000 --> 00:04:24.720
back to your earlier question, is like, I think that
76
00:04:24.800 --> 00:04:28.800
the challenges is that you can very easily get started
77
00:04:28.839 --> 00:04:31.079
with GS, but actually getting it right is a little
78
00:04:31.079 --> 00:04:31.920
bit more difficult.
79
00:04:31.920 --> 00:04:34.079
And that's why we we you know, we see.
80
00:04:33.920 --> 00:04:37.120
Things like some specific guidance can really help people going forward.
81
00:04:37.399 --> 00:04:38.040
Over to Matteo.
82
00:04:39.000 --> 00:04:41.920
So hi, hi folks, I am a little bit under
83
00:04:41.920 --> 00:04:43.680
the weather today, so I'm sorry. I didn't want to
84
00:04:44.519 --> 00:04:49.240
defer the recording. So so sorry if I'm less, I
85
00:04:49.279 --> 00:04:57.839
don't know, excited as you. It's look, well, well I
86
00:04:57.879 --> 00:04:59.839
have I have a lot at this point, have been
87
00:04:59.879 --> 00:05:02.120
doing been doing the JS for a long time. I
88
00:05:02.160 --> 00:05:08.680
have accumulated a few hundreds MPM deployed a few hundreds
89
00:05:09.519 --> 00:05:15.079
modules on MPM, which more or less total a very
90
00:05:15.199 --> 00:05:18.519
nice one percent, close to one percent of the total
91
00:05:18.600 --> 00:05:23.399
number of down of downloads of MPM itself. Wow, it's
92
00:05:23.439 --> 00:05:27.160
it's a little bit unbelievable to be honest, the numbers
93
00:05:27.160 --> 00:05:30.360
are you know, it has way too many zeros in them.
94
00:05:30.600 --> 00:05:33.439
Okay, you've been busy.
95
00:05:33.759 --> 00:05:37.000
Well yeah, everybody seems to love the code that I
96
00:05:37.120 --> 00:05:43.240
pushed that they push out for free. So anyway, a
97
00:05:43.319 --> 00:05:48.720
few years back, I started this company called Platformatic two
98
00:05:50.920 --> 00:05:53.399
you know, to push not to the next level, and
99
00:05:53.439 --> 00:05:57.079
that's where what we are trying to do, and and
100
00:05:57.160 --> 00:06:00.079
we have been trying to fund some of those initiatives
101
00:06:00.399 --> 00:06:02.839
and things and promote no js.
102
00:06:03.240 --> 00:06:04.319
So here we are.
103
00:06:06.680 --> 00:06:11.160
Cool. Now, you guys all work at different companies, so
104
00:06:11.319 --> 00:06:14.079
you're obviously all three of you very much involved in node,
105
00:06:15.000 --> 00:06:17.959
but your day job is at different places. How did
106
00:06:17.959 --> 00:06:20.040
it happen that all of the three of you came
107
00:06:20.079 --> 00:06:22.079
together to write this article?
108
00:06:22.560 --> 00:06:23.439
Oh, I can take this.
109
00:06:23.720 --> 00:06:26.480
So basically it's actually one person that is missing in
110
00:06:26.480 --> 00:06:28.959
this call, which is Natalia that was also part of
111
00:06:29.000 --> 00:06:29.480
the review.
112
00:06:29.959 --> 00:06:35.319
Okay. And Natalia is also the lead owner and for
113
00:06:35.560 --> 00:06:39.720
JavaScript the X and have tools for Azure and the
114
00:06:39.800 --> 00:06:42.920
four of us like this started from my idea, from
115
00:06:43.560 --> 00:06:46.800
an idea that I had a few months back and says, look,
116
00:06:46.879 --> 00:06:50.120
how come we can how can we promote and solidify
117
00:06:50.360 --> 00:06:51.079
that knowledge?
118
00:06:51.199 --> 00:06:59.680
Okay? And how can we stop start pushing back against the.
119
00:07:01.120 --> 00:07:03.920
All the bad tutorials, all the bad all the bad
120
00:07:03.959 --> 00:07:07.959
practices that are out there and plugging every single not
121
00:07:08.079 --> 00:07:11.920
JS code base that I have that I've seen, Okay.
122
00:07:11.600 --> 00:07:13.639
Because that's that's frankly what it is.
123
00:07:14.199 --> 00:07:17.519
So at that time I started looking, and I said
124
00:07:17.560 --> 00:07:21.279
that I picked a few friends and decided, look, who
125
00:07:21.279 --> 00:07:24.399
can who can I ask? I want a presentation for
126
00:07:24.480 --> 00:07:28.000
a bunch of different companies and so on. So and
127
00:07:28.279 --> 00:07:31.439
let's try to put our our minds together and write
128
00:07:31.439 --> 00:07:38.959
something up that can be uh that you know, we
129
00:07:39.040 --> 00:07:42.879
can be happy with and can help developers you know
130
00:07:43.120 --> 00:07:46.519
you're doing no J as well, and stop those you know,
131
00:07:46.680 --> 00:07:52.879
Spaghetti's code mess that they do most of the time.
132
00:07:53.279 --> 00:07:56.839
So yeah, and one important point of me is like,
133
00:07:56.879 --> 00:07:59.079
none of none of the information in this pod post
134
00:07:59.160 --> 00:08:02.399
is new. It's stuff that we've talked about and talks
135
00:08:02.399 --> 00:08:05.680
over the years for conferences and workshops, and you know,
136
00:08:05.720 --> 00:08:09.639
each of us in various ways have have talked about
137
00:08:09.680 --> 00:08:13.439
these things before. Unfortunately, a lot of that gets kind
138
00:08:13.439 --> 00:08:15.279
of washed out in the noise. It's like, you know,
139
00:08:15.319 --> 00:08:19.000
there's so many of these tutorials that just kind of
140
00:08:19.000 --> 00:08:22.519
get things wrong. And it ends up washing out the
141
00:08:23.160 --> 00:08:26.639
good information. Uh, just kind of in that noise. And
142
00:08:26.680 --> 00:08:29.600
so it's like many times we can repeat this stuff,
143
00:08:30.000 --> 00:08:30.680
get it out there.
144
00:08:31.279 --> 00:08:31.480
You know.
145
00:08:31.839 --> 00:08:34.000
I'd like to see us like repeat this again like
146
00:08:34.159 --> 00:08:36.480
a year from now, just kind of keep reiterating on it,
147
00:08:36.600 --> 00:08:37.200
keep going.
148
00:08:37.519 --> 00:08:43.759
Uh, gets on again and again in the future. Individually altogether,
149
00:08:44.360 --> 00:08:48.919
just say the word Obviously, we will enumerate through the
150
00:08:48.960 --> 00:08:52.159
pillars and look talk about the positive stuff and the
151
00:08:52.200 --> 00:08:54.600
things that that need that should be done, and it
152
00:08:54.720 --> 00:08:57.440
can be done and need to be done. But to
153
00:08:57.519 --> 00:08:59.799
make it spicy, I do actually want to start with
154
00:08:59.840 --> 00:09:02.600
some of the negatives. If you don't mind. You guys
155
00:09:02.639 --> 00:09:06.960
said that you encounter so many bad practices and so
156
00:09:07.279 --> 00:09:11.919
much bad advice and bad code, and without naming names,
157
00:09:12.360 --> 00:09:14.120
can you give some examples.
158
00:09:17.039 --> 00:09:20.000
Oh yeah, we can do whole whole examples. I'm gonna
159
00:09:20.480 --> 00:09:24.519
a couple years ago the top guys, I did a
160
00:09:24.559 --> 00:09:27.080
talk called broken Promises. There there's you can you can
161
00:09:27.120 --> 00:09:29.519
find it on YouTube, and I credit with the work
162
00:09:29.639 --> 00:09:33.399
some workshops just that you know, kind of breaks down
163
00:09:33.840 --> 00:09:37.480
some of the really bad ways people just get things wrong,
164
00:09:37.519 --> 00:09:40.759
particularly around promises, because they just don't understand how they work.
165
00:09:41.960 --> 00:09:45.639
I had one former consulting customer I walked in was.
166
00:09:45.600 --> 00:09:49.600
Doing a workshop their their their lead engineer on the
167
00:09:49.679 --> 00:09:54.799
team started arguing with me because he believed that creating
168
00:09:54.879 --> 00:09:57.519
new promise was just like creating new thread and Java.
169
00:09:58.360 --> 00:10:02.840
So no, it's completely different model. And this is their
170
00:10:02.919 --> 00:10:05.879
lead engineer on on on the team. Because it just
171
00:10:06.159 --> 00:10:10.080
did not understand how how this works, and it just
172
00:10:10.120 --> 00:10:12.600
we just kept encountering that over and over and over again,
173
00:10:12.639 --> 00:10:13.399
that kind of stuff.
174
00:10:14.879 --> 00:10:18.519
I just posted the link, by the way, Uh, we'll
175
00:10:18.559 --> 00:10:20.679
also put it in the show notes to that talk.
176
00:10:21.399 --> 00:10:24.840
So yeah, that's that's pretty amazing. Like I can understand
177
00:10:24.840 --> 00:10:28.080
why somebody might confuse a worker with a thread, but
178
00:10:28.240 --> 00:10:31.320
confusing a promise with a thread that's pretty extreme.
179
00:10:32.200 --> 00:10:35.519
But look, we can even go to more of way
180
00:10:35.600 --> 00:10:40.519
more basic stuff, okay, like like the best. Let's let's
181
00:10:40.519 --> 00:10:43.399
talk a little bit about updating no JS updated not
182
00:10:43.639 --> 00:10:46.879
do not use uh deprecated code.
183
00:10:48.360 --> 00:10:49.679
It's unbelievable.
184
00:10:50.120 --> 00:10:55.879
Okay, the companies are not updating no JS like this
185
00:10:56.039 --> 00:10:56.720
seems you know.
186
00:10:56.799 --> 00:10:57.360
It's it's.
187
00:11:00.000 --> 00:11:03.720
Should deploy something though it's working. Just let it be right.
188
00:11:04.200 --> 00:11:07.200
I mean, I know a lot of companies, are you know,
189
00:11:07.360 --> 00:11:09.960
in some sort of hype cycle where they're just deploying
190
00:11:09.960 --> 00:11:13.120
the latest framework every other day. But I think a
191
00:11:13.159 --> 00:11:17.799
lot of profitable companies are creating a product and once
192
00:11:17.840 --> 00:11:21.039
that product is good, they're they're not gonna rock the
193
00:11:21.080 --> 00:11:23.879
boat on it every five minutes. They're gonna let it cook.
194
00:11:24.720 --> 00:11:28.480
Also, you know that old joke about that the developer
195
00:11:28.559 --> 00:11:33.799
and his son walking down the road and the boy says, Dad,
196
00:11:33.879 --> 00:11:37.200
why does the sun rise in the east, And the
197
00:11:37.240 --> 00:11:42.279
father says, it works, don't touch it.
198
00:11:43.320 --> 00:11:47.840
Those are good points. Those are good points. But you know,
199
00:11:48.039 --> 00:11:50.519
no one wants to use software that is full of
200
00:11:50.559 --> 00:11:52.279
security and vulnerabilities.
201
00:11:52.879 --> 00:11:54.480
Well, maybe they should stop putting them in.
202
00:11:54.440 --> 00:11:59.360
The oh, maybe they should stop putting their product on
203
00:11:59.399 --> 00:12:04.600
the Internet. Then that's a pretty eastern way to be pulled.
204
00:12:04.639 --> 00:12:09.120
The blog it's it's it's secure by default, Okay.
205
00:12:09.279 --> 00:12:12.919
I mean, so the application and an application that has
206
00:12:13.039 --> 00:12:15.399
proper isolation around it. And I say, if all of
207
00:12:15.440 --> 00:12:17.799
the routes coming into that thing are secured and it's
208
00:12:17.840 --> 00:12:20.840
not exposed to the Internet, it's just like a long
209
00:12:20.919 --> 00:12:25.399
running enterprise application that's there to support existing business processes.
210
00:12:25.720 --> 00:12:28.440
If they don't update, they don't update that doesn't matter
211
00:12:28.480 --> 00:12:32.559
because because they have that isolation, and the types of
212
00:12:32.600 --> 00:12:35.879
threats that are coming at that server, you know, are
213
00:12:35.919 --> 00:12:38.080
much more limited. But if something's out on the internet,
214
00:12:38.159 --> 00:12:40.679
if it's exposed to the internet, you know, you don't
215
00:12:40.679 --> 00:12:44.679
want to have software running that has these security vulnerabilities.
216
00:12:44.679 --> 00:12:49.600
You really should update. And as updating, you know, you
217
00:12:49.639 --> 00:12:51.679
can't just quite throw a new version out there. You
218
00:12:51.679 --> 00:12:53.799
need to see what other changes are going on. Like
219
00:12:54.120 --> 00:12:57.879
we'll deprecate things that we really people really should not
220
00:12:58.000 --> 00:13:01.799
use because it could be a security vulnerability. But we
221
00:13:01.919 --> 00:13:03.639
you know, but removing it or changing the way it
222
00:13:03.639 --> 00:13:05.279
works is too much of a breaking change, and we
223
00:13:05.320 --> 00:13:07.279
don't want to force a breaking change on people. We
224
00:13:07.360 --> 00:13:11.600
just want to strongly nudge you away, right. Yeah.
225
00:13:12.399 --> 00:13:16.000
Also, it's not as if those organizations aren't updating their
226
00:13:16.039 --> 00:13:19.080
own code. I mean, you know, if the project is dead,
227
00:13:19.120 --> 00:13:21.879
then it's dead. But you know, we are primarily talking
228
00:13:21.879 --> 00:13:26.840
about you know, living, not dead profitable.
229
00:13:27.159 --> 00:13:32.720
There's a difference between dead and it's not a suck
230
00:13:32.799 --> 00:13:36.000
of engineering resources every week, it's actually making money.
231
00:13:36.159 --> 00:13:38.679
Yeah, But in order to be profit afoodable these days,
232
00:13:38.679 --> 00:13:40.600
you need to be a service and the only way
233
00:13:40.639 --> 00:13:44.879
to justify being a service is continuously releasing updates even
234
00:13:44.879 --> 00:13:47.919
if nobody asks for them.
235
00:13:48.080 --> 00:13:51.639
Well, I was going to say one thing that circling back,
236
00:13:52.159 --> 00:13:55.600
I don't think I have seen anything breaking Node since
237
00:13:55.720 --> 00:13:59.799
version either ten or twelve. So I recently updated an application.
238
00:14:00.120 --> 00:14:02.919
Was so fraid because I'm actually using private APIs in
239
00:14:02.960 --> 00:14:06.440
the networking layer. I updated an application I think from
240
00:14:06.720 --> 00:14:09.759
it was version maybe twelve or fourteen, all the way
241
00:14:09.840 --> 00:14:15.120
up to version twenty, and there were no issues. So
242
00:14:15.600 --> 00:14:19.720
Note has become incredibly stable, probably after version I want
243
00:14:19.720 --> 00:14:21.200
to say after version ten. I think there was a
244
00:14:21.200 --> 00:14:23.799
ton of breaking changes in the version version six or eight,
245
00:14:24.399 --> 00:14:30.480
but version ten or twelve, it's it's been incredibly stable.
246
00:14:30.519 --> 00:14:34.679
In the likelihood that you'll have to go debug things
247
00:14:34.399 --> 00:14:37.879
is unless you're using an experimental feature. Ye had experimental flags,
248
00:14:37.879 --> 00:14:39.799
but even then, I don't think I've seen any breaks
249
00:14:39.799 --> 00:14:44.240
in the experimental features in the last several years. Few.
250
00:14:44.840 --> 00:14:46.879
Yeah, they're few, they count, you know, they're the usually
251
00:14:46.919 --> 00:14:48.919
pretty small, but they happen every now and then.
252
00:14:49.639 --> 00:14:52.240
One of the ones that I used, like fetch and
253
00:14:52.480 --> 00:14:56.879
the there was something in web crypto, and maybe there's
254
00:14:56.919 --> 00:14:59.039
some more niche things that are weird, like the U
255
00:15:00.200 --> 00:15:02.799
was that it's like a lifetimes thing. I forget what
256
00:15:02.799 --> 00:15:04.480
the name of it was, if I don't know if
257
00:15:04.480 --> 00:15:06.279
it's still a thing, but there was like some sort
258
00:15:06.320 --> 00:15:07.519
of a lifetimey thing.
259
00:15:08.639 --> 00:15:15.720
In price talking about Yeah, yeah.
260
00:15:13.799 --> 00:15:15.480
That might be. Like there's some of that stuff that
261
00:15:15.559 --> 00:15:18.159
was super experimental. I didn't touch, but anything that already
262
00:15:18.200 --> 00:15:20.159
had a web standard was the stuff that I was
263
00:15:20.919 --> 00:15:22.879
that I've been using that's been experimental.
264
00:15:23.679 --> 00:15:25.919
It's certainly like if you follow the discussions in the
265
00:15:26.000 --> 00:15:28.879
in the project, we really are careful about that and
266
00:15:28.919 --> 00:15:33.320
we think carefully. And you know, if even the ones
267
00:15:33.360 --> 00:15:35.799
that James mentioned, we do make some small breaking changes,
268
00:15:35.799 --> 00:15:37.360
but we think very carefully about those.
269
00:15:37.399 --> 00:15:38.960
We try and understand the impact.
270
00:15:39.039 --> 00:15:41.240
And so yeah, I think that's one of the things
271
00:15:41.240 --> 00:15:43.320
the project has been doing quite well over the last
272
00:15:43.399 --> 00:15:45.600
number of years is to try and minimize that. The
273
00:15:45.679 --> 00:15:47.440
other thing I wanted to add to what James was
274
00:15:47.480 --> 00:15:50.320
saying is like it really comes back to risk management.
275
00:15:52.000 --> 00:15:54.440
You know, you can continue to run on older versions,
276
00:15:54.639 --> 00:15:57.399
and I think if you've done your risk management, you've
277
00:15:57.399 --> 00:16:00.919
done your analysis, like you may you know, again back
278
00:16:00.919 --> 00:16:02.759
to your point of like it doesn't cost any money
279
00:16:02.799 --> 00:16:04.919
to leave it just running so that that isn't that
280
00:16:05.000 --> 00:16:07.000
is good and if you've actually thought about it, maybe
281
00:16:07.039 --> 00:16:09.720
you're doing the right thing. I think we just don't
282
00:16:09.720 --> 00:16:13.600
necessarily see that people are like thinking about it enough
283
00:16:13.679 --> 00:16:15.879
in terms of like should I should I have updated?
284
00:16:17.039 --> 00:16:19.039
You know, that's the easy answer is if you stay
285
00:16:19.039 --> 00:16:21.039
on the lift, you're going to get the security fixes
286
00:16:22.200 --> 00:16:24.519
or you know, there's some companies like like the one
287
00:16:24.519 --> 00:16:26.559
I work for that will give you longer term support,
288
00:16:26.679 --> 00:16:29.759
so you're probably okay then, But like we probably like
289
00:16:29.840 --> 00:16:33.639
to see a few more people either very carefully looking
290
00:16:33.639 --> 00:16:36.879
at their risks or sticking to the LTS releases and
291
00:16:36.879 --> 00:16:38.639
the ones that are active, because those are the ones
292
00:16:38.639 --> 00:16:40.000
that like the project is going to help.
293
00:16:40.559 --> 00:16:44.240
Yeah, but now you're starting to go towards the actual pillars,
294
00:16:44.799 --> 00:16:49.399
because that's literally one of the pillars. So I'll just
295
00:16:49.519 --> 00:16:52.600
pull us or push us towards that, and let's maybe
296
00:16:52.639 --> 00:16:55.120
start going down the pillars, unless you guys want to
297
00:16:55.159 --> 00:17:00.440
mention something else before we we do that, Okay, let's
298
00:17:00.480 --> 00:17:04.880
go do. Let's start with the pillars then, So pillar
299
00:17:04.960 --> 00:17:09.240
number one do not block the event loop. That's an
300
00:17:09.279 --> 00:17:13.359
interesting one because it's actually also very much pertinent to
301
00:17:13.640 --> 00:17:19.440
the browser, not only to node, and actually it's also
302
00:17:19.559 --> 00:17:23.759
pertinent to the Dino and bond. By the way, I
303
00:17:23.799 --> 00:17:26.799
will say that quite a number of these pillars are
304
00:17:26.880 --> 00:17:29.440
relevant or almost all of them are also relevant to
305
00:17:29.559 --> 00:17:33.880
Dino and to bon I think. And some of them
306
00:17:33.960 --> 00:17:38.079
are relevant, you know, to whatever server platform almost you're using.
307
00:17:38.359 --> 00:17:40.799
You know, they might be relevant if you're using Java
308
00:17:40.960 --> 00:17:45.759
or Go or whatever. But again we'll be focusing on
309
00:17:45.799 --> 00:17:49.720
a node in this conversation. So again, the first one
310
00:17:49.839 --> 00:17:53.440
is do not block the event loop. We've discussed the
311
00:17:53.440 --> 00:17:56.359
event loop in the past on this podcast, but maybe
312
00:17:56.400 --> 00:17:59.960
it's worthwhile for one of you guys to quickly explain
313
00:18:00.200 --> 00:18:02.920
reiterate what the event loop is and why it's so
314
00:18:02.960 --> 00:18:07.920
important not to block it. Yeah, I mean we can.
315
00:18:08.200 --> 00:18:11.039
We can talk about it just in very very high
316
00:18:11.079 --> 00:18:13.319
level general terms. You know, you know, the note has
317
00:18:13.359 --> 00:18:16.200
its event loop which is based on the UV. It
318
00:18:16.279 --> 00:18:22.160
is structured a particular way. Dino and and Bond and
319
00:18:22.440 --> 00:18:24.519
workers and stuff. We you know, they all have event
320
00:18:24.559 --> 00:18:28.400
loops that are that work slightly differently. They have different phases,
321
00:18:28.440 --> 00:18:31.640
different you know, slight you know, slightly different implementations, so
322
00:18:31.640 --> 00:18:34.400
they all work slightly differently. But they all have the
323
00:18:34.440 --> 00:18:37.799
same fundamental concept of it's going to be monitoring the
324
00:18:37.839 --> 00:18:41.160
system for we you know, certain events io, hey, I
325
00:18:41.160 --> 00:18:42.720
want to read a file, or I've got a network
326
00:18:42.759 --> 00:18:47.720
connection or whatever. And as it's turning, it's gonna you know, say,
327
00:18:48.200 --> 00:18:50.119
I gotta I got some io I'm going to fire
328
00:18:50.160 --> 00:18:52.200
a callback and that callback is going to go off
329
00:18:52.200 --> 00:18:55.680
and run some job script. And what's important to understand
330
00:18:56.119 --> 00:18:59.160
is that while that joba script is running, the event
331
00:18:59.200 --> 00:19:02.359
loop is not. It pauses while you go off and
332
00:19:02.440 --> 00:19:05.200
run that JavaScript, and then when that is done running,
333
00:19:05.240 --> 00:19:08.240
it comes back and the loop continues. It doesn't matter
334
00:19:08.240 --> 00:19:11.519
what platform you're on. That's how it works, unless you're
335
00:19:11.599 --> 00:19:14.759
using worker threads, which you have multiple event loops running
336
00:19:14.799 --> 00:19:18.880
on different threads. When you're whenever you're running JavaScript, nothing
337
00:19:18.920 --> 00:19:21.200
else is running, all right, You're not going out and
338
00:19:21.200 --> 00:19:23.839
pulling IOH, you're not looking for you know, you can't
339
00:19:23.920 --> 00:19:27.559
go off and accept the new connection that kind of stuff, right,
340
00:19:27.920 --> 00:19:31.640
So you know, it's you have to make sure that
341
00:19:31.640 --> 00:19:34.160
that jobscript that you're running can return fast enough for
342
00:19:34.200 --> 00:19:36.319
that event that to turn around and do something else.
343
00:19:38.440 --> 00:19:44.160
Now, on the browser side, it's it's maybe less catastrophic.
344
00:19:44.240 --> 00:19:47.079
But it's often more obvious when there's a problem with
345
00:19:47.160 --> 00:19:53.759
the event loop because user interactions starts to get jenky uh,
346
00:19:54.079 --> 00:19:59.240
somebody clicks a button and the UI doesn't respond because
347
00:19:59.400 --> 00:20:02.839
the browser is too busy processing the JavaScript for a
348
00:20:02.880 --> 00:20:08.400
previous event. What's the negative impact in node when you
349
00:20:09.559 --> 00:20:13.480
don't process stuff out of the event loop quickly enough,
350
00:20:13.599 --> 00:20:17.400
or when things stay in the queue for too long.
351
00:20:19.599 --> 00:20:22.920
I have a very nice talk on this, okay, which
352
00:20:22.960 --> 00:20:25.319
I recommend everybody to watch. I'm going to pass it.
353
00:20:25.640 --> 00:20:29.160
I'm going to summarize and then pass it into into
354
00:20:29.240 --> 00:20:35.160
the chat for everybody to to take a look. Okay,
355
00:20:35.599 --> 00:20:41.119
So the the gist is very simple.
356
00:20:41.200 --> 00:20:44.160
What is that? What happens? Okay? You take.
357
00:20:48.559 --> 00:20:52.279
Gets busy? Okay, the problem it doesn't? You say, well,
358
00:20:52.319 --> 00:20:54.559
the event top is busy. What problem it can be?
359
00:20:54.880 --> 00:20:55.200
Okay?
360
00:20:55.759 --> 00:21:01.039
Well, genetically, if there's only one user, and which is
361
00:21:01.079 --> 00:21:05.000
for example, the case for deployment on workers or in
362
00:21:05.480 --> 00:21:10.160
w islam DA, this is essentially the impact is very limited.
363
00:21:10.359 --> 00:21:10.680
Okay.
364
00:21:11.079 --> 00:21:13.720
However, you are also missing out on the key feature
365
00:21:13.839 --> 00:21:18.400
of no JS and zavaskipt itself because you can, you know,
366
00:21:18.480 --> 00:21:21.599
supporting multiples at the same time allow you to maximize
367
00:21:22.240 --> 00:21:24.079
the use of the source.
368
00:21:23.920 --> 00:21:25.480
Of that single process.
369
00:21:25.720 --> 00:21:30.680
So what happens is that once the amount of load
370
00:21:31.240 --> 00:21:33.599
goes over and there's a little bit of math involved,
371
00:21:33.920 --> 00:21:38.079
goes over a st threshold, the response time of your
372
00:21:38.079 --> 00:21:43.640
application will start getting will start looping into we start
373
00:21:43.680 --> 00:21:48.880
growing in an exponential in an exponential fashion, and therefore
374
00:21:49.279 --> 00:21:50.559
at that point.
375
00:21:50.359 --> 00:21:51.119
You are.
376
00:21:53.160 --> 00:21:57.200
Your application will stall completely, very quickly and not responding,
377
00:21:57.359 --> 00:22:02.640
not nothing, spinning wheels. Typically, the problem is if I
378
00:22:02.759 --> 00:22:04.519
send a request, okay.
379
00:22:04.480 --> 00:22:07.640
Do you.
380
00:22:06.359 --> 00:22:09.759
Want the if you're if you done a good job,
381
00:22:09.839 --> 00:22:12.799
you are going to respond. Your server is going to
382
00:22:12.799 --> 00:22:16.319
respond in I don't know, two und MILLI second a second,
383
00:22:16.559 --> 00:22:21.160
two second, okay, after what's the threshold after which I
384
00:22:21.240 --> 00:22:26.039
stop responding? Okay, I start I stopped waiting for a response, okay.
385
00:22:26.799 --> 00:22:30.359
But the problem is that when you receive an HTP request,
386
00:22:30.400 --> 00:22:34.200
you node you you know, not just as received that request,
387
00:22:34.640 --> 00:22:39.559
and we continue processing that request up independently of the
388
00:22:39.599 --> 00:22:45.640
fact that the user on the other end as he
389
00:22:45.720 --> 00:22:46.359
is still there.
390
00:22:46.759 --> 00:22:50.240
Okay. You can detect that. You can handle this with
391
00:22:50.279 --> 00:22:52.960
about signals and a bunch of other stuff, but it's
392
00:22:54.440 --> 00:22:57.799
definitely not definitely not common.
393
00:22:58.119 --> 00:23:01.799
Okay, So, and the genetic result is and when you know,
394
00:23:01.880 --> 00:23:04.240
gs reach a certain level of flow, it became very
395
00:23:04.319 --> 00:23:10.440
much unresponsible that your application became as andresponsive completely.
396
00:23:10.839 --> 00:23:13.559
And this is a massive, massive problem.
397
00:23:14.200 --> 00:23:17.880
A great example, you know, based on former customer, I'm
398
00:23:17.920 --> 00:23:19.759
not going to name any names and such, but we
399
00:23:20.079 --> 00:23:23.359
were called out to do some consulting work for them
400
00:23:23.359 --> 00:23:27.480
because their note application was very, very slow. They were
401
00:23:27.519 --> 00:23:31.400
getting a whopping four requests per second production, Like, what
402
00:23:31.440 --> 00:23:33.200
the hell are you doing to get only to only
403
00:23:33.279 --> 00:23:35.279
get four requests per second? Well, what they were.
404
00:23:35.160 --> 00:23:42.119
Doing apply to the trillions dig on every request almost worse.
405
00:23:42.200 --> 00:23:45.160
So, they were using an old version of Apollo that
406
00:23:45.319 --> 00:23:49.279
was not very performance optimized. Every graph COO career that
407
00:23:49.279 --> 00:23:52.599
they were received was very complex and it ended up
408
00:23:52.599 --> 00:23:55.240
being where they would do like ten to fifteen sub
409
00:23:55.240 --> 00:23:59.119
requests on that back in that back then, the way
410
00:23:59.160 --> 00:24:01.720
that propol works, it would receive the requests, it would
411
00:24:01.759 --> 00:24:05.039
parse it generate the AST, walk the AST, go off
412
00:24:05.079 --> 00:24:08.279
and submit all of the sub requests, wait for those
413
00:24:08.319 --> 00:24:10.599
to return, and then would have to go through and
414
00:24:10.640 --> 00:24:15.799
do this this process of reconstructing the response. Unfortunately, these
415
00:24:16.119 --> 00:24:18.799
queries were so complex that it was blocking the event
416
00:24:19.039 --> 00:24:23.559
All of that processing was was synchronous right now, Waiting
417
00:24:23.599 --> 00:24:26.359
on the sub requests that was asynchronous, but the actual
418
00:24:26.400 --> 00:24:28.839
parsing and walking to the AST was fully synchronous. And
419
00:24:28.839 --> 00:24:31.880
they were blocking the event loop from progressing every time
420
00:24:31.960 --> 00:24:35.559
that happened, and they were blocking it by so much
421
00:24:35.920 --> 00:24:38.279
that you know, it couldn't get around to take the
422
00:24:38.319 --> 00:24:39.359
next request.
423
00:24:39.640 --> 00:24:39.839
Right.
424
00:24:40.160 --> 00:24:43.119
The other problem that they were encountering though, is roughly
425
00:24:43.200 --> 00:24:47.039
maybe about fifteen percent of of their requests were failing
426
00:24:47.839 --> 00:24:51.319
with timeouts. And like you know, we'd understand why these
427
00:24:51.319 --> 00:24:54.319
are failing with timeouts. Well, what would happen is they
428
00:24:54.359 --> 00:24:57.640
would send, like I said, ten to fifteen back end requests, right,
429
00:24:59.039 --> 00:25:01.920
sub request those would go to the back end systems.
430
00:25:01.920 --> 00:25:08.200
Those systems were responding quickly, right and and you know,
431
00:25:08.279 --> 00:25:14.039
having responses pending in the IOQ in the node event loop.
432
00:25:14.440 --> 00:25:16.759
But if you look at the phases of the node
433
00:25:16.759 --> 00:25:20.720
event loop, what you'll see is almost right before we
434
00:25:20.759 --> 00:25:25.960
pull for pending io we checked timers, right, you know,
435
00:25:26.000 --> 00:25:29.160
and that loop we always checked timers first. What was
436
00:25:29.200 --> 00:25:31.720
happening is that the event loop was being blocked for
437
00:25:31.759 --> 00:25:35.160
so long that by the time the event loop turned
438
00:25:35.160 --> 00:25:38.880
and came to book the timers even though that those responses,
439
00:25:38.960 --> 00:25:42.319
the suber quest responses were waiting to be read, the
440
00:25:42.400 --> 00:25:45.720
timeouts on the sub requests would would fire and cancel
441
00:25:45.799 --> 00:25:49.720
the entire thing. Oh no, So it was just like
442
00:25:49.799 --> 00:25:54.480
this compounding problem that all of the synchronous activity blocking
443
00:25:54.519 --> 00:25:58.799
the loop from actually advancing IO tripping itself up.
444
00:26:00.559 --> 00:26:05.279
If I'm thinking about it, I can basically like perceive
445
00:26:05.359 --> 00:26:10.839
of two main problematic scenarios here and correct me if
446
00:26:10.880 --> 00:26:16.039
I'm if I'm wrong. One scenario is that even though
447
00:26:16.799 --> 00:26:24.039
events are are being handled relatively in a timely fashion individually,
448
00:26:24.880 --> 00:26:27.000
the rate in which they are coming in is so
449
00:26:27.200 --> 00:26:33.759
high that the server is simply unable to complete the
450
00:26:34.160 --> 00:26:36.799
processing the events at the rate that new events are
451
00:26:36.839 --> 00:26:41.799
coming in. That's that's problem number one. And problem number
452
00:26:41.880 --> 00:26:46.039
two is that regardless of the rate that events are
453
00:26:46.039 --> 00:26:50.839
coming in, sometimes the processing is so lengthy that the
454
00:26:50.920 --> 00:26:54.400
loop is just being blocked for so long that it's
455
00:26:54.440 --> 00:26:58.200
making the system and the system is unresponsive during that time.
456
00:26:58.599 --> 00:27:03.480
That that causes problems because other events time out are
457
00:27:03.480 --> 00:27:07.400
not processed in a sufficiently timely fashion, all sorts of problems.
458
00:27:07.720 --> 00:27:11.759
So the service might be even mostly not busy at all,
459
00:27:12.200 --> 00:27:15.960
but whenever something comes in, it just gets stuck for
460
00:27:17.079 --> 00:27:19.960
too long a period I understand.
461
00:27:19.640 --> 00:27:25.039
Incorrectly, yes, yes, yes, And if that event opens uppens
462
00:27:25.079 --> 00:27:28.160
too often, it gets into a catastrophic failure.
463
00:27:29.400 --> 00:27:32.839
And most as to say.
464
00:27:32.759 --> 00:27:35.960
Like the event loops really optimized to do lots of
465
00:27:36.079 --> 00:27:39.799
short things. And you know you talked about the first
466
00:27:39.839 --> 00:27:42.880
case of things coming in too quickly, Well, no one
467
00:27:42.920 --> 00:27:46.319
can scale to take a lot of incoming requests as
468
00:27:46.319 --> 00:27:49.000
long as you quickly hand them off to something else
469
00:27:49.039 --> 00:27:50.400
to like, you know, if you come in, you take
470
00:27:50.400 --> 00:27:52.680
a request, you hand it off to the database, and
471
00:27:52.759 --> 00:27:55.119
you do that asynchronously, it can scale to lots and
472
00:27:55.160 --> 00:27:57.759
lots of things coming in. I mean, I think it's
473
00:27:57.799 --> 00:28:00.680
a Mattel was kind of saying. But if you get
474
00:28:00.680 --> 00:28:03.079
to a point where you're you're trying to do too
475
00:28:03.119 --> 00:28:06.039
much in the event loop itself because you're you're effectively
476
00:28:06.079 --> 00:28:10.279
sharing a single thread, you're now going to slow everything down.
477
00:28:10.319 --> 00:28:13.079
And it follows over a cliff that at one point,
478
00:28:13.119 --> 00:28:15.680
so you know, if you've got longer running tasks, you
479
00:28:15.799 --> 00:28:17.759
really want to push them to worker threads.
480
00:28:18.359 --> 00:28:20.680
And a good example that I think is.
481
00:28:20.680 --> 00:28:25.680
More to or to other servers, but a microservices architecture
482
00:28:25.799 --> 00:28:27.119
something exactly.
483
00:28:27.519 --> 00:28:29.359
The one thing I think is kind of interesting is
484
00:28:29.359 --> 00:28:31.240
even if you have your micro service, you say, okay,
485
00:28:31.279 --> 00:28:33.119
I'm going to make a micro service for my very
486
00:28:33.160 --> 00:28:36.400
long running job, you still don't want to block the
487
00:28:36.400 --> 00:28:39.640
event loop for that micro service because the main event loop,
488
00:28:39.759 --> 00:28:43.160
because well, what if you deploy that micro service to Kubernetes.
489
00:28:43.599 --> 00:28:46.440
Kubernetes is probably going to have a liveness check, and well,
490
00:28:46.480 --> 00:28:48.240
how is that liveness check going to run? It's going
491
00:28:48.319 --> 00:28:50.079
to have to hit that main event loop and say hey,
492
00:28:50.160 --> 00:28:51.000
are you still alive?
493
00:28:51.799 --> 00:28:57.160
And sorry? I We literally had this problem, okay at
494
00:28:57.160 --> 00:29:00.000
the company that I worked at, again without naming names,
495
00:29:00.559 --> 00:29:08.519
we were actually using Prometheus, the Prometheus client, and without
496
00:29:08.559 --> 00:29:13.880
going into reasons, the Prometheus response that was being generated
497
00:29:14.039 --> 00:29:18.440
was huge, and it was a huge string being serialized
498
00:29:19.599 --> 00:29:23.559
and that just took too long. And if that happened
499
00:29:23.680 --> 00:29:27.480
while the liveness check happened to come in, it could
500
00:29:27.519 --> 00:29:31.440
literally cause the liveness check to time out and cause
501
00:29:31.599 --> 00:29:33.559
Kobernetes to kill that instance.
502
00:29:34.079 --> 00:29:37.799
Yeah, so you always want to push your long running
503
00:29:37.960 --> 00:29:41.279
jobs onto worker threads so that your main event luke
504
00:29:41.319 --> 00:29:42.480
can respond quickly.
505
00:29:44.880 --> 00:29:49.480
Yeah, and this problem is not unique to note, not
506
00:29:49.480 --> 00:29:52.319
by any stretch. Now, in other run times, it manifests
507
00:29:52.559 --> 00:29:55.920
differently like workers, and we have a completely different threading
508
00:29:55.920 --> 00:30:00.599
model and workers to note, every request is running on
509
00:30:00.599 --> 00:30:03.559
its own thread coming in. We can still accept other
510
00:30:03.599 --> 00:30:07.440
requests and that kind of thing, but and isolate, a
511
00:30:07.519 --> 00:30:11.640
particular worker might be used by multiple threads. So whenever
512
00:30:11.920 --> 00:30:16.200
one request is being processed on one thread, right, no
513
00:30:16.359 --> 00:30:19.680
other threads can use that isolate, that can can use that,
514
00:30:19.799 --> 00:30:22.200
you know, that particular instance. And we have to share these.
515
00:30:22.599 --> 00:30:24.119
So we have these things that are all you know,
516
00:30:24.160 --> 00:30:27.039
basically lock contention. It's waiting for that locks, you know,
517
00:30:27.079 --> 00:30:28.960
waiting for that isolate to be free so I can
518
00:30:29.039 --> 00:30:31.519
use it on this particular thread and it jumps around
519
00:30:31.880 --> 00:30:35.799
the effect. It's a different mechanism but has the same
520
00:30:35.960 --> 00:30:39.880
effect of blocking other things. If one particular request has
521
00:30:39.960 --> 00:30:42.880
too much synchronous processing, it goes on for too long,
522
00:30:43.720 --> 00:30:47.759
then other threads can't acquire that lock and can't progress,
523
00:30:47.839 --> 00:30:50.279
They can't you know, run their own jobscript and it
524
00:30:50.359 --> 00:30:52.559
ends up being the same basic effects blocking the note
525
00:30:52.559 --> 00:30:53.039
event loop.
526
00:30:54.480 --> 00:30:59.319
So you just sorry, you just just that I'm not
527
00:30:59.440 --> 00:31:03.000
used to thinking about blocks soften in the context of JavaScript.
528
00:31:03.160 --> 00:31:04.240
That's all I wanted to say.
529
00:31:05.359 --> 00:31:07.519
Yeah, I mean, but they're there, you know, And in
530
00:31:07.920 --> 00:31:11.519
the key concept here for this particular pillar is yes,
531
00:31:11.599 --> 00:31:13.559
run jobscript all you want, just do it in short
532
00:31:13.640 --> 00:31:18.640
span you know, first, don't do these huge, long, secretus processes.
533
00:31:19.599 --> 00:31:24.559
So basically, either push processing off of the main note
534
00:31:26.720 --> 00:31:32.400
thread to workers, to micro services whatever, don't and don't
535
00:31:32.519 --> 00:31:34.680
wait on them, just send it and wait for their
536
00:31:34.720 --> 00:31:42.799
synchronous response. Or break your long running JavaScript into multiple
537
00:31:42.960 --> 00:31:48.640
shorter segments might see anything, you know, the set time
538
00:31:48.720 --> 00:31:53.160
out zero for the wind.
539
00:31:51.799 --> 00:31:53.960
Typically the task the company.
540
00:31:55.559 --> 00:31:59.200
But yes, unfortunately, yes, okay, in that way, other things
541
00:31:59.279 --> 00:32:00.519
can be scheduled in between.
542
00:32:01.160 --> 00:32:04.119
Okay, So that's the gist.
543
00:32:04.279 --> 00:32:07.000
But genetically, I would say that we do have enough
544
00:32:07.400 --> 00:32:11.160
technologies right now to run things easily on worker threads
545
00:32:11.279 --> 00:32:15.000
that you should just be using trads like literally, most
546
00:32:15.039 --> 00:32:16.359
developers don't think.
547
00:32:18.119 --> 00:32:20.839
That no JS is multi threaded these days.
548
00:32:21.079 --> 00:32:24.480
It has been since twenty eighteen, and most developers since
549
00:32:24.680 --> 00:32:27.519
you know, they're still reading that tutorial from twenty fifteen.
550
00:32:28.079 --> 00:32:32.359
So that's a problem.
551
00:32:33.599 --> 00:32:36.279
I have to say that there is one issue with it,
552
00:32:37.160 --> 00:32:39.599
and I know that there are several proposals that are
553
00:32:39.680 --> 00:32:42.160
looking to address it, but so far it still exists,
554
00:32:42.240 --> 00:32:45.599
and it's more of a JavaScript issue than a note issue,
555
00:32:46.119 --> 00:32:52.799
and it's that serializing stuff across workers can be sometimes
556
00:32:52.920 --> 00:32:57.319
more expensive that the actual work that was offloaded. Like
557
00:32:57.519 --> 00:33:01.519
serializing and de serializing each way can sometimes be more
558
00:33:01.559 --> 00:33:04.279
expensive than the actual work that you're afloaded if you're
559
00:33:04.319 --> 00:33:05.240
not careful.
560
00:33:05.200 --> 00:33:07.920
Of course, but it means that you need to upfload
561
00:33:08.000 --> 00:33:09.960
staff that is beer essentially.
562
00:33:10.720 --> 00:33:13.000
Yeah, yeah, and there are ways around that, you know,
563
00:33:13.079 --> 00:33:15.759
with with you know, my shared array offfer and some
564
00:33:15.880 --> 00:33:17.079
of the shared data structures we have.
565
00:33:17.240 --> 00:33:18.000
So yeah.
566
00:33:19.200 --> 00:33:24.799
So Node has the ability to run multiple processes, so
567
00:33:24.920 --> 00:33:27.519
you can you can fork, and you can I don't
568
00:33:27.519 --> 00:33:31.000
remember exactly. I kind of forgot it because it turned
569
00:33:31.000 --> 00:33:33.039
out not to be useful for this very reason that
570
00:33:33.200 --> 00:33:38.119
the the communication between Node processes of doing the Jason
571
00:33:38.160 --> 00:33:41.519
stringifying the Jason parse makes it so that you should
572
00:33:41.599 --> 00:33:44.440
probably never ever do that. And the only way that
573
00:33:44.480 --> 00:33:46.599
you should be using Node if you're going to use
574
00:33:46.640 --> 00:33:49.680
multiple processes, not it is not it's it's child process
575
00:33:49.759 --> 00:33:53.960
forking mechanism, but rather you just run multiple processes. They
576
00:33:54.000 --> 00:33:58.400
handle all multiple requests and let them you know, donect
577
00:33:58.440 --> 00:34:01.440
to the database, separate and stuff. Yeah, well where would
578
00:34:01.480 --> 00:34:06.039
that where would that be profitable? Where? Where would it
579
00:34:06.160 --> 00:34:10.000
actually make sense to use that? Oh, cluster, it's called
580
00:34:10.039 --> 00:34:14.119
node cluster, right, yeah, is that what it's called. Yeah, yeah,
581
00:34:14.239 --> 00:34:15.920
so I think it's kind of a secure feature most
582
00:34:15.920 --> 00:34:20.039
people know about. Yeah, I think today what we're doing good.
583
00:34:20.639 --> 00:34:22.519
I was going to say today, I would defer to
584
00:34:22.800 --> 00:34:26.480
other things, Like you know, Kubernetes will manage multiple instances
585
00:34:26.519 --> 00:34:29.760
of your node application, each which should be stateless. So
586
00:34:29.920 --> 00:34:32.199
like if you want to scale, there's lots of non
587
00:34:32.320 --> 00:34:35.239
node specific ways of scaling processes out, so you can
588
00:34:35.280 --> 00:34:38.960
have multiple compaties of your your microwins, of your micro service.
589
00:34:39.000 --> 00:34:40.800
So that's why I wouldn't necessarily be using the cluster
590
00:34:40.920 --> 00:34:45.840
module on its own anymore. So it's really like, you know,
591
00:34:45.960 --> 00:34:48.880
I would typically scale using those technologies when it's a
592
00:34:48.960 --> 00:34:51.760
matter of just needing more than one thread's worth worth
593
00:34:51.840 --> 00:34:55.639
of you know, throughput, because you could have lots of
594
00:34:55.679 --> 00:34:58.039
little tasks, but you just still can't handle all those
595
00:34:58.119 --> 00:35:00.519
tasks on a single thread, in which case let's scale
596
00:35:00.559 --> 00:35:04.280
out to multiple processes. But if you have long running tasks.
597
00:35:04.599 --> 00:35:07.920
Even if you have enough to maybe only take fifty
598
00:35:07.960 --> 00:35:10.360
percent of your single CPU, you don't want to do
599
00:35:10.519 --> 00:35:12.760
those on your main thread loop. You want to still
600
00:35:12.800 --> 00:35:15.239
push those two workers because you don't want to be
601
00:35:15.280 --> 00:35:17.840
blocking all the all the work based on those lower
602
00:35:18.119 --> 00:35:20.280
or longer transactions, right, even if there's like one in
603
00:35:20.440 --> 00:35:24.400
ten every tenth second, you don't want to have something
604
00:35:24.440 --> 00:35:26.800
that takes a really long time and slows everybody. Yeah.
605
00:35:26.840 --> 00:35:28.840
I think it was Jake Archibald that said it in
606
00:35:28.960 --> 00:35:31.480
the context, or maybe it was a Somat that said
607
00:35:31.519 --> 00:35:33.519
it in the context of browsers that one of the
608
00:35:33.599 --> 00:35:36.840
reasons that you want to offload things to workers is
609
00:35:36.920 --> 00:35:41.159
not so much sorry about performance, it's more about consistency.
610
00:35:42.760 --> 00:35:45.480
That you don't want all of the like every x
611
00:35:45.639 --> 00:35:49.440
task to suddenly block your system for too long. I
612
00:35:49.559 --> 00:35:51.800
do have to say though, that in my experience, most
613
00:35:51.840 --> 00:35:54.239
of the work that I've seen done on loade is
614
00:35:54.360 --> 00:35:58.599
mostly as quote unquote middleware, so very often there's not
615
00:35:58.880 --> 00:36:04.239
so much heavy lifting being done inside the note service itself.
616
00:36:04.599 --> 00:36:05.519
Let's say it this way.
617
00:36:05.920 --> 00:36:06.719
Are you sure done?
618
00:36:08.360 --> 00:36:10.360
No, I'm not. I'm scared.
619
00:36:10.920 --> 00:36:14.079
Let's let if you if you take a look at
620
00:36:14.280 --> 00:36:19.719
what the all the front end meta frameworks are doing lately.
621
00:36:20.320 --> 00:36:26.480
They all of them, they are massively blocking the develope
622
00:36:27.280 --> 00:36:27.760
like they.
623
00:36:30.000 --> 00:36:33.599
All of the rendering code, the service rendering stuff.
624
00:36:33.920 --> 00:36:37.639
Yes, so in that scenario, if you are already I
625
00:36:37.719 --> 00:36:41.960
have a very expensive rendering pipeline and you also need
626
00:36:42.000 --> 00:36:46.039
to do some data processing, data mangling that can take
627
00:36:46.119 --> 00:36:47.000
some CPU.
628
00:36:46.800 --> 00:36:50.960
Time, you are really really you really really want to
629
00:36:51.000 --> 00:36:56.079
push it somewhere else. Okay, and you do well, not
630
00:36:56.320 --> 00:36:59.119
on the not on the tutorials, but yeah, you can
631
00:37:00.119 --> 00:37:01.599
not on their maint not on the mein.
632
00:37:01.559 --> 00:37:04.480
To No, I'm asking if from your experience, the framework
633
00:37:04.599 --> 00:37:10.320
makers are doing the the best, you know, the best
634
00:37:10.360 --> 00:37:12.320
that they could do to offload stuff.
635
00:37:12.519 --> 00:37:15.719
You know, they are in order to turn it better.
636
00:37:16.360 --> 00:37:19.000
It's getting better and better and better. And I think
637
00:37:19.119 --> 00:37:21.960
it's it's not like a lot of it comes around
638
00:37:22.320 --> 00:37:26.559
on the marketing side versus the framework itself. Okay, then
639
00:37:26.840 --> 00:37:29.639
nothing in the frameworks blocks you to do certain things, okay,
640
00:37:30.119 --> 00:37:33.599
But it's more about how they market they frameworks and
641
00:37:33.639 --> 00:37:40.960
the products that cause, like the they make, the they
642
00:37:41.039 --> 00:37:44.960
make those applications. You know, they teach developers using their
643
00:37:45.000 --> 00:37:49.440
frameworks very often that they could do certain things, and
644
00:37:49.599 --> 00:37:52.480
those certain things will work very well up until a point,
645
00:37:53.039 --> 00:37:54.840
and then they won't work anymore.
646
00:37:55.320 --> 00:37:57.159
But they then don't tell you that point.
647
00:37:57.880 --> 00:38:01.119
Yeah, and the promotereos example I think I gave is
648
00:38:01.280 --> 00:38:03.000
a pretty good representation of that.
649
00:38:03.840 --> 00:38:04.800
Yeah for that.
650
00:38:05.079 --> 00:38:07.960
Okay, what we have recently been done and we have
651
00:38:08.039 --> 00:38:11.000
losen as a product called the VA Application Server. And
652
00:38:11.159 --> 00:38:15.000
what we do is we keep we use one work thread,
653
00:38:15.480 --> 00:38:18.440
so we run the applications in the application in a
654
00:38:18.480 --> 00:38:21.920
worker thread and we keep the prometheus in the main thread.
655
00:38:22.440 --> 00:38:26.239
So in this way we can have the monitor okay,
656
00:38:27.639 --> 00:38:33.280
not affected by the application itself. And in this way
657
00:38:33.519 --> 00:38:34.639
you can keep things.
658
00:38:35.440 --> 00:38:40.000
We can keep things responsive and app okay and be
659
00:38:40.079 --> 00:38:43.119
able to monitor them correctly even if the application is
660
00:38:43.239 --> 00:38:43.960
under eavylod.
661
00:38:46.119 --> 00:38:48.719
Yeah. By the way, just to toot my own horn,
662
00:38:48.840 --> 00:38:52.320
I actually contributed back into the prompt client project and
663
00:38:52.400 --> 00:38:57.519
optimization that basically just reduced the runtime cost of serializing
664
00:38:57.599 --> 00:39:00.519
the string by something like fifty percent. Uh.
665
00:39:02.119 --> 00:39:04.559
That serialization thing, and going back to you know it
666
00:39:04.800 --> 00:39:08.559
is you know original point there about the cost of
667
00:39:09.000 --> 00:39:11.840
serializing the data back and forth across these boundaries, right,
668
00:39:11.920 --> 00:39:13.320
you know, it doesn't matter if you're using a worker
669
00:39:13.360 --> 00:39:17.119
thread or a child process or whatever, I PC doesn't matter.
670
00:39:17.639 --> 00:39:20.679
The serialization and de serialization back and forth those boundaries
671
00:39:20.800 --> 00:39:24.119
always has a cost. You can use you know, faster
672
00:39:24.480 --> 00:39:27.719
serialization framework so proto buff or cat and P versus,
673
00:39:27.840 --> 00:39:31.320
you know, instead of serializing everything as is JSON, but
674
00:39:31.440 --> 00:39:34.239
you're still going to have a cost. So it's like
675
00:39:34.320 --> 00:39:38.239
anytime you're you're distributing this load you need to do,
676
00:39:38.519 --> 00:39:41.039
you take effort, takes steps to minimize the amount of
677
00:39:41.079 --> 00:39:43.280
serialization de serialization you're going to do. You're using a
678
00:39:43.360 --> 00:39:46.679
child process rather than sending a large chunk of JSON
679
00:39:47.480 --> 00:39:50.039
just past the FD right and let the let that
680
00:39:50.159 --> 00:39:52.480
child process you know, read the data off the off
681
00:39:52.519 --> 00:39:54.599
the network and do its own you know, don't parts
682
00:39:54.960 --> 00:39:58.880
or whatever. If you're doing worker threads, use shared data
683
00:39:58.920 --> 00:40:01.679
objects like shared rape buffer rather than things that need
684
00:40:01.760 --> 00:40:06.079
to get copied and serialized using structured clone. The more
685
00:40:06.599 --> 00:40:08.400
of those kinds of things you do, the more effective
686
00:40:08.599 --> 00:40:12.239
this this load distribution is going to be because you're
687
00:40:12.280 --> 00:40:13.719
not going to eat the you know, eat up all
688
00:40:13.760 --> 00:40:17.360
your your performance gain on serialization de serialization costs.
689
00:40:19.519 --> 00:40:22.239
Well, we've been stuck on the first pillar for such
690
00:40:22.239 --> 00:40:24.320
a long time, it's pretty obvious we won't be able
691
00:40:24.400 --> 00:40:26.679
to run through all the pillars, which is just a
692
00:40:26.760 --> 00:40:31.079
great excuse to invite you all over again. But still,
693
00:40:31.239 --> 00:40:34.360
unless somebody else wants to say something about the first pillar,
694
00:40:34.760 --> 00:40:36.800
I think we'll move on to the second one. Is
695
00:40:36.840 --> 00:40:37.480
that okay with it?
696
00:40:37.519 --> 00:40:39.559
I think we have covered the second one too.
697
00:40:39.559 --> 00:40:39.760
You know.
698
00:40:41.880 --> 00:40:44.679
Yeah, so an extent we have. It's a monitor note
699
00:40:44.719 --> 00:40:47.559
specific metrics and act on them. This is one of
700
00:40:47.639 --> 00:40:51.719
those recommendations which is true everywhere, for every system, not
701
00:40:52.000 --> 00:40:54.880
just for Note. I will say that I'll be monitoring.
702
00:40:55.559 --> 00:40:59.800
Yeah, there's there's one here that is worth calling out.
703
00:41:00.199 --> 00:41:03.159
Most people, most new users, even even the long terms,
704
00:41:03.320 --> 00:41:07.679
aren't familiar with event loop utilization. Folks still talk about
705
00:41:07.719 --> 00:41:11.519
event loop delay, right, and that is a different metric.
706
00:41:12.039 --> 00:41:15.880
Event look utilization is a relatively new concept. It's been
707
00:41:15.920 --> 00:41:17.719
there for a couple of years. Most people don't know.
708
00:41:17.719 --> 00:41:21.719
About it, and it's amazing. James maybe four.
709
00:41:21.920 --> 00:41:22.119
Yeah.
710
00:41:23.199 --> 00:41:27.280
The evently utilization is a measurement of how effectively your
711
00:41:27.880 --> 00:41:31.800
event loop is processing tasks versus waiting for things.
712
00:41:32.480 --> 00:41:32.559
Uh.
713
00:41:32.599 --> 00:41:35.960
And it's it's a much more accurate metric of how
714
00:41:36.920 --> 00:41:40.079
well your application is performing than event loop delay, so
715
00:41:40.400 --> 00:41:43.360
everyone should continue.
716
00:41:44.159 --> 00:41:47.320
Yeah, because I would like you to explain it. I'm
717
00:41:47.440 --> 00:41:50.639
familiar with the term with a metric called event loop lag.
718
00:41:50.960 --> 00:41:53.679
Is that just an alternate name for event loop delay?
719
00:41:54.639 --> 00:41:56.639
Yeah, that I would think so.
720
00:41:56.800 --> 00:42:02.360
Yeah, so event loop, which I knew was basically what
721
00:42:02.480 --> 00:42:06.599
you described. It's like looking at the meantime or the
722
00:42:06.719 --> 00:42:11.440
ninetieth percentile between when an event gets into the queue
723
00:42:11.800 --> 00:42:14.719
and until it gets processed pulled from the queue in
724
00:42:14.840 --> 00:42:18.440
order to be processed. And obviously they're the statement was
725
00:42:19.159 --> 00:42:21.400
you know, you want the mean value or the ninetieth
726
00:42:21.440 --> 00:42:25.280
percentile or whatever to be basically as low as possible
727
00:42:25.599 --> 00:42:27.800
in order for the system to be responsible. But you're
728
00:42:27.880 --> 00:42:31.519
talking about something else. You're talking about event loop utilization.
729
00:42:31.719 --> 00:42:33.400
Can you explain that metric to us.
730
00:42:34.920 --> 00:42:37.360
Yeah, I mean there's a few things Ago went to it,
731
00:42:37.480 --> 00:42:41.079
but it's basically a ratio of how how much time
732
00:42:41.639 --> 00:42:46.239
your event loop is spending doing things versus just sitting
733
00:42:46.280 --> 00:42:49.639
idle waiting for things. So let's say if you have
734
00:42:50.079 --> 00:42:52.840
an event loop that is just going off, your application
735
00:42:53.000 --> 00:42:55.320
is just going up and scheduling a whole bunch of IYO,
736
00:42:56.159 --> 00:42:57.599
and then it has to wait a long time for
737
00:42:57.679 --> 00:43:00.599
that io to do anything, and in between as times
738
00:43:00.960 --> 00:43:05.800
it's not actually processing anything else. Right, In that case,
739
00:43:05.880 --> 00:43:10.159
your event loop is not being utilized effectively. It's spending
740
00:43:10.199 --> 00:43:13.480
most of this time being idle waiting for stuff. But
741
00:43:13.559 --> 00:43:16.440
if that event loop is able to turn over very
742
00:43:16.519 --> 00:43:19.000
very quickly accept a new request, except a new request
743
00:43:19.159 --> 00:43:23.039
while it's processing other things while it's waiting for that
744
00:43:23.159 --> 00:43:26.000
other step to happen, if it's able to keep processing things,
745
00:43:26.039 --> 00:43:28.920
then you're going to see a higher utilization. That basically
746
00:43:29.000 --> 00:43:35.039
means your event loop is doing more more efficiently. I
747
00:43:35.119 --> 00:43:37.519
hope that's there's a whole paper.
748
00:43:37.320 --> 00:43:40.679
On it, Okay, but I'd be happy to have a
749
00:43:40.760 --> 00:43:43.519
link to that paper. But one thing does concern me.
750
00:43:43.639 --> 00:43:46.239
It does seem that if I pull in like the
751
00:43:46.320 --> 00:43:51.639
first event, and that triggers an infinite computation, which means
752
00:43:51.719 --> 00:43:54.679
all the other things are just stuck in the queue forever,
753
00:43:55.320 --> 00:43:59.000
my event loop utilization would still appear to be great
754
00:43:59.199 --> 00:44:01.840
because I'm just processing forever.
755
00:44:02.079 --> 00:44:05.000
Like is that more?
756
00:44:05.000 --> 00:44:06.039
Am I missing something?
757
00:44:07.000 --> 00:44:09.760
Yeah? Missing some of the details. It takes some of
758
00:44:09.840 --> 00:44:12.920
those those things into consideration. The paper goes into a
759
00:44:12.960 --> 00:44:15.880
lot more detail, and this was done by trepreneurs at
760
00:44:15.960 --> 00:44:19.360
notes source that the blog post he wrote on this
761
00:44:19.480 --> 00:44:23.599
initially introducing it answers pretty much all the questions about it.
762
00:44:24.320 --> 00:44:27.159
It is one of the best research you.
763
00:44:27.239 --> 00:44:32.239
Can You can take event loubutalization and in a slightly
764
00:44:32.320 --> 00:44:36.159
different way. Okay, consider this an event look delay or
765
00:44:36.199 --> 00:44:36.880
event look blog.
766
00:44:37.079 --> 00:44:41.639
Okay. It's a metric okay that you can measure after
767
00:44:41.800 --> 00:44:42.480
there is a lag.
768
00:44:43.039 --> 00:44:47.079
Okay, however, you only have a lag okay if your
769
00:44:47.159 --> 00:44:53.000
event loop is very busy, correct, Okay. Event loopertilization is
770
00:44:53.079 --> 00:44:56.239
able to tell you that the event your event loop
771
00:44:56.320 --> 00:44:59.400
is getting busy, so you can act on it way
772
00:44:59.559 --> 00:45:04.119
sooner then the event loop at Okay.
773
00:45:04.679 --> 00:45:05.880
In fact, is it much.
774
00:45:05.800 --> 00:45:09.360
Basically what you're saying. What you're saying. If I'm taking
775
00:45:09.440 --> 00:45:12.519
too long to process user requests, but I have very
776
00:45:12.599 --> 00:45:15.920
few users, then I might not notice that I have
777
00:45:16.039 --> 00:45:18.800
a problem, and by the time I do realize I
778
00:45:18.840 --> 00:45:21.000
have a problem, it's kind of too late in a
779
00:45:21.119 --> 00:45:24.880
sense because users are already suffering. What you're saying is
780
00:45:24.960 --> 00:45:29.559
with event loop utilization, I'll be noticing it much earlier
781
00:45:30.079 --> 00:45:33.039
and be able to respond to it, you know, in advance.
782
00:45:33.280 --> 00:45:36.199
It's really interesting I very much would like to look
783
00:45:36.239 --> 00:45:38.159
at the paper it's.
784
00:45:40.239 --> 00:45:42.880
It does. Go ahead, and I'll just mentioned real quick.
785
00:45:42.880 --> 00:45:44.519
The other thing that it does is it tells you
786
00:45:44.639 --> 00:45:47.280
how well you're scaling, and it gives you a much
787
00:45:47.320 --> 00:45:51.119
more accurate scaling point. So a lot of applications previously
788
00:45:51.159 --> 00:45:55.000
would look at CPU usage right and when when Note
789
00:45:55.039 --> 00:45:59.039
process is primarily just one thread, one main application thread.
790
00:45:59.079 --> 00:46:03.440
Before we had worker threads, that was an okay measurement,
791
00:46:03.519 --> 00:46:05.480
but it was still pretty noisy. As soon as we
792
00:46:05.519 --> 00:46:08.599
introduced worker threads, the CPU monitoring just goes out the
793
00:46:08.639 --> 00:46:10.880
window because it becomes way too noisy because you're you know,
794
00:46:10.960 --> 00:46:13.880
because it's it's not fine grained enough to be able
795
00:46:13.920 --> 00:46:20.480
to show you individual event loop processes. Uh. The event
796
00:46:20.519 --> 00:46:24.639
look utilization is per event loop, so it's per worker thread,
797
00:46:24.719 --> 00:46:27.679
and it gives you a much better signal at where
798
00:46:27.760 --> 00:46:29.960
you where and when you need to start scaling your
799
00:46:30.000 --> 00:46:35.280
application to multiple processes and multiple worker threads. Uh. You know,
800
00:46:35.440 --> 00:46:37.559
you know, better than any other metric that I've seen,
801
00:46:37.679 --> 00:46:39.480
this is the one that gives you the best, the
802
00:46:39.840 --> 00:46:40.960
best accuracy for that.
803
00:46:41.880 --> 00:46:46.000
And monitoring systems these days do they expose this metric.
804
00:46:48.000 --> 00:46:48.199
Well.
805
00:46:48.239 --> 00:46:54.079
Plus formatting does so. Sorry for the for the pon here,
806
00:46:54.400 --> 00:46:59.039
but yeah, we would product our product absolutely, but also
807
00:46:59.159 --> 00:47:02.079
all our open source expose this metric on as part
808
00:47:02.199 --> 00:47:06.519
of the promissious integration, so you can essentially take it
809
00:47:06.639 --> 00:47:08.559
and consume it and so on and sup forth. The
810
00:47:08.639 --> 00:47:11.880
important part is that you want you want to set
811
00:47:11.920 --> 00:47:16.320
your out of scale to uh, look at this metric
812
00:47:16.519 --> 00:47:21.239
versus CPU. Okay, if you if you look at CPU usage,
813
00:47:21.360 --> 00:47:23.480
you are typically is too luggy.
814
00:47:23.920 --> 00:47:24.239
Okay.
815
00:47:24.960 --> 00:47:28.480
Once, once you see once the horizontal product of scaler
816
00:47:28.639 --> 00:47:31.800
see that stuff, you are you are already in trouble.
817
00:47:31.960 --> 00:47:32.280
Okay.
818
00:47:34.360 --> 00:47:37.480
But it's not a metric that's built into no or whatever.
819
00:47:37.639 --> 00:47:41.559
There's no like no evens there's an API board. Yeah,
820
00:47:42.039 --> 00:47:44.400
there's an a p I built into it directly in
821
00:47:44.440 --> 00:47:46.480
the it's part of the perfect.
822
00:47:46.159 --> 00:47:48.159
Say you need to enable it in from client.
823
00:47:49.840 --> 00:47:52.920
Very cool, very cool. We'll definitely look at it. Thank
824
00:47:52.960 --> 00:47:59.800
you for that. Anything else about pillar number two? Okay,
825
00:47:59.840 --> 00:48:03.440
the and moving on to pillar number three news node
826
00:48:03.679 --> 00:48:08.119
LTS versions in production. I think it even though people
827
00:48:08.199 --> 00:48:10.920
listening to us should be familiar with node, I think
828
00:48:11.000 --> 00:48:14.960
it's worthwhile to mention what node LTS versions actually mean.
829
00:48:17.559 --> 00:48:18.960
Yeah, long term supports.
830
00:48:19.239 --> 00:48:23.000
Basically, Michael, you want to take it, sure, Yeah, like
831
00:48:23.119 --> 00:48:28.039
long you can go to the website on the GitHub.
832
00:48:28.280 --> 00:48:31.159
It's like no gs slash release, it'll have our schedule
833
00:48:31.920 --> 00:48:37.519
the you know, every it's very predictable release schedule. We
834
00:48:37.639 --> 00:48:41.480
have a current which happens every April and October, and
835
00:48:41.559 --> 00:48:44.559
then every even current gets promoted to long term support.
836
00:48:44.559 --> 00:48:46.639
And long term support means I think it's thirty months
837
00:48:46.679 --> 00:48:49.800
of support, so it lasts from you know, October this
838
00:48:50.000 --> 00:48:53.199
year for example, to April two and a half years
839
00:48:53.239 --> 00:48:58.440
from now, and so the odd currents they only have
840
00:48:58.519 --> 00:49:00.960
six months of support. So you know why we say
841
00:49:01.000 --> 00:49:02.840
you really want to stick to the long term support
842
00:49:03.039 --> 00:49:06.159
versions is that you know, that's the longest period of
843
00:49:06.239 --> 00:49:08.800
time that you can sort of be on a version
844
00:49:08.880 --> 00:49:11.239
that's not going to go out of service. And back
845
00:49:11.280 --> 00:49:13.159
to AG's point of like, we don't want to change
846
00:49:13.199 --> 00:49:16.320
things any anytime. We don't want to change them because
847
00:49:16.320 --> 00:49:19.039
it costs us money, right, So you want to basically
848
00:49:19.440 --> 00:49:22.000
look at the release schedule and pet the LTS.
849
00:49:22.119 --> 00:49:23.679
It's going to give you the longest runway.
850
00:49:25.199 --> 00:49:28.559
And you know, I'd also say, like schedule, you don't
851
00:49:28.599 --> 00:49:30.679
have to move up to every LTS because we have
852
00:49:30.960 --> 00:49:33.679
multiple overlapping LTS is we either have like two or
853
00:49:33.719 --> 00:49:36.519
three usually going on at the same time. So if
854
00:49:36.519 --> 00:49:38.960
it was me, I would basically say, like, okay, when
855
00:49:39.000 --> 00:49:40.760
am I want to go into production, let's plan to
856
00:49:40.800 --> 00:49:44.440
have the closest LTS and then you know, two years
857
00:49:44.519 --> 00:49:47.480
later I should plan on like, okay, now let's plan
858
00:49:47.639 --> 00:49:50.960
for upgrading that particular version of the next LTS. There
859
00:49:51.000 --> 00:49:53.639
are multiple phases in LTS as well. There's like an
860
00:49:53.719 --> 00:49:57.519
active phase where we backport changes quite quickly, so if
861
00:49:57.559 --> 00:49:59.320
you want to get new features, they still go into
862
00:49:59.360 --> 00:50:04.679
those LTS releases, but about after the first and I'm
863
00:50:04.880 --> 00:50:08.559
thinking it's eight months ish now I'd have to look
864
00:50:08.639 --> 00:50:12.000
exactly at the numbers. It then flips into maintenance, where
865
00:50:12.119 --> 00:50:15.519
things are more like as needed security, security fixes, that
866
00:50:15.719 --> 00:50:16.239
kind of stuff.
867
00:50:17.519 --> 00:50:21.400
Why do non LTS versions even exist and why would
868
00:50:21.480 --> 00:50:23.039
I ever use one of them?
869
00:50:23.400 --> 00:50:25.719
See that there are people who want to be on
870
00:50:25.840 --> 00:50:29.920
the bleeding edge, and so those ones give you based
871
00:50:29.960 --> 00:50:31.840
on our schedule.
872
00:50:31.960 --> 00:50:33.800
We feed things into those non.
873
00:50:33.760 --> 00:50:35.880
LTS versions first, so if you want to get the
874
00:50:36.079 --> 00:50:39.239
very latest, greatest, you can try them out there, and
875
00:50:39.320 --> 00:50:41.719
we do appreciate that people test them out for us
876
00:50:41.800 --> 00:50:44.239
and give us feedback. And you know, so if you
877
00:50:44.280 --> 00:50:47.039
want to take advantage of a new feature, we really do.
878
00:50:47.159 --> 00:50:49.679
People want want people to try those out and give
879
00:50:49.760 --> 00:50:50.800
us that early feedback.
880
00:50:51.639 --> 00:50:54.760
And there have been cases were I've there have been
881
00:50:54.800 --> 00:50:57.840
cases where I've had to use a non LTS because
882
00:50:57.880 --> 00:51:01.400
there was a critical feature particular related to web crypto
883
00:51:01.920 --> 00:51:06.880
or fetch or one of those standards that is cross
884
00:51:07.800 --> 00:51:12.119
platform standard for JavaScript that was only available first in
885
00:51:12.239 --> 00:51:16.519
the in the non LTS. Right now, for example, nodes
886
00:51:16.840 --> 00:51:21.880
ESM support has finally completed, but it won't be available
887
00:51:22.000 --> 00:51:25.880
until what V twenty four without the flag, so I'll
888
00:51:25.960 --> 00:51:29.880
probably update to V twenty twenty.
889
00:51:33.639 --> 00:51:34.039
Twenty three.
890
00:51:34.760 --> 00:51:35.360
How are you sure?
891
00:51:35.480 --> 00:51:35.679
AJ?
892
00:51:37.599 --> 00:51:41.039
Now I have a very good news for you. I
893
00:51:41.159 --> 00:51:44.119
am really very good news. We are likely thinking of
894
00:51:44.239 --> 00:51:45.679
backparting it to twenty two.
895
00:51:46.320 --> 00:51:46.519
Yeah.
896
00:51:46.559 --> 00:51:50.639
Oh sweet, that's great. Yeah, that's that's that's amazing. Yeah,
897
00:51:50.639 --> 00:51:53.760
because that that's something I've not been using ESM because
898
00:51:53.960 --> 00:51:56.159
you know, like, why would I publish something to NPM
899
00:51:56.239 --> 00:51:59.440
that breaks everybody else's stuff and everybody else has to transpile,
900
00:51:59.559 --> 00:52:02.440
But then all those people using bundlers anyway, like you know,
901
00:52:02.719 --> 00:52:04.719
sm just didn't make any sense. And then when I
902
00:52:04.760 --> 00:52:07.559
saw that, I was like, yeah, finally I get to
903
00:52:08.199 --> 00:52:11.400
to not have to screw around with all this you know,
904
00:52:11.559 --> 00:52:12.559
window crap.
905
00:52:13.760 --> 00:52:15.639
This raises, this raises the good point. It's like why
906
00:52:15.679 --> 00:52:18.000
do we have this, you know, the schedule you know,
907
00:52:18.559 --> 00:52:22.559
back if you think back to when before node niogs,
908
00:52:22.840 --> 00:52:25.639
Node was originally going way too slow. I just came
909
00:52:25.679 --> 00:52:29.159
and was going way too fast. So the CELTS schedule
910
00:52:29.320 --> 00:52:31.360
was a you know, let's find a middle ground, like
911
00:52:31.440 --> 00:52:34.480
we're going to have one LTS per year, but why
912
00:52:34.559 --> 00:52:37.679
do two majors? And the reason for that is because
913
00:52:37.719 --> 00:52:40.440
the ecosystem needs to be able to have these features
914
00:52:40.519 --> 00:52:43.800
out at a faster rate than only one release per year.
915
00:52:45.000 --> 00:52:47.360
And so you know, the the the short term like
916
00:52:47.519 --> 00:52:53.000
odd numbered currents, those are primarily to help the developer
917
00:52:53.079 --> 00:52:57.599
ecosystem in Node, not the like enterprise you know, production users.
918
00:52:58.400 --> 00:53:01.440
Then it's there to help like the module developers and
919
00:53:01.480 --> 00:53:05.519
the ecosystem that are producing all of these dependencies keep
920
00:53:05.639 --> 00:53:08.159
up on a rate of change and allows Node to
921
00:53:08.280 --> 00:53:10.679
be you know, to know like what's actually being used?
922
00:53:10.719 --> 00:53:12.280
How does this need to be evolved? You know, you know,
923
00:53:12.440 --> 00:53:15.360
like actually get used to these things before it goes LTS,
924
00:53:15.480 --> 00:53:18.000
before it goes where we have to maintain something long term.
925
00:53:18.440 --> 00:53:20.880
And it's still considered to be a stable version, an
926
00:53:20.920 --> 00:53:24.519
official stable version, So I'm not like working on some
927
00:53:24.800 --> 00:53:28.159
beta or whatever. I am working on an official version.
928
00:53:28.199 --> 00:53:32.159
I just get the let's call it modern or bloody
929
00:53:32.360 --> 00:53:35.239
bleeding edge features sooner and I don't have to wait
930
00:53:35.320 --> 00:53:38.159
a full year, yes for that stuff, and I can
931
00:53:38.440 --> 00:53:40.840
have it ready in advance of that LTS release.
932
00:53:41.159 --> 00:53:44.559
It still respects semver, so you can expect that there
933
00:53:44.599 --> 00:53:49.800
shouldn't be really any breaking changes, but features going more quickly,
934
00:53:49.880 --> 00:53:52.079
and it really does help us in terms of like
935
00:53:52.559 --> 00:53:55.239
the versions we promote to LTS. It's great to have
936
00:53:55.440 --> 00:53:57.760
that six months as a current because that really helps
937
00:53:57.840 --> 00:54:00.559
us find out, like, are there an things that we
938
00:54:00.719 --> 00:54:02.800
missed in terms of like did something was it more
939
00:54:02.840 --> 00:54:05.840
breaking than we expected? And you know means sort of
940
00:54:05.880 --> 00:54:07.559
that six months means that by the time we go
941
00:54:07.639 --> 00:54:10.159
to LTS, we have a much better chance of it's
942
00:54:10.199 --> 00:54:12.840
just being worrying for everybody, which is what we like.
943
00:54:14.480 --> 00:54:17.000
I really want to be respectful of all your time.
944
00:54:17.400 --> 00:54:21.079
We are nearing the time usually where we start pushing
945
00:54:21.159 --> 00:54:25.480
towards picks. I'd love to continue this conversation for now.
946
00:54:25.559 --> 00:54:29.679
It's also easier earlier for me because we've switched to
947
00:54:29.800 --> 00:54:33.559
daylight savings, and you guys well off of daylight savings,
948
00:54:33.599 --> 00:54:35.719
and you guys are still, at least in the States,
949
00:54:35.760 --> 00:54:38.400
are still there. So I don't know how long you
950
00:54:38.519 --> 00:54:44.079
guys can go. Do we have another thirty something minutes
951
00:54:44.239 --> 00:54:46.400
or do we need to start thinking about wrapping up?
952
00:54:47.880 --> 00:54:48.400
I got time?
953
00:54:49.039 --> 00:54:51.360
Yeah, I'm okay, I'm okay.
954
00:54:51.639 --> 00:54:53.920
Okay, let's keep on going at least for a while.
955
00:54:54.000 --> 00:54:57.760
Let's see how far we can push it. Anything else
956
00:54:57.800 --> 00:55:00.400
about this pillar before we go to the next one,
957
00:55:00.440 --> 00:55:07.360
which is a whopper? Okay? Then, so pillar number four,
958
00:55:08.199 --> 00:55:14.159
it's automated testing, code review, and conformance as much as possible. Again,
959
00:55:14.559 --> 00:55:18.280
this is like an absolute truism of software development that
960
00:55:18.599 --> 00:55:21.480
has you know, it's true for note, but it's practically
961
00:55:21.559 --> 00:55:24.519
true everywhere else in the world. By the way, there's
962
00:55:24.599 --> 00:55:27.000
this click, so I don't know where it's coming from,
963
00:55:27.159 --> 00:55:31.280
but guys, please be aware that there's like this clicking
964
00:55:31.559 --> 00:55:38.440
sound going on anyway. So what do we have to
965
00:55:38.599 --> 00:55:43.719
say about automating tests and code reviews and conformance that's
966
00:55:44.079 --> 00:55:47.840
no specific or is it just you know do it?
967
00:55:48.800 --> 00:55:51.239
I think what my perspective on this would be is that,
968
00:55:51.880 --> 00:55:53.800
you know, one of the advantages white people we here
969
00:55:54.119 --> 00:55:56.719
use nogests is that they can move really quickly and
970
00:55:56.760 --> 00:56:01.000
they can innovate quickly. For me, that's great if you
971
00:56:01.039 --> 00:56:03.800
can move quickly, but it makes your testing and your
972
00:56:03.840 --> 00:56:06.440
regression tests all the more important. So while this is
973
00:56:06.960 --> 00:56:09.760
very important in most cases, it's even more important when
974
00:56:09.760 --> 00:56:13.199
you're moving fast, and because no lets you move fast,
975
00:56:13.880 --> 00:56:15.320
that's why it's so relevant to me.
976
00:56:18.360 --> 00:56:22.280
I'm totally I totally agree. Part of my job at
977
00:56:22.320 --> 00:56:26.320
almost everywhere that I've worked in the past over a
978
00:56:26.440 --> 00:56:31.480
decade is going into existing projects and starting to mess
979
00:56:31.519 --> 00:56:36.280
with them and literally break them. And like, the difference
980
00:56:36.360 --> 00:56:39.599
between between having tests and not having tests is like
981
00:56:39.960 --> 00:56:43.679
life and death. Literally, It's it's like, am I how
982
00:56:43.800 --> 00:56:46.519
confident do I feel even going into this project?
983
00:56:48.239 --> 00:56:48.440
Yeah?
984
00:56:48.519 --> 00:56:51.159
It's like if you can make if you can make
985
00:56:51.239 --> 00:56:54.760
a change, run the test suite and feel pretty comfortable
986
00:56:54.800 --> 00:56:56.679
that it's not going to the world's not gonna light on.
987
00:56:56.760 --> 00:56:59.519
Fire, that's what lets you move fast.
988
00:57:00.119 --> 00:57:01.480
Don't if you're like, oh, I made a.
989
00:57:01.559 --> 00:57:06.039
Change, but nothing's testing this. You're you're always very cautious, right,
990
00:57:06.159 --> 00:57:07.840
I think, and you're not going to go as fast.
991
00:57:09.400 --> 00:57:14.840
Now you did differentiate between like the three different kinds
992
00:57:14.840 --> 00:57:18.719
of tests that people usually talk about, which is unit tests,
993
00:57:19.239 --> 00:57:23.880
integration tests, and end to end tests. Now I'm curious,
994
00:57:24.599 --> 00:57:30.119
like because I hear people, different people putting different emphasis
995
00:57:30.280 --> 00:57:33.960
on different types of tests. So I hardly ever encounter
996
00:57:34.159 --> 00:57:37.400
people who say, you know, you don't need tests, But
997
00:57:37.559 --> 00:57:41.280
I do encounter people who say, you know, it's all
998
00:57:41.320 --> 00:57:44.440
about the end to end tests, and other people are saying, no,
999
00:57:44.719 --> 00:57:47.400
it's all about the unit tests and so forth. So
1000
00:57:47.519 --> 00:57:50.679
I am curious where you guys, which camp you guys
1001
00:57:50.760 --> 00:57:53.320
fall in, if you even do fall in a camp.
1002
00:57:55.519 --> 00:57:58.000
For me, I don't necessarily care about the type of test.
1003
00:57:58.119 --> 00:58:00.679
I care about the test coverage. And I know a
1004
00:58:00.719 --> 00:58:02.519
lot of people, you know, have a problem with chasing,
1005
00:58:02.960 --> 00:58:05.199
like you know, complete test coverage and stuff.
1006
00:58:05.840 --> 00:58:08.360
I don't measuring test coverage.
1007
00:58:08.480 --> 00:58:12.280
Right, I don't care necessarily what kind of test it is.
1008
00:58:12.920 --> 00:58:17.599
I care about is this line of code tested? And
1009
00:58:18.119 --> 00:58:21.239
too often, you know, you know, folks will only test
1010
00:58:21.320 --> 00:58:23.840
the happy path, you know, the only the right test
1011
00:58:23.920 --> 00:58:26.519
based on what they want the code to do, not
1012
00:58:26.920 --> 00:58:29.559
based on what the code actually does. Uh, and they
1013
00:58:29.639 --> 00:58:32.360
end up missing, like you know, coverage on half the
1014
00:58:32.679 --> 00:58:36.639
branches that their code, that their code takes or could take,
1015
00:58:36.679 --> 00:58:38.199
and then they get it into production or make some
1016
00:58:38.280 --> 00:58:40.199
kind of refactoring change and things just break.
1017
00:58:42.360 --> 00:58:45.800
My one of my problems with end two end tests,
1018
00:58:46.599 --> 00:58:50.119
which on the face of on the face of it,
1019
00:58:50.320 --> 00:58:53.760
and to end tests like like they have like they
1020
00:58:53.920 --> 00:58:56.960
could have been the best tests because they literally test
1021
00:58:57.039 --> 00:59:01.400
the system as it should work, but they're from my perspective,
1022
00:59:01.480 --> 00:59:04.320
there are two main issues with it. One is that
1023
00:59:04.719 --> 00:59:09.679
they can run pretty long, which means that people run
1024
00:59:09.760 --> 00:59:15.079
them less often. And the other problem is that testing
1025
00:59:15.199 --> 00:59:18.440
coverage with end to endests, or achieving good coverage with
1026
00:59:18.639 --> 00:59:21.280
end to end tests can be pretty challenging.
1027
00:59:23.119 --> 00:59:26.320
I think a lot of times, as I say, I
1028
00:59:26.360 --> 00:59:28.920
think I'd agree with kind of the challenges, like the
1029
00:59:30.039 --> 00:59:31.960
I think the end N tests like along with that
1030
00:59:32.159 --> 00:59:35.239
is it's sometimes harder to figure out what went wrong,
1031
00:59:36.280 --> 00:59:39.000
or like you made a tiny change and you only
1032
00:59:39.440 --> 00:59:41.360
if you only find that in your end end test,
1033
00:59:41.440 --> 00:59:43.400
it's probably going to be hard to figure out what
1034
00:59:43.519 --> 00:59:45.239
that tiny change is versus.
1035
00:59:45.119 --> 00:59:46.760
List you founders before production.
1036
00:59:47.039 --> 00:59:50.039
Yeah, no, no, So I think it's a balance between
1037
00:59:50.079 --> 00:59:52.360
the two, right, Like I think having unit tests, which
1038
00:59:52.400 --> 00:59:55.239
gives you really good coverage of the very specific things,
1039
00:59:55.480 --> 00:59:58.280
will help you find like, hey, I just made a
1040
00:59:58.320 --> 01:00:01.760
commit and I broke something like on the you know,
1041
01:00:02.719 --> 01:00:06.239
but worlsthing small. I can find that very easily. And
1042
01:00:06.360 --> 01:00:08.360
so you want you want as much unit testing as
1043
01:00:08.400 --> 01:00:10.679
you as you as you can afford to cover you know,
1044
01:00:10.760 --> 01:00:13.000
find those things. But then you still definitely need the
1045
01:00:13.119 --> 01:00:15.840
end to end tests. But you probably don't need to
1046
01:00:15.960 --> 01:00:18.880
test every single thing in the end t end test because,
1047
01:00:18.920 --> 01:00:22.840
like you said, that quickly becomes too long, and you
1048
01:00:22.920 --> 01:00:24.840
know you can't run it as often. Right, So it's
1049
01:00:24.880 --> 01:00:28.079
finding that right balance between you know, having your unit
1050
01:00:28.199 --> 01:00:29.880
tests that can fail, only they won't be able to
1051
01:00:29.920 --> 01:00:32.800
cover everything in the end to end style, but covering
1052
01:00:32.840 --> 01:00:34.519
as much as you can, and then as much of
1053
01:00:34.599 --> 01:00:36.880
the the end end testing is as practical so that
1054
01:00:36.960 --> 01:00:38.760
it still gets run on a regular basis.
1055
01:00:39.239 --> 01:00:41.920
Also, it's much closer to the actual code, so you're
1056
01:00:42.039 --> 01:00:45.760
much less likely to miss branches, at least at the unit.
1057
01:00:45.679 --> 01:00:49.159
Level, right, And a lot of times the integration tests
1058
01:00:50.239 --> 01:00:55.159
are incapable of testing particular branches, like particularly if their
1059
01:00:55.239 --> 01:00:58.559
edge cases or you know, should only happen in like
1060
01:00:58.639 --> 01:01:03.119
critical failure situation where you're into end test isn't actually
1061
01:01:03.159 --> 01:01:06.480
able to trigger those right because it's it's meant to
1062
01:01:06.519 --> 01:01:09.239
be some internal failure or IO is failing in some
1063
01:01:09.440 --> 01:01:13.760
case actually make it make likely.
1064
01:01:14.800 --> 01:01:18.239
Yeah, we all know the remedy to to a critical
1065
01:01:18.920 --> 01:01:20.960
problem which is consoler.
1066
01:01:22.440 --> 01:01:23.760
Mm hmmm, of course.
1067
01:01:24.119 --> 01:01:24.320
Yeah.
1068
01:01:26.800 --> 01:01:31.840
Okay, anything else we want to say about tests, any
1069
01:01:31.960 --> 01:01:35.960
recommendations about the systems you guys use for testing, Any
1070
01:01:36.039 --> 01:01:39.960
particular system or mechanism I should be using as a
1071
01:01:40.000 --> 01:01:41.119
node developer.
1072
01:01:42.079 --> 01:01:44.639
Use no tests, use the new test framework, builped into
1073
01:01:44.679 --> 01:01:45.159
the run time.
1074
01:01:46.400 --> 01:01:49.760
What I can tell is what not to use. Okay,
1075
01:01:51.199 --> 01:01:57.039
don't you just make yourself a faire No, this is true.
1076
01:01:57.119 --> 01:01:59.920
Okay, if you're building a node system, just as a
1077
01:02:00.039 --> 01:02:02.320
lot of good features. If you're building if you're using
1078
01:02:02.360 --> 01:02:07.239
it for some of the front and meta frameworks, okay,
1079
01:02:08.000 --> 01:02:11.039
But if you're building another app and EPI or something
1080
01:02:11.039 --> 01:02:15.440
like that, don't use it, I recommend because you cannot
1081
01:02:15.719 --> 01:02:18.679
test hundred percent of the branches with it, and therefore
1082
01:02:18.960 --> 01:02:23.119
it completely defeats the purpose of a testing framework. So
1083
01:02:24.639 --> 01:02:27.039
if I can't, why is that by the way, because
1084
01:02:27.079 --> 01:02:28.280
the monkey branches globals.
1085
01:02:28.480 --> 01:02:32.920
So if the no emits an error in one of
1086
01:02:33.000 --> 01:02:35.159
his own APIs in.
1087
01:02:36.719 --> 01:02:39.480
However, the error object is not create is different and
1088
01:02:39.559 --> 01:02:42.280
the one that just is put in the global. So
1089
01:02:42.480 --> 01:02:45.480
if you do error instance of error, it tron folds
1090
01:02:45.719 --> 01:02:46.840
even though it's an error.
1091
01:02:50.320 --> 01:02:50.960
You don't know.
1092
01:02:53.199 --> 01:02:57.440
Well, now we have the j aspective error is error.
1093
01:03:00.960 --> 01:03:03.719
I mean that that should that should help. But but yeah,
1094
01:03:03.760 --> 01:03:06.760
with with Justin in the fund, just Jesment, a couple others,
1095
01:03:06.920 --> 01:03:09.880
you know, had this issuable floor where the test and
1096
01:03:09.960 --> 01:03:12.559
it's get the test you write ends up testing the
1097
01:03:12.679 --> 01:03:16.719
mock rather than testing, you know, the actual run time
1098
01:03:16.800 --> 01:03:19.400
the actual code. We had this problem workers, you know
1099
01:03:19.480 --> 01:03:21.960
for the longest time. We're doing local tests, you know,
1100
01:03:22.599 --> 01:03:25.920
because our test framework originally, like that client side part,
1101
01:03:26.760 --> 01:03:28.920
the original version of many flour, was actually running a note.
1102
01:03:29.840 --> 01:03:32.519
So when you would go to all protecting your worker
1103
01:03:32.599 --> 01:03:35.159
and test it, you were actually testing it against nodes
1104
01:03:35.159 --> 01:03:38.119
implementation of something like readable stream. And then you actually
1105
01:03:38.119 --> 01:03:39.840
go to run at the runtime and oaks it breaks
1106
01:03:39.880 --> 01:03:42.280
because we have slight differences and you know, we're getting
1107
01:03:42.280 --> 01:03:43.840
away from that now where you can actually test them
1108
01:03:43.880 --> 01:03:47.239
the actual production code. But a lot of these testom
1109
01:03:47.280 --> 01:03:49.920
works like just have that fundamental problem where you're not
1110
01:03:50.199 --> 01:03:51.760
testing the thing you're actually running.
1111
01:03:54.440 --> 01:03:56.880
And I think Mitaylo's point might be like, it has
1112
01:03:56.960 --> 01:03:59.800
some advantages if you're you know, closer to the front
1113
01:03:59.880 --> 01:04:02.360
end side of things, but if you're really just a
1114
01:04:02.480 --> 01:04:05.679
node micro service, you might be better served by something
1115
01:04:05.760 --> 01:04:08.360
that's more no focused versus that.
1116
01:04:09.559 --> 01:04:12.480
And in that case, just use the built in node
1117
01:04:12.519 --> 01:04:22.320
testing framework. Yeah cool, Okay, moving on to the next one,
1118
01:04:22.519 --> 01:04:26.000
and I think you know what we'll see if this
1119
01:04:26.159 --> 01:04:27.960
is the last one, or we'll manage to get to
1120
01:04:28.119 --> 01:04:30.280
number six. It's kind of stopping in the middle. If
1121
01:04:30.719 --> 01:04:33.360
we stop in this one, and then we'll give us
1122
01:04:33.679 --> 01:04:36.360
an incentive to do another episode. I'd love to have
1123
01:04:36.519 --> 01:04:40.719
you guys on again. This is such an awesome conversation. Okay,
1124
01:04:40.840 --> 01:04:44.400
then number five and again, this is just a golden
1125
01:04:44.480 --> 01:04:48.280
rule in software development, but I think it has special
1126
01:04:48.400 --> 01:04:53.159
meaning in the context of node and that's avoid dependency creep.
1127
01:04:55.199 --> 01:04:58.719
Can we explain what dependency creep means in general and
1128
01:04:58.800 --> 01:05:05.320
what it means specif defically in NOE. So this is.
1129
01:05:07.119 --> 01:05:16.320
Probably one of the most misunderstood practice, especially lately. It's
1130
01:05:17.559 --> 01:05:20.840
like the node has been at the success it had
1131
01:05:21.679 --> 01:05:25.079
only because it was able to solve one specific problem.
1132
01:05:25.199 --> 01:05:28.440
In fact, NO didn't do it, and PM did it
1133
01:05:28.800 --> 01:05:33.000
found a way to do software reuse at massive scale.
1134
01:05:33.880 --> 01:05:38.280
Okay, and by by what ques mechanism?
1135
01:05:38.679 --> 01:05:43.079
Well, by allowing it turns out that your substantial portion
1136
01:05:43.239 --> 01:05:45.199
of that reuse pretty much.
1137
01:05:46.519 --> 01:05:47.880
I don't know if it's a good thing or a
1138
01:05:47.960 --> 01:05:51.239
bad thing, Okay, I am one of like I think.
1139
01:05:52.719 --> 01:05:55.440
I have that you're that guy from the x k
1140
01:05:55.639 --> 01:06:04.960
CD strip about that. It's sortaally it ye, yes, so.
1141
01:06:06.840 --> 01:06:07.920
The that's it.
1142
01:06:08.480 --> 01:06:14.000
Okay, So it's avoid dependency cree so not jes at
1143
01:06:14.079 --> 01:06:17.960
the massive success due to this software used. It allows
1144
01:06:18.079 --> 01:06:21.119
you to, for example, use different versions of the same
1145
01:06:21.199 --> 01:06:25.400
libraries in different dependency trees of your app.
1146
01:06:25.719 --> 01:06:26.000
Okay.
1147
01:06:26.440 --> 01:06:29.679
This means that you can have and this happens very often,
1148
01:06:30.000 --> 01:06:32.880
readable stream one in your code based, retable stream two
1149
01:06:33.079 --> 01:06:35.719
in your code based litable Steam three in your code base,
1150
01:06:35.760 --> 01:06:36.840
and readable steam four.
1151
01:06:37.559 --> 01:06:40.559
Okay, and when I will ship five, you likely have five.
1152
01:06:40.639 --> 01:06:45.840
We'll have five. Okay. That's what it is.
1153
01:06:46.119 --> 01:06:50.719
Okay, so there is there are some modules that get
1154
01:06:50.760 --> 01:06:54.159
a lot of that are and a lot of dependency
1155
01:06:54.280 --> 01:07:00.280
change because typically for the typically historic reason and at
1156
01:07:00.320 --> 01:07:04.239
that point in time it's they were useful, but now
1157
01:07:04.519 --> 01:07:08.719
probably way less. So so maybe you should stop using
1158
01:07:08.840 --> 01:07:13.239
readable that stream and maybe start using you know, not
1159
01:07:13.760 --> 01:07:15.880
they're not just an austream module.
1160
01:07:15.639 --> 01:07:19.360
Because that's all of it. But however there's a lot
1161
01:07:19.440 --> 01:07:21.320
of things where you still want to use that module.
1162
01:07:21.440 --> 01:07:24.559
And therefore here we are. Okay, so you.
1163
01:07:24.679 --> 01:07:28.039
Made actually two points here. I think first of all,
1164
01:07:28.159 --> 01:07:34.760
you're saying node itself is advancing and it's offering many
1165
01:07:34.880 --> 01:07:37.559
built in features that in the past did not exist
1166
01:07:37.760 --> 01:07:40.519
that in the past we would have needed to bring in,
1167
01:07:41.079 --> 01:07:45.199
like third party libraries. Now they're building features in the platform.
1168
01:07:45.800 --> 01:07:50.519
And as with the browser, whenever I can leverage an
1169
01:07:50.559 --> 01:07:54.119
existing part of the platform rather than bringing in a dependency,
1170
01:07:54.800 --> 01:07:58.000
it's it's almost always a good idea. It's going to
1171
01:07:58.079 --> 01:08:02.440
be a stable API or well tested service. API is
1172
01:08:02.519 --> 01:08:04.760
going to be there forever, I don't need to worry
1173
01:08:04.800 --> 01:08:09.480
about maintainability, about security, about who gets ownership of it
1174
01:08:09.639 --> 01:08:14.880
and starts pushing malware into it or whatever. And it's
1175
01:08:15.000 --> 01:08:18.880
probably going to perform better and so many advantages. So
1176
01:08:19.199 --> 01:08:24.159
that's an obvious thing. But the other point you're saying
1177
01:08:24.319 --> 01:08:30.119
is that I should be wary of having multiple versions
1178
01:08:30.439 --> 01:08:36.880
of the same package running within my single node instance.
1179
01:08:37.079 --> 01:08:39.560
Now I understand why it's a bad thing on the
1180
01:08:39.640 --> 01:08:44.920
browser side, because I've actually seen a browser based application
1181
01:08:45.159 --> 01:08:50.199
deliver three different versions of moment js which resulted in
1182
01:08:50.439 --> 01:08:53.439
like a huge download, which is a problem on the client.
1183
01:08:54.359 --> 01:08:56.439
Why is it a problem in my node server?
1184
01:08:56.560 --> 01:09:03.439
Though, the first problem is related to your surface attack.
1185
01:09:04.399 --> 01:09:07.119
Okay, the more dependency you have, the more you are
1186
01:09:07.199 --> 01:09:12.199
exposed to potential attack. You want to have genetically dependency
1187
01:09:12.239 --> 01:09:14.720
that you need and only the dependency that.
1188
01:09:14.760 --> 01:09:16.800
You need in your tree. Okay.
1189
01:09:17.640 --> 01:09:20.800
So this is the first point okay, which you know
1190
01:09:21.000 --> 01:09:23.399
each one is a vector, is a potential attack factor,
1191
01:09:23.560 --> 01:09:26.319
so you need to treat them like that, okay. And
1192
01:09:26.800 --> 01:09:31.159
the other stuff is it increases significantly the install time
1193
01:09:32.039 --> 01:09:34.840
of the application. So if you do and increases I
1194
01:09:34.880 --> 01:09:38.800
don't know, see I time, okay, just attending bit Okay,
1195
01:09:39.159 --> 01:09:42.880
but then another app can have easily three four thousand
1196
01:09:42.920 --> 01:09:46.760
dependencies once all of a sudden done. And then you
1197
01:09:46.880 --> 01:09:49.920
start saying, oh, Okay, can I just maybe remove a
1198
01:09:50.000 --> 01:09:50.880
thousand of those?
1199
01:09:51.560 --> 01:09:55.159
Okay? Each one of them needs to be downloaded independence,
1200
01:09:56.880 --> 01:09:59.760
you know, I'm just like a lot of them, like
1201
01:10:00.439 --> 01:10:05.319
some of them that are trivia, okay, and frankly they should,
1202
01:10:06.000 --> 01:10:09.960
you know, not be molelized, but there we are. And
1203
01:10:10.079 --> 01:10:11.840
some of them they need to.
1204
01:10:11.840 --> 01:10:14.800
Be down leveled, right, I mean, they just people just
1205
01:10:14.880 --> 01:10:17.840
don't update their dependencies when they can, and so some
1206
01:10:18.000 --> 01:10:21.800
of them end up just being brought in just because
1207
01:10:21.840 --> 01:10:23.920
somebody decided not to update.
1208
01:10:25.199 --> 01:10:28.840
It's it's also the fact that it's like it's like
1209
01:10:29.239 --> 01:10:31.600
like this sort of a skeleton, like the hip bone,
1210
01:10:31.680 --> 01:10:34.039
like how that song go the hip bones connected to
1211
01:10:34.159 --> 01:10:36.560
the high bone and so forth. So you bring in
1212
01:10:36.680 --> 01:10:39.520
one note package and that brings in two more, which
1213
01:10:39.640 --> 01:10:42.960
bring in eight more, which bring in sixteen more, and
1214
01:10:43.479 --> 01:10:45.680
and all of a sudden you have like the entire
1215
01:10:45.880 --> 01:10:51.239
universe downloaded into your node instance. And you did put
1216
01:10:51.319 --> 01:10:55.159
that comic strip in your article about how the NPM
1217
01:10:55.319 --> 01:10:59.840
modules folder is heavier than a black hole. How how
1218
01:11:00.399 --> 01:11:01.520
how do I contend with that?
1219
01:11:01.840 --> 01:11:05.760
You know, I think the principle was about, like be
1220
01:11:05.920 --> 01:11:08.880
more intentional about that. If you're gonna you can easily
1221
01:11:09.000 --> 01:11:12.600
pull in a package and you're using some small part
1222
01:11:12.640 --> 01:11:16.560
of that package, and but take you should take a
1223
01:11:16.640 --> 01:11:18.720
look at like, what all did that pull in? If
1224
01:11:18.760 --> 01:11:22.560
that pulled in one hundred other packages and you've effectively
1225
01:11:22.680 --> 01:11:25.560
replaced ten lines of code that you might have written yourself,
1226
01:11:25.760 --> 01:11:27.920
maybe you should just put the ten lines of code
1227
01:11:27.960 --> 01:11:32.039
in right, so you know, as Matteo said, the reuse
1228
01:11:32.159 --> 01:11:36.159
is one of the fast fantastic things about the ecosystem.
1229
01:11:36.199 --> 01:11:39.119
It's really easy to pull in code and reuse it.
1230
01:11:39.239 --> 01:11:42.079
That's great, But I think we could use a little
1231
01:11:42.119 --> 01:11:44.039
bit of a shift towards being a little bit more
1232
01:11:44.119 --> 01:11:46.720
intentional and looking at what you're pulling in versus the
1233
01:11:46.800 --> 01:11:50.239
benefit you get, so that you're you're sort of doing
1234
01:11:50.279 --> 01:11:53.760
the right balance between hey, I'm reusing code easily versus
1235
01:11:53.920 --> 01:11:56.000
the sort of risk that I'm taking on because you know,
1236
01:11:56.039 --> 01:11:58.439
I've got a huge amount of code. It's not just
1237
01:11:58.520 --> 01:12:00.159
the attack factor. What if there's a bug do you
1238
01:12:00.239 --> 01:12:04.039
want to have fixed? You know, are you able to
1239
01:12:04.119 --> 01:12:07.319
do that yourself? If not, that's something you should probably
1240
01:12:07.359 --> 01:12:08.319
at least think a little.
1241
01:12:08.159 --> 01:12:08.560
Bit about it.
1242
01:12:09.119 --> 01:12:14.239
Yeah, maybe you don't actually need left pad right, like, yeah,
1243
01:12:14.840 --> 01:12:21.399
you know, yeah, The sad thing is that, given the
1244
01:12:21.720 --> 01:12:26.000
average experience of developers, there's a good chance that half
1245
01:12:26.079 --> 01:12:28.720
our listeners don't even get that joke about left pad
1246
01:12:28.760 --> 01:12:32.800
because they came into the industry after it happened. Yeah.
1247
01:12:33.439 --> 01:12:35.640
Well, the question is are they still using it today.
1248
01:12:36.640 --> 01:12:38.600
There's a good chance that they are, though, but they
1249
01:12:38.680 --> 01:12:41.359
probably don't know it because they're probably you not using
1250
01:12:41.439 --> 01:12:44.560
it directly, they're probably using something that uses something which
1251
01:12:44.640 --> 01:12:45.359
uses left pad.
1252
01:12:46.399 --> 01:12:48.840
I think we need an ethos change to be more
1253
01:12:48.960 --> 01:12:52.880
like Go and Zig and other same languages, make the
1254
01:12:52.960 --> 01:12:56.760
standard library great again, and get rid of all the
1255
01:12:56.840 --> 01:13:00.520
crap dependencies that I mean, there's so much many even
1256
01:13:00.680 --> 01:13:04.920
security dependencies where the people who are doing it obviously
1257
01:13:05.079 --> 01:13:07.359
don't know what they're doing. You can't blame them because
1258
01:13:07.439 --> 01:13:09.479
no one who did know what they were doing was
1259
01:13:09.560 --> 01:13:12.359
doing it right. But I remember one of the early,
1260
01:13:13.520 --> 01:13:19.960
very very popular OTP libraries was atrocious. You know, there's
1261
01:13:20.119 --> 01:13:23.600
there's there in our industry, I think because of there
1262
01:13:23.680 --> 01:13:26.720
being so much money available, and thank goodness, there isn't now.
1263
01:13:26.800 --> 01:13:31.079
I actually think I hope that the interest rates stay high.
1264
01:13:31.119 --> 01:13:33.359
I hope they don't go down for the sake of
1265
01:13:33.399 --> 01:13:35.680
our industry for the sake of you know, lots of
1266
01:13:35.720 --> 01:13:38.600
other things. Maybe I don't know, but our industry was
1267
01:13:38.760 --> 01:13:42.680
ruined by low interest rates because with free money, there
1268
01:13:42.800 --> 01:13:46.439
was no responsibility to a customer, and then there was
1269
01:13:46.560 --> 01:13:51.600
no there was no craftsmanship, and and then it became
1270
01:13:52.159 --> 01:13:55.319
it became an ego thing like, look, I don't know
1271
01:13:55.439 --> 01:13:58.159
what I'm doing, and I'm getting so much done anyway. Look,
1272
01:13:58.199 --> 01:14:01.159
I don't understand how this frame work works. I don't
1273
01:14:01.279 --> 01:14:03.800
understand how the library works. But look how great I
1274
01:14:03.920 --> 01:14:06.720
am anyway, and we need some sort of an ethos
1275
01:14:06.800 --> 01:14:10.199
change to like, Hey, I'm able to do this with
1276
01:14:10.479 --> 01:14:13.680
just the standard library. Isn't that pretty cool? Hey I'm
1277
01:14:13.720 --> 01:14:16.800
able to understand how my code works. Hey I've got
1278
01:14:16.880 --> 01:14:19.800
a handle on what my application is doing. Because if
1279
01:14:19.840 --> 01:14:22.399
we don't have that etho shift, then we're we're gonna
1280
01:14:22.439 --> 01:14:24.319
get stuck in this the same rut that we're in.
1281
01:14:24.560 --> 01:14:25.800
I mean, like we're not going to leave the right
1282
01:14:25.800 --> 01:14:27.119
We're already stuck in the run. We're not going to
1283
01:14:27.199 --> 01:14:27.560
get out of it.
1284
01:14:29.560 --> 01:14:31.840
So an interesting thing that I have to mention. So
1285
01:14:31.920 --> 01:14:35.159
a few episodes back, we've had we had Ryan Doll
1286
01:14:35.239 --> 01:14:37.760
as a guest to talk about dn O two when
1287
01:14:37.840 --> 01:14:41.560
it came out. Now, interestingly, when DNO itself first came
1288
01:14:41.600 --> 01:14:44.880
out dn O one, one of the things about it
1289
01:14:45.199 --> 01:14:49.720
was that they avoided NPM and did try to provide
1290
01:14:49.880 --> 01:14:53.560
like their own more significant built in standard library. And
1291
01:14:53.720 --> 01:14:57.640
the thing about DNO two is that they will, surprise, surprise,
1292
01:14:57.680 --> 01:14:59.880
they now support NPM because it turns out that we
1293
01:15:00.000 --> 01:15:02.399
without supporting NPM, you can't really.
1294
01:15:03.399 --> 01:15:04.399
Get enough investment.
1295
01:15:05.039 --> 01:15:08.079
Well, not that you can't really build practical things, especially
1296
01:15:08.159 --> 01:15:10.239
for the enterprise users.
1297
01:15:10.720 --> 01:15:13.880
You just want to use users want to reuse NPM models.
1298
01:15:14.479 --> 01:15:16.399
I mean, that's all it is. So that that that
1299
01:15:16.560 --> 01:15:19.479
that the whole joke about NPM being as black hole,
1300
01:15:19.920 --> 01:15:23.159
that's exactly it. It's got such a massive gravity in
1301
01:15:23.199 --> 01:15:26.800
the ecosystem that you cannot avoid it, right and right.
1302
01:15:26.760 --> 01:15:29.439
But I don't I don't say I'm not going to
1303
01:15:29.479 --> 01:15:32.159
go use go because I don't have NPM, or I'm
1304
01:15:32.199 --> 01:15:34.880
not going to use Rust because I don't have NPM. Right.
1305
01:15:35.399 --> 01:15:37.560
I mean, when you create something new, when you create
1306
01:15:37.640 --> 01:15:40.720
something that's fundamentally different, you have the liberty to not
1307
01:15:41.039 --> 01:15:44.720
take the baggage you know from from prior years, Like
1308
01:15:44.840 --> 01:15:47.800
you don't you don't use C and and well, in
1309
01:15:47.920 --> 01:15:50.119
some rare cases you use see and go like seq
1310
01:15:50.239 --> 01:15:52.840
light or something like that. But you know, in other languages,
1311
01:15:52.920 --> 01:15:55.640
they're not They're not afraid to say, Hey, one of
1312
01:15:55.680 --> 01:15:57.640
the reasons we're creating a new language and a new
1313
01:15:57.720 --> 01:16:00.680
platform is because we want to leave the crap. We
1314
01:16:00.800 --> 01:16:02.720
don't want the craft to come with us. I'm not
1315
01:16:02.840 --> 01:16:05.159
I'm sad that Dino conceded on that point.
1316
01:16:05.640 --> 01:16:10.960
I'm not convinced the other languages have have totally I've
1317
01:16:11.039 --> 01:16:13.479
necessarily necessarily done better. They may be in at a
1318
01:16:13.520 --> 01:16:15.439
different point on their journey, Like I know and Go.
1319
01:16:15.720 --> 01:16:19.039
I'm I'm working on build packs for no jest. They're
1320
01:16:19.039 --> 01:16:21.920
written and go. That's the place we actually have like
1321
01:16:22.000 --> 01:16:25.680
a dependencies that's deleted, that's preventing things from being updated.
1322
01:16:25.760 --> 01:16:28.640
And so, like you know, NPM has gone through a
1323
01:16:28.760 --> 01:16:32.159
fairly long learning process, and some of these other languages,
1324
01:16:32.279 --> 01:16:35.520
like it'll be interesting to see if they end up
1325
01:16:35.680 --> 01:16:38.720
in the same place, or you know, they just haven't
1326
01:16:38.800 --> 01:16:40.880
hit some of the challenges that you get with the scale.
1327
01:16:40.960 --> 01:16:41.880
That note has gotten to you.
1328
01:16:42.479 --> 01:16:44.640
I'm trying to remember who said it. It might have
1329
01:16:44.720 --> 01:16:48.039
been Con't. I don't remember, but basically they said that
1330
01:16:48.199 --> 01:16:53.000
without NPM, we wouldn't have had carbon. So so even
1331
01:16:53.239 --> 01:16:58.680
even though even though NPM is not perfect, it's the
1332
01:16:58.800 --> 01:17:01.840
most used and that definitely says something.
1333
01:17:04.119 --> 01:17:09.640
Yes, yeah, I am said that they based Cargo around
1334
01:17:09.720 --> 01:17:11.600
n PM because it shows and it's got a lot
1335
01:17:11.640 --> 01:17:15.000
of the same problems, whereas the Go Package Manager is
1336
01:17:15.199 --> 01:17:18.279
empirically as perfect as it can be, meaning that it
1337
01:17:18.439 --> 01:17:21.239
has the fewest trade offs and you can prove that
1338
01:17:21.359 --> 01:17:24.439
mathematically looking at the graphs, and there's attack where that's
1339
01:17:24.520 --> 01:17:26.840
been done, so that that is really sad that we
1340
01:17:26.920 --> 01:17:30.279
actually have something that we know both mathematically and practically
1341
01:17:30.319 --> 01:17:32.079
works out and we still choose other things.
1342
01:17:33.000 --> 01:17:35.880
Well, there was not there, like they go back.
1343
01:17:36.720 --> 01:17:39.159
M I know, yeah, for NPM, I know, but I'm
1344
01:17:39.199 --> 01:17:41.319
saying cargo, but like it's it's sad.
1345
01:17:41.880 --> 01:17:43.840
Was not there, Sorry, it was not there. I think
1346
01:17:43.880 --> 01:17:45.439
it's Cargo pre dates the Go back.
1347
01:17:47.720 --> 01:17:48.159
Yeah. Yeah.
1348
01:17:48.960 --> 01:17:53.000
I came out very very very late in the game,
1349
01:17:53.560 --> 01:17:57.439
and for a long time, Go was in fact the
1350
01:17:57.560 --> 01:17:59.000
original Lino one.
1351
01:18:00.760 --> 01:18:03.479
Package package Management.
1352
01:18:03.960 --> 01:18:07.279
We came out from Dino from GO and they just said,
1353
01:18:07.319 --> 01:18:10.159
well you point us, do you point it to a URL?
1354
01:18:10.399 --> 01:18:13.159
And then it downloaded and they it handled it.
1355
01:18:13.439 --> 01:18:17.279
It handled it, okay, which was essentially our dependency we're
1356
01:18:17.359 --> 01:18:19.479
managing go prior to that.
1357
01:18:20.880 --> 01:18:23.800
Okay, yeah yeah yeah for the model repost, yeah, that
1358
01:18:24.319 --> 01:18:26.520
was definitely yeah, Okay, I see what you said. Yeah,
1359
01:18:26.520 --> 01:18:28.960
because the it came out in twenty eighteen and then
1360
01:18:29.000 --> 01:18:31.760
it was and it was confirmed final in twenty nineteen,
1361
01:18:31.840 --> 01:18:35.880
which it seems that's more recent than what it seems like.
1362
01:18:35.960 --> 01:18:37.880
It seems like it was a longer time ago. But
1363
01:18:37.920 --> 01:18:41.520
then I guess Rust wasn't really even hitting popularity until
1364
01:18:41.560 --> 01:18:44.439
after twenty eighteen. So when I think about it, I
1365
01:18:45.000 --> 01:18:47.760
my memory is wrong, My memory is corrupt. I'm faulty.
1366
01:18:48.279 --> 01:18:48.640
My bad.
1367
01:18:52.119 --> 01:18:54.000
Yeah, I mean is going back to something, you know,
1368
01:18:54.199 --> 01:18:56.840
the kind of the original thing with the tendency creep
1369
01:18:56.920 --> 01:18:59.199
and everything else. So NPM, like I said, it has
1370
01:18:59.239 --> 01:19:01.920
this massive grab and if if you know, folks are
1371
01:19:02.039 --> 01:19:04.119
using those modules, they want to keep they want to
1372
01:19:04.199 --> 01:19:07.079
keep using them. Unfortunately, there's just so many modules on
1373
01:19:07.079 --> 01:19:11.319
them they don't need to use. My canonical example, if
1374
01:19:11.319 --> 01:19:12.640
you go out there, and I don't want to like
1375
01:19:12.720 --> 01:19:14.560
pick on it too much, but there's a module out
1376
01:19:14.600 --> 01:19:16.479
there called is even all it.
1377
01:19:16.520 --> 01:19:18.720
Does that's parody, that's a joke.
1378
01:19:19.800 --> 01:19:22.439
It doesn't matter. I've seen people use it. It doesn't
1379
01:19:22.479 --> 01:19:24.680
matter if it's a joke because people I've actually seen
1380
01:19:24.760 --> 01:19:26.600
people use this in their code.
1381
01:19:27.760 --> 01:19:32.319
Because not a joke. They used it as not a joke, yes,
1382
01:19:32.520 --> 01:19:36.840
because it was that's story.
1383
01:19:37.600 --> 01:19:40.600
It is scary. But I I know, my the first
1384
01:19:40.640 --> 01:19:43.800
time I I found that isn't even module, which all
1385
01:19:43.880 --> 01:19:47.720
it does is is pull in is odd module and
1386
01:19:48.279 --> 01:19:48.680
negate it.
1387
01:19:50.239 --> 01:19:53.479
And that has a list of a million numbers, right
1388
01:19:53.800 --> 01:19:56.439
or something like that. It's it's not even something simple
1389
01:19:56.520 --> 01:19:58.239
like doing mod no, because I know one of the
1390
01:19:58.319 --> 01:20:02.279
parody modules just has a list of numbers like one
1391
01:20:02.359 --> 01:20:06.439
to a million, and then for every other one returns true. Okay,
1392
01:20:06.840 --> 01:20:07.720
so it's not that bad.
1393
01:20:08.239 --> 01:20:11.079
Now this actually does work, you know, and we'll check
1394
01:20:11.159 --> 01:20:13.520
to the validate that the input is a number and
1395
01:20:14.319 --> 01:20:16.319
you know, and that kind of thing that is odd.
1396
01:20:16.560 --> 01:20:19.399
But all is even does is pull that in and negated.
1397
01:20:19.920 --> 01:20:22.159
I've seen you know, there are a ton of moneys
1398
01:20:22.239 --> 01:20:26.880
on NPM that like you just don't need, and people
1399
01:20:27.039 --> 01:20:29.880
pull them in anyway because they're not thinking about it.
1400
01:20:29.920 --> 01:20:32.239
They're not being intentional about it. Going back to Michael's
1401
01:20:32.239 --> 01:20:35.359
ear their point or they don't understand what the model
1402
01:20:35.439 --> 01:20:38.800
is actually doing, right, and that's what they need to
1403
01:20:38.880 --> 01:20:41.720
be focusing on. Goes back to the same thing with
1404
01:20:41.800 --> 01:20:44.880
it we have a problem intentional about what you're doing.
1405
01:20:45.439 --> 01:20:47.760
I have a problem with that statement because, to a
1406
01:20:47.840 --> 01:20:52.520
great extent, the whole idea if of reuse is that
1407
01:20:52.760 --> 01:20:56.920
I don't need to think about the implementation details. I
1408
01:20:57.039 --> 01:21:00.359
can basically just look at the API surface and be
1409
01:21:00.520 --> 01:21:04.960
content with that. If I assume, if I can assume
1410
01:21:06.880 --> 01:21:13.680
let's call it a good a good actor, if I'm starting,
1411
01:21:13.840 --> 01:21:16.439
if I if I need to start looking under the
1412
01:21:16.520 --> 01:21:21.760
hood of every n PM module that I'm using, why
1413
01:21:21.880 --> 01:21:23.600
am I even using these modules?
1414
01:21:25.680 --> 01:21:28.159
It comes back to the you know, being intentional about
1415
01:21:28.159 --> 01:21:31.039
it right to some extent, Yeah, but you have to
1416
01:21:31.119 --> 01:21:34.119
understand as a trade off, if you don't understand what
1417
01:21:34.199 --> 01:21:37.119
the module is doing, it might be doing something incredibly
1418
01:21:37.399 --> 01:21:41.560
you know performance, you know costly, and you and sudden
1419
01:21:41.600 --> 01:21:43.760
your application is slowing down. You go into production. Why
1420
01:21:43.880 --> 01:21:46.039
is it slowing down? Well, you know, Michael and I
1421
01:21:46.600 --> 01:21:52.000
countless countless of consulting uh jobs. We went out and
1422
01:21:52.039 --> 01:21:54.800
found Hey, it's your dependencies that are slowing you down
1423
01:21:55.079 --> 01:21:57.920
because they're just not you know, written to be very
1424
01:21:58.520 --> 01:22:01.520
performing in any way. In prose ball, we didn't know that.
1425
01:22:01.640 --> 01:22:03.880
If we had known that, we wouldn't have used it. Well,
1426
01:22:04.439 --> 01:22:07.079
you know, do some digging, you know, look at what
1427
01:22:07.159 --> 01:22:12.560
your dependencies are doing, you know it. You have to
1428
01:22:12.640 --> 01:22:13.239
be aware of.
1429
01:22:13.319 --> 01:22:17.960
The a good metric because I think that with rails
1430
01:22:18.279 --> 01:22:20.520
and I don't think that this necessarily was what the
1431
01:22:20.640 --> 01:22:25.840
Rails community intended, but it bad pun you know, the
1432
01:22:25.960 --> 01:22:30.600
idea went off the rails uh dry right, don't repeat
1433
01:22:30.600 --> 01:22:33.760
yourself became it became a sacred cow that people didn't
1434
01:22:33.880 --> 01:22:37.760
understand and they just started to say it without knowing
1435
01:22:37.840 --> 01:22:39.960
what they were saying or what it was supposed to mean.
1436
01:22:40.800 --> 01:22:43.680
And this don't repeat yourself became this you know this
1437
01:22:44.560 --> 01:22:52.079
this religious uh month fervor. And I think a good
1438
01:22:52.119 --> 01:22:55.600
metric would be what does the number of letters you
1439
01:22:55.760 --> 01:22:58.920
have to type to search for it or or or
1440
01:22:59.079 --> 01:23:02.520
query for it exceed the number of characters you would
1441
01:23:02.560 --> 01:23:05.359
have to type in order to implement it. Because if so,
1442
01:23:06.399 --> 01:23:08.600
you're on the wrong track. You should just copy and
1443
01:23:08.680 --> 01:23:10.560
paste that code or type it out again.
1444
01:23:11.159 --> 01:23:16.159
It'll be interesting to see if AI code generators make
1445
01:23:16.199 --> 01:23:19.319
a dent in this if people can instead of pulling,
1446
01:23:19.399 --> 01:23:23.720
and if they actually make an improvement. Also, if somebody,
1447
01:23:23.840 --> 01:23:27.720
instead of pulling in a module that does something, can
1448
01:23:27.880 --> 01:23:32.319
stell like chat, GPT or copilot or whatever, right me
1449
01:23:32.479 --> 01:23:35.079
code that does that thing and then copy pastes it
1450
01:23:36.039 --> 01:23:38.439
into their code, is that better or worse?
1451
01:23:40.039 --> 01:23:43.600
I have had great success with chat GPT, writing far
1452
01:23:43.800 --> 01:23:47.119
better code than what exists in the ecosystem that I
1453
01:23:47.159 --> 01:23:49.479
could find. And I'm not just looking at modules that
1454
01:23:49.600 --> 01:23:52.359
have the fifteen hundred plus stars. I'll look for things
1455
01:23:52.439 --> 01:23:55.560
that have ten or no stars. I'm just looking for
1456
01:23:55.640 --> 01:23:57.560
the best code that's available, and I'll go peek at
1457
01:23:57.560 --> 01:24:00.720
the source code. Two things that come to mind. One
1458
01:24:01.039 --> 01:24:05.000
was Shot two fifty six, because web crypto has Shot
1459
01:24:05.079 --> 01:24:08.000
two fifty six, but it's really really slow because of
1460
01:24:08.039 --> 01:24:11.439
the context switches and the async. So if you need
1461
01:24:11.520 --> 01:24:14.000
Shot two fifty six for anything more than a one off,
1462
01:24:14.399 --> 01:24:17.079
I would not recommend using web Crypto. So all these
1463
01:24:17.159 --> 01:24:20.079
modules on NPM that have Shot two fifty six, they're
1464
01:24:20.119 --> 01:24:22.680
all really legacy there. You know, some of them are
1465
01:24:22.800 --> 01:24:26.560
using a transpiled buffer implementation from node like. None of
1466
01:24:26.600 --> 01:24:30.840
them are using unaight array and modern JavaScript. They're all
1467
01:24:30.960 --> 01:24:34.720
like decrepitly old. And I asked GPT to write me
1468
01:24:34.960 --> 01:24:38.560
from scratch a shot two fifty six, and I was
1469
01:24:38.720 --> 01:24:41.720
so skeptical. I spent two hours testing it, pulling from
1470
01:24:41.800 --> 01:24:44.880
other libraries, like grabbing their tests and bringing that in
1471
01:24:45.199 --> 01:24:47.600
because I thought there's no way it that it created
1472
01:24:47.640 --> 01:24:51.319
a better library than anything that exists on NPM in
1473
01:24:51.680 --> 01:24:54.680
a one shot. But it is a really well known algorithm.
1474
01:24:54.720 --> 01:24:57.279
There's lots of training data and lots of languages, and
1475
01:24:57.479 --> 01:25:00.439
GPT does kind of tend towards simplicity. It doesn't have
1476
01:25:00.520 --> 01:25:03.840
a context window to be able to create seven different
1477
01:25:03.880 --> 01:25:06.640
class hierarchies. To do something, it kind of has to
1478
01:25:06.720 --> 01:25:08.359
be able to do it in a function or two,
1479
01:25:08.800 --> 01:25:11.880
which I think you know also speaks to the greater
1480
01:25:12.039 --> 01:25:15.880
average of the human consciousness. Humans are not really good
1481
01:25:15.920 --> 01:25:20.039
at holding seven different class hierarchies in their context windows,
1482
01:25:20.079 --> 01:25:22.079
although they like to think that they do. But in
1483
01:25:22.199 --> 01:25:26.079
some ways I think that GPT is more truthfully reflecting
1484
01:25:26.159 --> 01:25:30.439
reality than people are perceiving it. Another instance was a
1485
01:25:30.520 --> 01:25:33.880
seaboar parser, and you know, seaboar is something there's not
1486
01:25:34.199 --> 01:25:39.199
very many implementations of it. But the implementations that exist
1487
01:25:40.119 --> 01:25:43.439
outside of JavaScript are extremely high quality, and so it
1488
01:25:43.600 --> 01:25:46.479
was able to write me a seaboard partser in a
1489
01:25:46.560 --> 01:25:49.119
one shot. Other than I had to make a follow
1490
01:25:49.239 --> 01:25:52.199
up prompt because there was one function that didn't fit
1491
01:25:52.279 --> 01:25:54.680
in it. I guess didn't fit in its context window.
1492
01:25:54.960 --> 01:25:56.680
So I had this. I could tell that it didn't
1493
01:25:56.720 --> 01:25:59.399
have one of the functions was missing, and so I said, hey,
1494
01:25:59.520 --> 01:26:01.800
you're missing this, and I took that and it worked.
1495
01:26:02.399 --> 01:26:07.199
And so it's at least in JavaScript, I can tell that.
1496
01:26:07.359 --> 01:26:08.720
And and part of it has to do with my
1497
01:26:08.880 --> 01:26:11.960
memories because in GPT, I've told it, hey, remember that
1498
01:26:12.119 --> 01:26:15.039
I prefer this style. Remember that I prefer this style.
1499
01:26:15.119 --> 01:26:18.840
So I have also prompted it to be simpler in
1500
01:26:18.920 --> 01:26:20.880
the way that it writes code. But it was able
1501
01:26:20.920 --> 01:26:25.560
to one shot two complex things that you know, certainly
1502
01:26:25.600 --> 01:26:28.680
nobody could write in thirty seconds, and very few people
1503
01:26:28.720 --> 01:26:31.319
could write and feel confident that they wrote it correctly.
1504
01:26:32.199 --> 01:26:33.920
And you know, I was able to test it and
1505
01:26:34.000 --> 01:26:36.600
see that it did work. So but I think it
1506
01:26:36.720 --> 01:26:39.479
takes the senior mindset to do that in the first place,
1507
01:26:39.520 --> 01:26:42.000
because you have to be looking for Hey, I looked
1508
01:26:42.000 --> 01:26:44.520
at the code of this shot twoty six implementation on NPM,
1509
01:26:44.760 --> 01:26:48.079
and it's absolute garbage. Not necessarily because it was always garbage,
1510
01:26:48.760 --> 01:26:52.760
but sometimes just because like it's got browser of fied transportations,
1511
01:26:52.760 --> 01:26:56.520
which hey, back in you know, two thousand and ten,
1512
01:26:56.680 --> 01:26:59.439
that's that that was what you had to do.
1513
01:26:59.720 --> 01:27:02.399
That was I don't think it's the senior mindset. I'm
1514
01:27:02.439 --> 01:27:06.000
looking at my kids and you know, they're getting into
1515
01:27:06.119 --> 01:27:10.560
dev and they make significant use of those AI tools.
1516
01:27:11.079 --> 01:27:14.600
So I definitely think that there's a possibility that AI
1517
01:27:14.800 --> 01:27:18.760
tools may reduce the amount of packages that we import
1518
01:27:18.960 --> 01:27:22.600
because they they'll write those one shot type codes for
1519
01:27:22.760 --> 01:27:26.880
us that we often need instead of you know important.
1520
01:27:27.720 --> 01:27:32.319
And then what will happen is that a box will
1521
01:27:32.319 --> 01:27:33.199
spread everywhere.
1522
01:27:35.039 --> 01:27:36.520
Yeah, that's the thing is That's why I said it
1523
01:27:36.560 --> 01:27:38.600
takes the senior mindset because you have to know to
1524
01:27:38.680 --> 01:27:40.359
test it, you have to know to determine if it's
1525
01:27:40.399 --> 01:27:43.399
slop or if it's real. Because depending on the day,
1526
01:27:43.479 --> 01:27:45.439
you know, when they update to a new model or
1527
01:27:45.680 --> 01:27:48.119
you know, do the revisions. I'll have a day where
1528
01:27:48.119 --> 01:27:51.960
I'm coding with GPT four. Oh, and you know it's
1529
01:27:52.039 --> 01:27:54.640
just like banger after banger and I'm like wow, And
1530
01:27:54.760 --> 01:27:57.399
then a day or two later, I'll be asking you
1531
01:27:57.520 --> 01:28:01.000
questions that might even be simpler or whatever, and it'll
1532
01:28:01.039 --> 01:28:03.000
turn out just absolute crap, and it's like, Okay, I
1533
01:28:03.039 --> 01:28:04.000
got to write this myself.
1534
01:28:05.359 --> 01:28:10.560
I think that another aspect of the reuse is that,
1535
01:28:11.079 --> 01:28:13.319
like if you're your own person, like if I'm just
1536
01:28:13.359 --> 01:28:15.960
writing code for myself, I don't mind writing some new
1537
01:28:16.039 --> 01:28:18.840
stuff and using that because like I'm the one who's
1538
01:28:18.840 --> 01:28:20.680
going to have to maintain. If you're working in a company,
1539
01:28:21.680 --> 01:28:24.039
I don't really you know, if I ran a large company,
1540
01:28:24.079 --> 01:28:27.439
I wouldn't want a hundred copies of the same thing
1541
01:28:27.640 --> 01:28:31.279
written by ten different people, even if they're using AI
1542
01:28:31.399 --> 01:28:33.760
to do it more quickly, because there's going to be
1543
01:28:33.800 --> 01:28:36.199
different bugs, there's going to be more investigation. So part
1544
01:28:36.279 --> 01:28:39.560
of the sort of the reuse is being intentional about
1545
01:28:39.560 --> 01:28:43.119
what you reuse and when you do reuse things. Like
1546
01:28:43.479 --> 01:28:45.600
the great thing in the JAVASCRPT ecosystem is we have
1547
01:28:45.680 --> 01:28:49.000
tons of choice. The challenges that we have tons of choice,
1548
01:28:49.039 --> 01:28:51.520
So at least like within an organization, you should try
1549
01:28:51.560 --> 01:28:54.680
and rein in that choice a little bit and say, well, okay,
1550
01:28:54.760 --> 01:28:58.760
we're going to use one version of X, Like, let's
1551
01:28:58.800 --> 01:29:01.279
not pick ten different ones because now we've just increased
1552
01:29:01.319 --> 01:29:03.640
our surface area in our risks by ten times. We're
1553
01:29:03.640 --> 01:29:06.399
going to pick one. We're going to reuse it. And
1554
01:29:06.760 --> 01:29:10.199
you know that's one way of continuing to maximize the
1555
01:29:10.279 --> 01:29:13.399
value you get to reuse. But you know, being intentional
1556
01:29:13.439 --> 01:29:15.880
about the dependencies you have in your application and as
1557
01:29:15.880 --> 01:29:19.319
an organization, managing the risk so that you get a
1558
01:29:19.359 --> 01:29:22.840
good balance between benefits to reuse versus the code thought
1559
01:29:22.960 --> 01:29:23.560
in your code.
1560
01:29:24.439 --> 01:29:25.640
If we bring it, if we bring it back to
1561
01:29:25.680 --> 01:29:27.399
the pillars, you know, if you look at every single
1562
01:29:27.439 --> 01:29:30.359
one of those pillars a key ingredient, and every single
1563
01:29:30.399 --> 01:29:34.079
one of those is intentionality, right, it's you know, get
1564
01:29:34.159 --> 01:29:37.159
you to stop and think about your code in some
1565
01:29:37.359 --> 01:29:39.680
aspect of it. You know, what are you testing? What
1566
01:29:39.960 --> 01:29:40.960
dependencies are you using?
1567
01:29:41.239 --> 01:29:41.399
Right?
1568
01:29:41.720 --> 01:29:44.199
How are your tasks broken down? Right?
1569
01:29:44.439 --> 01:29:45.600
All of it is just.
1570
01:29:45.880 --> 01:29:50.439
About this, this notion of being very very intentional about
1571
01:29:50.520 --> 01:29:54.439
what you're doing with your application. Dependencies are no different.
1572
01:29:54.640 --> 01:29:57.640
Don't just pick a dependency because it exists. Pick a
1573
01:29:57.720 --> 01:29:59.880
dependency because it does what you need it to do
1574
01:30:00.239 --> 01:30:03.760
the way you need it to do it right. And
1575
01:30:04.279 --> 01:30:08.520
you know, and understand what it's doing. And it doesn't
1576
01:30:08.520 --> 01:30:10.960
matter if you're having AI write your code. It's the
1577
01:30:11.039 --> 01:30:13.800
same thing, right, you have to be very intensible about it,
1578
01:30:14.359 --> 01:30:16.520
about what you're trying to accomplish.
1579
01:30:17.000 --> 01:30:19.159
Guys, I need to do.
1580
01:30:19.279 --> 01:30:19.479
Yeah.
1581
01:30:19.600 --> 01:30:22.479
Unfortunately, it's about time for me. So I just want
1582
01:30:22.560 --> 01:30:25.239
to say thank you very much for Johnning. I Fortunately
1583
01:30:25.239 --> 01:30:27.279
I would stay longer, but at this point I really
1584
01:30:27.319 --> 01:30:27.840
need to drop.
1585
01:30:28.520 --> 01:30:31.000
Okay, thank you very much for coming on. Will you
1586
01:30:31.079 --> 01:30:32.560
are going to be a guest on our show to
1587
01:30:32.640 --> 01:30:34.960
talk about something else in any event, pretty soon, so
1588
01:30:35.079 --> 01:30:37.359
we'll see you then. So thank you, thank you very
1589
01:30:37.439 --> 01:30:40.000
much for coming on today. And I'm going to push
1590
01:30:40.119 --> 01:30:42.760
us the rest of us into picks anyway. We will
1591
01:30:42.920 --> 01:30:46.600
just have to invite you over to talk more about
1592
01:30:46.600 --> 01:30:49.600
the pillars, because we literally made it halfway. We made
1593
01:30:49.640 --> 01:30:52.720
it into the middle of pillar number five, so now
1594
01:30:52.800 --> 01:30:55.039
we have the rest of pillar number five and then
1595
01:30:55.399 --> 01:30:58.119
six through nine, and this is such a great conversation.
1596
01:30:58.439 --> 01:31:02.239
I'm so happy that it's turning out this way. So
1597
01:31:02.439 --> 01:31:06.119
thank you, Matteo and uh and see you in a bit,
1598
01:31:06.439 --> 01:31:08.760
in like a few more in a few weeks.
1599
01:31:09.399 --> 01:31:10.600
Bye bye bye bye.
1600
01:31:12.039 --> 01:31:17.960
Bye, and you guys, so again I'm going to push
1601
01:31:18.039 --> 01:31:19.159
us to pigs a J.
1602
01:31:19.359 --> 01:31:23.000
Do you want to go first, Sure, I've got a couple.
1603
01:31:23.439 --> 01:31:26.279
So I'll go ahead and throw out my link to
1604
01:31:26.479 --> 01:31:29.840
this show two six implementation. If you have an application
1605
01:31:30.119 --> 01:31:35.079
where you need to be doing multiple shaws in a row, this,
1606
01:31:35.640 --> 01:31:40.960
this is the best implementation that exists in javascripts. At
1607
01:31:41.079 --> 01:31:44.960
least there might be one that's just as good, but
1608
01:31:45.079 --> 01:31:47.079
I was not able to find it. So I had
1609
01:31:47.119 --> 01:31:52.840
to publish this this and and it has been tested extensively,
1610
01:31:53.000 --> 01:31:58.520
so I am very you know I I dollars are
1611
01:31:58.600 --> 01:32:02.960
on the line with it. But anyway, so I'll I'll
1612
01:32:03.039 --> 01:32:05.960
do that just as a self promo since I since
1613
01:32:06.000 --> 01:32:09.720
I talked about it, because yeah, if web crypto works
1614
01:32:09.720 --> 01:32:11.720
because you only need to do one or two, that's great.
1615
01:32:12.479 --> 01:32:14.640
But the other the legacy modules that are out there,
1616
01:32:14.680 --> 01:32:16.960
I just I would not recommend them because they're they're
1617
01:32:17.119 --> 01:32:20.680
doing all this weird Browser five stuff or like yeah,
1618
01:32:20.800 --> 01:32:23.479
so they're just they're old, they're old, they're dated, they
1619
01:32:23.560 --> 01:32:28.119
need to be replaced. And uh yeah, so go put
1620
01:32:28.159 --> 01:32:30.039
the first star on there if you want to. And
1621
01:32:30.159 --> 01:32:32.880
then I another thing I'm gonna pick. We're heading into
1622
01:32:33.039 --> 01:32:37.199
winter so we're we're in this season right here where
1623
01:32:37.239 --> 01:32:42.880
I am of nearly perfect temperature, which the weather's been
1624
01:32:42.920 --> 01:32:45.520
really odd this year and the cycle of it's been
1625
01:32:45.640 --> 01:32:48.199
kind of strange, but the last week or two has
1626
01:32:48.239 --> 01:32:51.800
been pretty perfect temperature. We're heading into the thirties this week,
1627
01:32:51.960 --> 01:32:57.000
so it's in below freezing even so that's that as
1628
01:32:57.079 --> 01:32:59.560
soon as it came, it's over. That's that's how Utah is.
1629
01:32:59.680 --> 01:33:02.640
It's like your spring and your fall are very very
1630
01:33:02.800 --> 01:33:05.680
narrow bands. Like even two weeks ago it was up
1631
01:33:05.720 --> 01:33:08.199
in the eighties. This week it's down in the thirties.
1632
01:33:08.319 --> 01:33:11.439
So that's how it goes. But with it becoming winter,
1633
01:33:12.880 --> 01:33:16.600
static shock is a thing, at least for us here
1634
01:33:16.680 --> 01:33:20.520
in this dry climate. And a buddy of mine introduced
1635
01:33:20.560 --> 01:33:24.359
me to these grounding mats, and they sell them as
1636
01:33:24.560 --> 01:33:28.239
kind of woo woo hocus pocus, like it's gonna alleviate
1637
01:33:28.399 --> 01:33:32.479
your back playing pain problems while you sleep or carry
1638
01:33:32.479 --> 01:33:35.520
your depression, which I don't believe that the grounding mat
1639
01:33:35.640 --> 01:33:37.720
is gonna do any of that. If you do believe that,
1640
01:33:38.640 --> 01:33:44.079
i'd be curious to know why. But and honestly, I
1641
01:33:44.119 --> 01:33:45.840
actually would be curious to know if there's is there
1642
01:33:45.920 --> 01:33:47.520
some sort of science behind it or some sort of
1643
01:33:48.039 --> 01:33:53.079
uh like actual uh what lived experiences or whatever, But
1644
01:33:53.600 --> 01:33:55.720
but I get I got them, and I've got one
1645
01:33:55.760 --> 01:33:59.279
for my feet and one for my hands, just because
1646
01:33:59.359 --> 01:34:02.640
I start to develop this fear of like touching the keyboard,
1647
01:34:02.640 --> 01:34:04.399
because every time I did, I mean, it was a
1648
01:34:04.479 --> 01:34:07.039
heavy shock. It wasn't just like a little like, oh,
1649
01:34:07.319 --> 01:34:10.319
you know, I touched your sweater. It would really build up.
1650
01:34:10.479 --> 01:34:13.279
And so I got these grounding mats so that I
1651
01:34:13.960 --> 01:34:18.920
don't shock things. Also, real story about electric shock. I
1652
01:34:19.000 --> 01:34:25.039
took my home network down for two days, and I
1653
01:34:25.119 --> 01:34:27.439
kept on unplugging things and replugging them, and then it
1654
01:34:27.479 --> 01:34:29.359
would work for another hour and it would go down again.
1655
01:34:30.359 --> 01:34:34.239
It turned out there was a network switch that was
1656
01:34:34.479 --> 01:34:37.560
connected to my desk, and I believe that what had
1657
01:34:37.640 --> 01:34:41.359
happened was that I had inadvertently touched that one of
1658
01:34:41.439 --> 01:34:43.880
the cables that went to the network switch. It had
1659
01:34:43.920 --> 01:34:46.680
gotten into a bad state where it was just spitting
1660
01:34:46.720 --> 01:34:50.600
out some sort of packet. I honestly believe it was
1661
01:34:50.640 --> 01:34:54.319
from static shock, because I had unplugged a bunch of
1662
01:34:54.399 --> 01:34:56.600
other things, but I'd missed that one switch. And when
1663
01:34:56.640 --> 01:35:00.000
I finally found that, oh, I haven't actually power site
1664
01:35:00.239 --> 01:35:01.760
this thing like I thought I had. I think I
1665
01:35:01.840 --> 01:35:03.920
had power cycled it, but it had a USB connection
1666
01:35:04.079 --> 01:35:07.840
so it would still had power from the USB or
1667
01:35:07.920 --> 01:35:11.199
something like that. But anyway, I unplugged it, replugged it,
1668
01:35:11.439 --> 01:35:13.760
and then I didn't have those network problems anymore. Very
1669
01:35:13.920 --> 01:35:18.159
very weird situation, but I think just getting shocked flipped
1670
01:35:18.159 --> 01:35:22.399
a bit. So it also could potentially protect your electronics
1671
01:35:22.880 --> 01:35:27.319
from malfunction having one of these grounding pads. So I
1672
01:35:27.439 --> 01:35:30.640
linked to one that it actually feels nice.
1673
01:35:30.680 --> 01:35:31.079
It doesn't.
1674
01:35:31.399 --> 01:35:35.359
It doesn't feel cheap and junkie. It has a it
1675
01:35:35.479 --> 01:35:37.520
feels like real leather. I don't know if it is,
1676
01:35:37.600 --> 01:35:40.279
but it it feels like real leather. And it's very
1677
01:35:40.399 --> 01:35:44.640
very effective in terms of if I'm using it, I'm
1678
01:35:44.680 --> 01:35:47.840
not constantly shocking everything on my desk. If I'm not
1679
01:35:48.079 --> 01:35:50.680
using it, or like walk away on the other side
1680
01:35:50.680 --> 01:35:52.000
of the room and come back, then you know, I
1681
01:35:52.079 --> 01:35:54.760
put my hand down, and of course I shocked myself anyway,
1682
01:35:55.159 --> 01:35:57.720
grounding mats who knew? Who knew? That could be a pick,
1683
01:35:57.840 --> 01:36:01.640
but it is. And that's what I got for you
1684
01:36:01.680 --> 01:36:02.079
all today.
1685
01:36:03.920 --> 01:36:07.079
Excellent. So now I'll go with my picks. I actually
1686
01:36:07.199 --> 01:36:09.920
have two picks. So my first pick is we watched
1687
01:36:10.159 --> 01:36:15.800
on Netflix the limited series called Monsters. The Lyle and
1688
01:36:16.079 --> 01:36:19.640
Eric Menandez Story. This is a pretty famous and pretty
1689
01:36:19.720 --> 01:36:24.439
gruesome story from the end of the eighties. I think
1690
01:36:24.479 --> 01:36:27.439
it happened. The actual event happened in nineteen eighty one
1691
01:36:28.199 --> 01:36:32.520
about these two brothers that basically executed their parents and
1692
01:36:33.279 --> 01:36:35.600
they were caught. They went on, they went to a trial.
1693
01:36:35.640 --> 01:36:39.439
I won't spoil the rest of the story. There's actually
1694
01:36:39.600 --> 01:36:41.640
three ways. The funny thing is that there are actually
1695
01:36:41.760 --> 01:36:47.560
three ways to watch it on Netflix. There's the limited series,
1696
01:36:47.640 --> 01:36:54.039
which is a dramatization of the story, There's a documentary series,
1697
01:36:54.199 --> 01:36:59.159
and then there's a documentary movie. We watched the series
1698
01:36:59.520 --> 01:37:02.079
and in enjoyed it very much, and that's the thing
1699
01:37:02.159 --> 01:37:05.760
that I would recommend the most. It's well played, well written,
1700
01:37:07.079 --> 01:37:12.239
it's it's just it's just good, pretty good television. Afterwards,
1701
01:37:12.640 --> 01:37:16.279
we try to watch a documentary series because we were
1702
01:37:16.359 --> 01:37:19.119
kind of interested in the story, but it, I don't know,
1703
01:37:19.239 --> 01:37:21.600
it just went into way too many details for us.
1704
01:37:22.039 --> 01:37:25.520
So instead we watched the documentary movie, which was interesting
1705
01:37:25.600 --> 01:37:28.840
in the context of the series we just watched. But again,
1706
01:37:29.239 --> 01:37:32.840
if you're gonna watch something and just the one thing,
1707
01:37:33.439 --> 01:37:38.560
do just watch the limited series again. It's called Monsters
1708
01:37:38.640 --> 01:37:42.239
the Lylon Eric Menedde's story, and it's it's it's a
1709
01:37:42.279 --> 01:37:45.520
pretty good story. The one thing interesting about it is
1710
01:37:45.600 --> 01:37:49.359
that recently, I think the governor California, I believe, said
1711
01:37:49.399 --> 01:37:54.720
that he's reviewing their sentences because and people are saying
1712
01:37:54.760 --> 01:37:57.359
that it's potentially because of the stories that came out
1713
01:37:57.439 --> 01:37:59.800
due to these all these shows and all the the
1714
01:38:00.079 --> 01:38:03.279
ussion about them, which is kind of interesting how art
1715
01:38:03.439 --> 01:38:07.479
impacts life, I guess in a sense anyway, So that's
1716
01:38:07.560 --> 01:38:12.800
my first pick. My second pick is things have been
1717
01:38:13.119 --> 01:38:15.520
it's kind of people have stopped talking about it, maybe
1718
01:38:15.600 --> 01:38:18.319
because of the elections in the US or maybe people
1719
01:38:18.479 --> 01:38:20.760
just moved on. But there was a whole lot of
1720
01:38:20.880 --> 01:38:26.760
craziness around WordPress, like it kind of seemed like the
1721
01:38:26.880 --> 01:38:32.239
guy who's running automatic who is like the what's it called,
1722
01:38:32.439 --> 01:38:36.800
what's it called the Benevolent Dictator of WordPress, which is
1723
01:38:37.159 --> 01:38:41.319
Matt Mullenweg I think his name is pronounced seemly kind
1724
01:38:41.359 --> 01:38:43.680
of went off the rails. I won't go into the
1725
01:38:43.880 --> 01:38:48.000
entire story. It's pretty out there. A lot of crazy
1726
01:38:48.079 --> 01:38:52.239
things happened, and if you are curious about what actually
1727
01:38:52.359 --> 01:38:57.279
went down in what's potentially still going on, the one
1728
01:38:57.640 --> 01:39:00.680
video that I would recommend to learn everything about it,
1729
01:39:01.319 --> 01:39:05.800
at least everything as was as of about two weeks ago,
1730
01:39:06.600 --> 01:39:11.039
is a video made by THEO also known as THEO
1731
01:39:11.159 --> 01:39:16.479
three GG. It's actually in his throwaways channel. We'll post
1732
01:39:16.520 --> 01:39:21.720
a link. He actually spoke with Dan Sottman, another podcaster
1733
01:39:21.960 --> 01:39:27.600
streamer a bit less technical and explained to him the
1734
01:39:27.680 --> 01:39:30.319
whole thing. And THEO was kind of involved in it
1735
01:39:30.760 --> 01:39:35.239
because he actually spoke and interviewed Matt In to the
1736
01:39:35.359 --> 01:39:40.319
extent that his videos became part of the depositions in
1737
01:39:40.479 --> 01:39:45.359
the ongoing lawsuit that's related to this whole story. So again,
1738
01:39:45.439 --> 01:39:49.000
if you're interested in this craziness and wackiness in the
1739
01:39:49.119 --> 01:39:53.640
open source world and where open source can go in
1740
01:39:54.039 --> 01:39:58.399
bad situations, then it's a pretty interesting video to watch
1741
01:39:58.479 --> 01:40:02.560
and I recommend. So these are my two picks for today,
1742
01:40:02.920 --> 01:40:05.239
and i'll and i'll post a link to the links
1743
01:40:05.279 --> 01:40:09.359
to both of them. How about you, James, do you
1744
01:40:09.439 --> 01:40:10.399
have any picks for us?
1745
01:40:13.039 --> 01:40:15.439
Let's see. Well, first of all, I'm sorry if I
1746
01:40:15.520 --> 01:40:17.640
get any audio. My earbuds just died, so I'm on
1747
01:40:17.840 --> 01:40:19.000
laptop speakers now.
1748
01:40:18.960 --> 01:40:20.439
So there might be some echo.
1749
01:40:20.600 --> 01:40:25.279
I'm apologize for that. Let's see picks for for today.
1750
01:40:26.279 --> 01:40:31.439
Next week, we've got note comf EU happening in Iowa. Uh,
1751
01:40:32.119 --> 01:40:35.600
it's always my favorite time of year, getting back, getting
1752
01:40:35.680 --> 01:40:39.760
back to Ireland. We're actually returning to Waterford Castle. It's
1753
01:40:40.520 --> 01:40:45.479
the conference is an actual castle, you know, it's just
1754
01:40:45.560 --> 01:40:50.640
an absolutely wonderful, fantastic venue. There's still some tickets available,
1755
01:40:51.439 --> 01:40:52.960
you know. I know, folks from the US, it's maybe
1756
01:40:52.960 --> 01:40:55.319
a little a little harder to get over there that
1757
01:40:55.640 --> 01:40:57.119
you know, last minute, but if you're over there in
1758
01:40:57.159 --> 01:41:00.520
Europe and you have the time available, it's absolutely fantastic conference.
1759
01:41:01.319 --> 01:41:07.159
I'm gonna be talking about, uh, cross run time compatibility.
1760
01:41:07.479 --> 01:41:10.439
So all this effort, like Dino to act like note
1761
01:41:10.600 --> 01:41:13.000
bun working BacT like note workers is trying to act
1762
01:41:13.079 --> 01:41:15.600
like note how do we ensure that the all these
1763
01:41:15.640 --> 01:41:17.760
different run times work the same when it comes to like,
1764
01:41:17.880 --> 01:41:19.760
you know, standard web APIs that kind of thing. So
1765
01:41:19.800 --> 01:41:21.439
I'm gonna be talking through a lot of the challenges
1766
01:41:21.560 --> 01:41:26.680
that that all these different run times have to actually
1767
01:41:26.760 --> 01:41:30.199
make sure that they're compatible with the language like JavaScript
1768
01:41:30.239 --> 01:41:33.159
that allows you to basically do whatever you want. So
1769
01:41:33.239 --> 01:41:35.079
that'll be that'll be a fun talk. But the other
1770
01:41:35.239 --> 01:41:38.760
other side of it, and this is just my personal side,
1771
01:41:38.920 --> 01:41:41.560
my son is going. My son has been a contributor
1772
01:41:41.600 --> 01:41:43.199
to Note for a couple of years. He's doing his
1773
01:41:43.279 --> 01:41:47.159
own talk there with with with another person, Claudio. We're
1774
01:41:47.199 --> 01:41:48.680
gonna be talking about the work that they've been doing
1775
01:41:48.760 --> 01:41:54.640
to improve node uh release downloads based on cloud flare
1776
01:41:54.800 --> 01:41:56.960
R two and some of the other some of the
1777
01:41:57.039 --> 01:41:58.800
other work that they've been they've been working on. So
1778
01:42:00.239 --> 01:42:04.159
if you have time, go, we'd love to meet folks there.
1779
01:42:04.359 --> 01:42:11.680
And that's the family that nodes together, stays together. Cool
1780
01:42:11.760 --> 01:42:13.159
And how about you, Michael.
1781
01:42:13.800 --> 01:42:16.359
H Yeah, I'll my first one. I'll just agree with
1782
01:42:16.479 --> 01:42:19.279
James not you. Next week is going to be fantastic.
1783
01:42:20.039 --> 01:42:22.359
The other thing I've been doing lately is spending time,
1784
01:42:22.479 --> 01:42:24.840
like learning a little bit more about AI, trying to
1785
01:42:25.039 --> 01:42:29.199
use the libraries from JavaScript. And the great thing is
1786
01:42:29.279 --> 01:42:32.840
often like JavaScript or Typescript is the second language supported.
1787
01:42:32.920 --> 01:42:35.720
So if you look at a Lama Lamadex lang chain,
1788
01:42:35.760 --> 01:42:39.520
which we're all leading libraries in the AI space, they
1789
01:42:39.600 --> 01:42:42.439
obviously all start with Python, because really data science came
1790
01:42:42.479 --> 01:42:44.079
out of that that sort of space, and that's the
1791
01:42:44.159 --> 01:42:47.359
language I use. But most of the leading libraries also
1792
01:42:47.439 --> 01:42:50.000
then support Typescript is their second language, and I think
1793
01:42:50.039 --> 01:42:54.319
that shows a recognition of the AI ecosystem that like
1794
01:42:54.479 --> 01:42:57.279
JavaScript and typescript is going to be an important player
1795
01:42:57.359 --> 01:43:00.399
in terms of consuming those services. In terms of my
1796
01:43:00.520 --> 01:43:03.399
pick I've been looking at this week, it's the b
1797
01:43:03.520 --> 01:43:06.840
agent framework. It's actually one which started life as a
1798
01:43:06.880 --> 01:43:09.439
typescript instead of Python, which is nice to see as
1799
01:43:09.479 --> 01:43:12.680
a node developer that somebody started with a JavaScript implementation.
1800
01:43:13.520 --> 01:43:16.760
It lets you write agents that call functions more easily.
1801
01:43:16.800 --> 01:43:19.359
So I've been playing around with that, and if you're
1802
01:43:19.399 --> 01:43:24.000
interested in you know, Node and consuming AI from JavaScript typeescript,
1803
01:43:24.359 --> 01:43:26.359
I throw that over as my pick to go take
1804
01:43:26.399 --> 01:43:26.840
a look at that.
1805
01:43:28.600 --> 01:43:31.119
Very cool. Now, before we wrap up, if people want
1806
01:43:31.199 --> 01:43:33.159
to get in touch with you guys, so talk about
1807
01:43:33.199 --> 01:43:35.359
what we talked about today. I don't know if you
1808
01:43:35.520 --> 01:43:39.000
still do consulting work or in general just to speak
1809
01:43:39.039 --> 01:43:41.600
with you. How do they get in touch Michael, what's
1810
01:43:41.640 --> 01:43:42.880
the best way to contact.
1811
01:43:42.760 --> 01:43:45.520
I think you know Twitter? My handle's there. MH tauson one.
1812
01:43:46.079 --> 01:43:47.399
You can just reach out to me through that.
1813
01:43:48.479 --> 01:43:50.359
Excellent. And how about you, James.
1814
01:43:50.720 --> 01:43:55.760
Same on Twitter. I'm Jay A. Snell on Twitter and
1815
01:43:55.920 --> 01:43:59.159
on GitHub. I think we have to be following each
1816
01:43:59.199 --> 01:44:02.479
other for you to d m DM, but you know,
1817
01:44:02.600 --> 01:44:04.720
apporporate to reach out to a public chat out on
1818
01:44:04.800 --> 01:44:06.119
me on their happy chat.
1819
01:44:07.199 --> 01:44:10.680
Excellent. So guys, it's it was great having you on
1820
01:44:11.119 --> 01:44:14.560
and I really hope we can organize and schedule the
1821
01:44:15.199 --> 01:44:18.159
follow up because we do really need to cover the
1822
01:44:18.279 --> 01:44:20.479
rest of the pillars. The ones that we did were
1823
01:44:20.520 --> 01:44:24.199
so great. Thank you for coming on, and to all
1824
01:44:24.279 --> 01:44:27.600
our listeners, thank you for listening in and goodbye.