S10 E8 | Architecting for Autonomy: Micro Frontends & Native Federation with Manfred Steyer

WEBVTT
1
00:00:08.519 --> 00:00:11.839
Welcome to the Angular plus Show. We're app developers of
2
00:00:11.919 --> 00:00:16.359
all kinds share their insights and experiences. Let's get started.
3
00:00:21.359 --> 00:00:24.239
Hello, and welcome back to another episode of the Angular
4
00:00:24.359 --> 00:00:27.359
Plus Show. I am one of your hosts today, Laura Newsome.
5
00:00:28.039 --> 00:00:30.960
I'm happy to be here. I have with me my
6
00:00:31.440 --> 00:00:34.880
one of my co hosts, Jay Jay. How's it going good?
7
00:00:35.200 --> 00:00:35.320
Uh?
8
00:00:35.799 --> 00:00:37.799
I forgot that we were doing this today, so hopefully
9
00:00:37.799 --> 00:00:38.960
I'm slightly prepared.
10
00:00:39.759 --> 00:00:42.880
You'll be totally prepared. There is nothing confusing about this topic.
11
00:00:43.159 --> 00:00:48.119
So about.
12
00:00:48.079 --> 00:00:49.719
And I was that with me Yan Yan, How's it
13
00:00:49.799 --> 00:00:51.200
going great?
14
00:00:51.520 --> 00:00:52.399
Fantastic?
15
00:00:52.920 --> 00:00:54.920
Jean really likes it if you ping him a whole
16
00:00:54.920 --> 00:00:57.960
bunch of times. So if you have a contact information
17
00:00:58.000 --> 00:01:00.000
for Yon, just make sure and just send him message
18
00:01:00.159 --> 00:01:01.320
just constantly.
19
00:01:01.240 --> 00:01:05.879
Like on all platforms in LinkedIn email, fat.
20
00:01:07.200 --> 00:01:09.000
Like if you can somehow like send a message to
21
00:01:09.040 --> 00:01:10.920
his kids to get his kids to be like.
22
00:01:13.079 --> 00:01:14.120
Join the podcast.
23
00:01:16.480 --> 00:01:18.879
Children's sound that's not creepy. Well.
24
00:01:18.920 --> 00:01:21.560
I am very delighted to have our guests on today.
25
00:01:22.400 --> 00:01:24.599
If you've spent any time in the ang Yelo community,
26
00:01:24.680 --> 00:01:27.359
I'm sure you know our guest. If you do not,
27
00:01:27.719 --> 00:01:31.200
I am excited to introduce Manfred Stier, How are you today, Manfred?
28
00:01:31.560 --> 00:01:33.200
I'm fine. Thanks for having me.
29
00:01:33.680 --> 00:01:36.599
Absolutely, you know, we wanted to do a top and
30
00:01:36.640 --> 00:01:38.480
the topic today in case any of you are wondering
31
00:01:38.519 --> 00:01:42.599
about this. Very clear, super straightforward topic is module federation
32
00:01:42.879 --> 00:01:44.079
and Native federation.
33
00:01:44.920 --> 00:01:46.599
So we're talking micro front ends.
34
00:01:46.879 --> 00:01:50.920
What's that talk about it than Manford exactly like we should.
35
00:01:52.599 --> 00:01:55.280
We should really ask Manfred to come on. So Manfred
36
00:01:55.640 --> 00:01:57.000
for the audience, do you want to go ahead and
37
00:01:57.000 --> 00:01:57.840
introduce yourself.
38
00:01:58.799 --> 00:02:03.480
Yeah, sure, I am Manfred Manfred Schtaya and I do
39
00:02:03.640 --> 00:02:09.000
trainings and consulting and reviews for angolar people, so I
40
00:02:09.039 --> 00:02:14.680
have companies doing Angola for the enterprise. And besides this,
41
00:02:14.879 --> 00:02:18.319
I'm speaking at a lot of conferences. I really enjoyed
42
00:02:18.439 --> 00:02:24.159
is sharing my knowledge and also writing block contiguis and
43
00:02:24.240 --> 00:02:24.479
so on.
44
00:02:25.360 --> 00:02:25.840
Excellent.
45
00:02:25.960 --> 00:02:29.199
Yeah, and I know you've been very helpful. I personally
46
00:02:29.319 --> 00:02:31.759
asked asked you questions that you've helped me out with.
47
00:02:32.800 --> 00:02:35.599
I know pretty much everyone in the community at this
48
00:02:35.639 --> 00:02:38.400
point has relied on the knowledge that you've shared with
49
00:02:38.439 --> 00:02:42.520
the community, and so it's very much appreciated. And on
50
00:02:42.560 --> 00:02:47.759
the topic of model federation, I use Native Federation every
51
00:02:47.840 --> 00:02:48.759
day at work.
52
00:02:48.919 --> 00:02:54.439
So oh, so I'm really glad to be here because
53
00:02:54.439 --> 00:02:55.199
we have questions.
54
00:02:58.800 --> 00:03:02.560
Yeah, it's not an easy topic, so it can be dampting,
55
00:03:02.759 --> 00:03:04.479
but it's it's not a free.
56
00:03:04.319 --> 00:03:05.719
Lunch, right right.
57
00:03:05.800 --> 00:03:11.000
So before we really dive into the topic, so model
58
00:03:11.039 --> 00:03:14.520
federation and native federation don't make any sense without the
59
00:03:14.560 --> 00:03:18.000
whole idea of microphone and architecture. So do you want
60
00:03:18.000 --> 00:03:20.759
to for the listeners who are not familiar with microphone ends,
61
00:03:20.919 --> 00:03:22.639
do you want to give a brief description of what
62
00:03:22.680 --> 00:03:23.520
that means?
63
00:03:24.159 --> 00:03:28.400
Yeah? Sure. So the idea is that somehow, if you
64
00:03:28.520 --> 00:03:32.759
have a huge system, we need to cut it into pieces.
65
00:03:32.800 --> 00:03:37.120
To slice it into pieces, and ideally we want to
66
00:03:37.159 --> 00:03:41.280
have pieces that don't know much about each other so
67
00:03:41.319 --> 00:03:44.919
that they can change something here without breaking something there.
68
00:03:45.680 --> 00:03:49.479
And if you have several teams, ideally each team would
69
00:03:49.520 --> 00:03:53.800
be responsible for just one slice or a tiny amount
70
00:03:53.840 --> 00:03:56.639
of slices so that they can do their own stuff
71
00:03:57.000 --> 00:04:00.039
and don't need to coordinate that much. So it's a
72
00:04:00.039 --> 00:04:04.400
lot about team autonomy. And you can achieve this in
73
00:04:04.520 --> 00:04:08.120
several ways, and each and every way has their own
74
00:04:08.199 --> 00:04:12.960
advantages and disadvantages. For instance, you can structure a huge
75
00:04:13.039 --> 00:04:19.560
application internally into modules or libraries or folders and access
76
00:04:19.680 --> 00:04:23.399
some nice possibilities to make sure that this source code
77
00:04:23.560 --> 00:04:27.279
cannot access that source code. But if you want to
78
00:04:27.319 --> 00:04:33.079
maximize the team autonomy, then you have several applications so
79
00:04:33.199 --> 00:04:39.759
called microfroundance, one application per bart per vertically slides, and
80
00:04:39.800 --> 00:04:43.680
then that challenges somehow. You need to bring everything together
81
00:04:44.199 --> 00:04:47.959
because the user wants to have one entire thing they
82
00:04:47.959 --> 00:04:51.399
can work with. That means we need to integrate those
83
00:04:51.439 --> 00:04:56.519
solutions that are separately developed and deployed at runtime. We
84
00:04:56.639 --> 00:04:59.920
need to do this at runtime because everything happens separate
85
00:05:00.800 --> 00:05:04.639
and those parts only meet at rundime for the first time.
86
00:05:05.160 --> 00:05:11.199
And yeah, for this microfront and technologies are attempting solution.
87
00:05:11.360 --> 00:05:16.079
And one of those technologies is module and or native federation.
88
00:05:17.160 --> 00:05:20.000
So what is the underlying difference between module Federation and
89
00:05:20.079 --> 00:05:20.839
native federation.
90
00:05:21.560 --> 00:05:26.279
Originally Module Federation came with web back five and for
91
00:05:26.360 --> 00:05:30.360
me it was really an eye opener because already in
92
00:05:30.399 --> 00:05:33.399
the better phase, I have seen this is solving so
93
00:05:33.639 --> 00:05:38.040
many issues all my customers have. Okay, not all of them,
94
00:05:38.120 --> 00:05:41.879
but a lot of them have, especially when they want
95
00:05:41.920 --> 00:05:47.319
to verticalize everything into separate applications. Basically, it allows us
96
00:05:47.319 --> 00:05:51.480
to load something from over there, from a different application
97
00:05:52.000 --> 00:05:56.240
that has not been known at compile time, and it
98
00:05:56.279 --> 00:05:59.480
can be done in a way that is more or
99
00:05:59.600 --> 00:06:04.399
less agnostic. Do your framework like Angola, So for Angola
100
00:06:04.519 --> 00:06:08.000
it looks like lazy loading, but underneath the covers, this
101
00:06:08.319 --> 00:06:13.399
module federation thing is scrapping over and taking something from
102
00:06:13.439 --> 00:06:18.079
a different application. And it also allows us to share dependencies.
103
00:06:18.519 --> 00:06:21.439
If we have the same version of Angola here and there,
104
00:06:21.879 --> 00:06:27.319
we can just share it. So this arrived with batback five. Meanwhile,
105
00:06:27.360 --> 00:06:30.879
we know that that back is not a big thing anymore.
106
00:06:31.319 --> 00:06:35.399
All the communities are moving to other bundlers because meanwhile
107
00:06:35.920 --> 00:06:39.920
we have better solutions. While bab back five years ago
108
00:06:40.279 --> 00:06:44.319
was the go tool solution for each and every community,
109
00:06:44.800 --> 00:06:50.879
meanwhile we have better solutions in terms of performance. And
110
00:06:51.040 --> 00:06:54.319
when I saw that also the Angler team is moving
111
00:06:54.439 --> 00:06:58.360
to other bundlers, I got a bit afraid because I
112
00:06:58.439 --> 00:07:02.439
saw on the one side, module federation in that back
113
00:07:02.600 --> 00:07:06.120
is exactly what we need, and on the other side,
114
00:07:06.160 --> 00:07:09.040
I was afraid that we cannot board it to each
115
00:07:09.160 --> 00:07:13.319
end every other bundler, especially because we need to be
116
00:07:13.720 --> 00:07:16.519
future proof in the long term. If we have such
117
00:07:16.560 --> 00:07:21.360
a huge system. Usually this system is developed for ten years,
118
00:07:21.439 --> 00:07:25.639
fifteen years, twenty years. We cannot foresee what will happen there,
119
00:07:26.000 --> 00:07:28.360
and soon we need to have a solution that works
120
00:07:28.399 --> 00:07:32.319
with everything, even with stuff we don't know today. And
121
00:07:32.360 --> 00:07:37.519
that's why I reimplemented the idea of module federation. Let's
122
00:07:37.519 --> 00:07:41.839
say the mandal model in a neutral way, in a
123
00:07:42.000 --> 00:07:46.800
technology agnostic way, that is just a wrapper around each
124
00:07:46.879 --> 00:07:51.160
and every possible bundler. In theory, you could wrap an
125
00:07:51.199 --> 00:07:54.160
ex copy command with it. Don't do it, but if
126
00:07:54.160 --> 00:07:56.759
you want to create your bundles with x copy, feel
127
00:07:56.800 --> 00:08:00.600
free and you can use native federation. In addition, and
128
00:08:00.759 --> 00:08:05.879
besides this, it's also using web standards like inboard maps
129
00:08:05.920 --> 00:08:10.199
and ekmask rep modules. And if we put this together,
130
00:08:10.480 --> 00:08:15.399
being not depended on a bundler and using web standards,
131
00:08:15.800 --> 00:08:19.480
then this is a solution that is very bodible and
132
00:08:19.959 --> 00:08:22.480
can help us in the long term. So what ability
133
00:08:22.959 --> 00:08:26.199
was the key here? And so nowadays we can use
134
00:08:26.279 --> 00:08:31.040
the Angler CLI with the new ees built based builder,
135
00:08:31.120 --> 00:08:35.600
the application builder, and we can stay closed to what
136
00:08:35.720 --> 00:08:39.679
the Angler community is doing and add this federation idea
137
00:08:39.720 --> 00:08:43.639
on the top. Because it's just a thin wrapper nice.
138
00:08:43.679 --> 00:08:47.519
Okay, so I I guess I thought Native Federation was
139
00:08:47.559 --> 00:08:51.240
meant to specifically work with es bill, but you're saying
140
00:08:51.440 --> 00:08:54.559
it's specifically meant with to work with whatever.
141
00:08:55.440 --> 00:08:59.879
Yeah, yeah, totally, But you have a good point. Our
142
00:09:00.480 --> 00:09:04.679
reference implementation and the implementation that comes out of the
143
00:09:04.799 --> 00:09:09.440
box is indeed yes, build based or application builder based,
144
00:09:09.519 --> 00:09:12.720
because this is what we need now in the angular space.
145
00:09:13.200 --> 00:09:18.279
But bodding it over to another bundler would be really straightforward.
146
00:09:18.480 --> 00:09:22.360
I think we need less than a week, perhaps one day,
147
00:09:22.440 --> 00:09:25.240
two days to board it do a different bundler.
148
00:09:25.759 --> 00:09:26.639
Nice. Nice.
149
00:09:26.720 --> 00:09:30.360
That actually makes me feel a little more relaxed. We
150
00:09:30.440 --> 00:09:32.960
use native federation when you have a question.
151
00:09:33.120 --> 00:09:37.240
With the bundler being agnostic or mostly agnostic, how does
152
00:09:37.240 --> 00:09:39.159
it look on the application side, because, like in the
153
00:09:39.240 --> 00:09:42.480
microphone and space, one common scenarios that you have, like
154
00:09:42.519 --> 00:09:45.360
an Anger application next to React application, for instance, how
155
00:09:45.399 --> 00:09:46.080
does that look?
156
00:09:47.279 --> 00:09:50.039
Yeah, we can do this. So if we really want
157
00:09:50.080 --> 00:09:53.840
to mix and match different frameworks, there are some good
158
00:09:53.879 --> 00:09:58.320
reasons and some not that good reasons we can achieve it.
159
00:09:59.399 --> 00:10:07.039
Because we can also wrap native Federation around a self
160
00:10:07.120 --> 00:10:11.159
written built script people might use in the rect space
161
00:10:11.799 --> 00:10:16.080
or have a wit integration, or if you use EARS
162
00:10:16.120 --> 00:10:19.639
builds directly in a build script, you can also include it.
163
00:10:19.639 --> 00:10:24.159
They are just at free commands and that's it. Of course,
164
00:10:24.240 --> 00:10:28.320
if you have several frameworks, then we somehow need to
165
00:10:28.399 --> 00:10:34.000
abstract the framework. Some people hides the framework behind a
166
00:10:34.039 --> 00:10:38.279
simple interface with a start and stop method. I like
167
00:10:38.399 --> 00:10:42.720
to use BAB components because also they can act as
168
00:10:42.759 --> 00:10:48.519
a wrapper of everything that's used technology viz underneath the covers.
169
00:10:49.480 --> 00:10:54.080
One of the questions I wanted to ask is, so
170
00:10:54.120 --> 00:10:58.759
how do you deal with upgrading Angular doing either Angular
171
00:10:58.840 --> 00:11:01.720
upgrades or Native Federation upgrades? Does that mean you have
172
00:11:01.799 --> 00:11:06.120
to update all the apps together or can I go separately?
173
00:11:07.320 --> 00:11:12.159
Yeah? So I really like to distinguish between this single
174
00:11:12.279 --> 00:11:17.120
version solution and the multi version solution. Both have different
175
00:11:17.279 --> 00:11:23.480
character characteristics, different advantages and disadvantages. If you manage to
176
00:11:23.840 --> 00:11:28.200
just stick with one Anglar version, then it's really straightforward.
177
00:11:28.559 --> 00:11:34.080
Then it really looks like lazy loading. But Angler loads
178
00:11:34.120 --> 00:11:36.799
something it did not know it to compile. Then, but
179
00:11:36.840 --> 00:11:42.120
then you just have one router and this makes everything simple. However,
180
00:11:42.480 --> 00:11:46.240
if you cannot control this, if you cannot make sure
181
00:11:46.559 --> 00:11:50.279
that all your different thems upgrade at the same moment.
182
00:11:50.840 --> 00:11:54.960
This can have several reasons, not only technically reasons but
183
00:11:55.200 --> 00:12:01.240
also organisatorically reasons and reasons that die in company culture.
184
00:12:01.919 --> 00:12:05.840
Then you need this multi version solution, and then you
185
00:12:05.919 --> 00:12:10.879
need a wrap around your framework, some kind of abstraction.
186
00:12:11.559 --> 00:12:15.720
Then you need to deal with different routers because different
187
00:12:15.840 --> 00:12:19.840
microf round thens can bring their own route, and this
188
00:12:20.159 --> 00:12:26.320
calls for some creative workarounds. It's completely doable, we have
189
00:12:26.440 --> 00:12:29.360
done it several times, but the road is a bit
190
00:12:29.399 --> 00:12:30.519
more rocky do What's this?
191
00:12:31.399 --> 00:12:36.039
So? With the single version solution, can you get into
192
00:12:36.120 --> 00:12:41.840
a situation where one application slice I guess if that's
193
00:12:41.879 --> 00:12:44.720
a good If one application slice, let's say like you
194
00:12:44.759 --> 00:12:46.639
have a monitory book for example, right, and we update
195
00:12:46.679 --> 00:12:49.679
the angler version to twenty point one one zero, right,
196
00:12:50.960 --> 00:12:53.600
and then we deploy like the two application slices and
197
00:12:53.639 --> 00:12:56.600
then the root application. Right, there's three. Can you end
198
00:12:56.679 --> 00:13:00.519
up in a situation where like the previous version of
199
00:13:00.559 --> 00:13:04.960
the root application loads a new version of one of
200
00:13:05.000 --> 00:13:08.279
the slices and then the angular version is then mismatched
201
00:13:08.279 --> 00:13:10.600
between the two of them. Or are there tools or
202
00:13:10.639 --> 00:13:14.360
processes that there are available to as such that like
203
00:13:14.759 --> 00:13:17.679
once we update the single version of angular across all
204
00:13:17.720 --> 00:13:20.320
of our slices. We're never mad up in a weird
205
00:13:20.519 --> 00:13:24.159
mismatch scenario. How does the like Because of course there's
206
00:13:24.240 --> 00:13:27.919
like CD and cashing and browser casing and chunk cashing,
207
00:13:27.960 --> 00:13:30.960
and like cashing is hard. So how do we prevent
208
00:13:31.759 --> 00:13:34.360
version mismatches in the single version policy?
209
00:13:35.080 --> 00:13:38.039
Yeah, so you're totally right. This can happen if you
210
00:13:38.279 --> 00:13:43.279
deploy different pieces of your mono repository at different times.
211
00:13:43.879 --> 00:13:47.200
Even though you have a single version policy, this just
212
00:13:47.320 --> 00:13:49.960
means you have a single version at one given time.
213
00:13:50.440 --> 00:13:53.720
So in this case, you could end up with a mismatch.
214
00:13:54.639 --> 00:13:57.519
What do we do in these cases? We like to
215
00:13:57.639 --> 00:14:02.120
use an X and an X candella which applications have
216
00:14:02.200 --> 00:14:06.279
been affected by recent changes, and then we need to
217
00:14:06.399 --> 00:14:11.120
deploy all of them together, all the effect that applications together,
218
00:14:13.200 --> 00:14:16.759
and usually if you update the angler version, all of
219
00:14:16.799 --> 00:14:21.879
your applications have been affected by a reason change. And
220
00:14:21.919 --> 00:14:27.279
this also shows one characteristic of this single version solution. Namely,
221
00:14:27.399 --> 00:14:31.759
it does not give you the full freedom, the full
222
00:14:31.840 --> 00:14:35.840
dem autonomy. It gives you some amount of team autonomy,
223
00:14:36.399 --> 00:14:39.879
but on the other side, it also gives you less
224
00:14:40.159 --> 00:14:43.399
things to think about. You don't need an abstraction, you
225
00:14:43.480 --> 00:14:48.080
only have one version. But yeah, this is the consequence
226
00:14:48.120 --> 00:14:52.519
that rad off here you have more freedom with multi versions,
227
00:14:52.559 --> 00:14:56.399
but also more moving parts, more things to think about.
228
00:14:57.440 --> 00:15:00.320
So then if we go a step further beyond, say
229
00:15:00.320 --> 00:15:04.159
like the build and deploy time, what happens in the
230
00:15:04.200 --> 00:15:06.960
case of where like let's say i have root version
231
00:15:07.039 --> 00:15:09.879
one loaded in my browser, right, and I'm on some
232
00:15:10.000 --> 00:15:13.279
page that has you know, child version one, right, and
233
00:15:13.320 --> 00:15:17.240
then Manford, you go and update Angular. Everything gets affected,
234
00:15:17.279 --> 00:15:20.320
everything gets deployed, right, So now everything's on version two
235
00:15:20.320 --> 00:15:26.000
and I navigate to another page that would load child two, right,
236
00:15:26.519 --> 00:15:30.960
how does my root version one not load child version
237
00:15:30.960 --> 00:15:33.679
two and then have an incompatibility mismatch? Or how do
238
00:15:33.720 --> 00:15:37.960
you prevent like someone's existing application or cased application from
239
00:15:38.080 --> 00:15:42.960
loading from a CDN an invalid version because of the
240
00:15:43.080 --> 00:15:44.240
version mismatching.
241
00:15:44.080 --> 00:15:45.799
Just to a hard to refresh on every navigation?
242
00:15:46.240 --> 00:15:50.440
Oh, hard refresh on every navigation? Okay, got it right? Yeah,
243
00:15:50.799 --> 00:15:51.879
I'm sure that is the answer.
244
00:15:52.120 --> 00:15:54.879
Yeah, I mean I'm in hype. But link in decoration
245
00:15:55.120 --> 00:15:59.080
is indeed's the symbol solution, and we see it's in
246
00:15:59.120 --> 00:16:04.159
some area, especially when we talk about product suits like
247
00:16:04.320 --> 00:16:08.720
Office three sixty five or the Google suits where Google
248
00:16:08.840 --> 00:16:14.279
Sheets and Google Forms is a completely different application. And
249
00:16:14.679 --> 00:16:19.039
in my opinion, it's okay as long as you don't
250
00:16:19.120 --> 00:16:22.080
need to switch around for a single desk. If you
251
00:16:22.120 --> 00:16:24.960
need to switch around for a single dosk, and if
252
00:16:25.000 --> 00:16:29.120
you have to go with ten page refreshers, then it's
253
00:16:29.200 --> 00:16:32.159
really a mess, you know. But otherwise, if you say,
254
00:16:32.639 --> 00:16:37.000
if I do an article, I'm sticking with Word for
255
00:16:37.039 --> 00:16:40.399
the next six hours, if I do the buttshed for
256
00:16:40.480 --> 00:16:43.320
the next year, I stick with Axle for the next
257
00:16:43.399 --> 00:16:48.559
six months, then it might be okay. But if this
258
00:16:48.639 --> 00:16:52.000
is not the case, well, if you really have several
259
00:16:52.399 --> 00:16:56.080
versions side by side, then each version needs to have
260
00:16:56.159 --> 00:17:02.159
some MATA data. This can be as simple as a
261
00:17:02.320 --> 00:17:07.160
chasing file that is published with the Shell application, or
262
00:17:07.200 --> 00:17:12.200
perhaps you have something like a backhand service and NBM
263
00:17:12.359 --> 00:17:15.960
rechestery for a micro round THENCE that tells you, oh,
264
00:17:16.160 --> 00:17:18.640
you are the Shell in version one. Here, I have
265
00:17:18.720 --> 00:17:21.160
those micro round thence for you, and you are the
266
00:17:21.160 --> 00:17:24.160
Shell in version two that is only rolled out to
267
00:17:24.319 --> 00:17:28.480
friendly users so far, and here is the list of
268
00:17:28.759 --> 00:17:29.960
you are microfroundans.
269
00:17:30.319 --> 00:17:33.680
Yeah, so it's not I'm going to go load child too.
270
00:17:33.920 --> 00:17:36.759
It's like, what child toos do I have access to?
271
00:17:37.720 --> 00:17:39.279
Bet, I'm going to pick the child too, I have
272
00:17:39.319 --> 00:17:41.640
access to which would be version one or version two
273
00:17:41.640 --> 00:17:47.799
depending on what child map right importan math effectively Yeah,
274
00:17:48.039 --> 00:17:49.160
yeah you.
275
00:17:48.880 --> 00:17:52.759
That shell knew about at build time kind of thing,
276
00:17:53.440 --> 00:17:56.119
m or more or less. I guess, yeah, okay, that
277
00:17:56.160 --> 00:18:00.559
makes sense. Yeah, someone block listing, or I guess it's
278
00:18:00.559 --> 00:18:04.240
more allow listing, just saying like, hey, you only know
279
00:18:04.279 --> 00:18:06.480
how to load these things, don't just take the most
280
00:18:06.480 --> 00:18:09.160
recent version from the CDN that might be incapatible.
281
00:18:09.720 --> 00:18:13.240
Yeah, yeah, totally, Yeah, Yeah, we need this meta data.
282
00:18:14.240 --> 00:18:19.039
And I think this also shows that we have to
283
00:18:19.240 --> 00:18:24.400
implement a bit to provide a foundation for our architecture.
284
00:18:24.839 --> 00:18:27.799
Sometimes the static chase and file might be good enough.
285
00:18:28.160 --> 00:18:31.799
Sometimes we want to have our own registry where we
286
00:18:31.839 --> 00:18:35.119
can do a quick roll back perhaps, or where we
287
00:18:35.200 --> 00:18:40.000
can give just friendly users during ap testing access to
288
00:18:40.200 --> 00:18:42.920
new vertically something like Yeah.
289
00:18:42.920 --> 00:18:45.400
I think I think it also really touches on. I
290
00:18:45.440 --> 00:18:49.400
think the biggest struggle that we have had with one
291
00:18:49.400 --> 00:18:52.039
of the biggest struggles we've had with microphone and architecture
292
00:18:52.319 --> 00:18:57.519
is local development, because you're not just running one app.
293
00:18:57.599 --> 00:19:03.359
You're running like three apps, so what are what is
294
00:19:03.400 --> 00:19:07.880
your go to solution for local development with the microphont
295
00:19:07.920 --> 00:19:08.640
and architecture.
296
00:19:08.759 --> 00:19:13.119
So really quick, I'm why are you running three apps?
297
00:19:13.240 --> 00:19:15.759
Is that the whole idea that one team is working
298
00:19:15.799 --> 00:19:16.960
on one that's fair?
299
00:19:17.119 --> 00:19:20.160
So for example, we have our like shell app, which
300
00:19:20.200 --> 00:19:23.279
is the host, that's the one that knows, that's the
301
00:19:23.319 --> 00:19:26.720
one that has the routes that lazy load the child apps.
302
00:19:27.680 --> 00:19:30.319
And then so if you're working on app A and
303
00:19:30.400 --> 00:19:34.720
app B or honestly even just the Shell and app A,
304
00:19:35.680 --> 00:19:37.680
you have to have the shell running to be able
305
00:19:37.759 --> 00:19:41.240
to load app A, And so you either have to
306
00:19:41.359 --> 00:19:44.240
run the shell on your machine and then also run
307
00:19:44.359 --> 00:19:47.839
app A on your machine so that app the shell
308
00:19:47.920 --> 00:19:53.200
can load the running app A into the shell, or
309
00:19:53.240 --> 00:19:55.559
you have to pull a running version from somewhere.
310
00:19:56.039 --> 00:20:01.680
But I still confused. Why don't you just work A Usually.
311
00:20:02.920 --> 00:20:05.440
Well, so you can just run app A.
312
00:20:06.200 --> 00:20:09.480
But for example, like our app, the shell has the navigation,
313
00:20:09.680 --> 00:20:12.359
so if I want to test navigating into.
314
00:20:13.279 --> 00:20:15.759
Yeah like stitching things together, okay, yeah, yeah.
315
00:20:15.640 --> 00:20:16.559
Yeah, yeah, yeah.
316
00:20:16.599 --> 00:20:19.160
You can do local development to a certain degree. But
317
00:20:19.279 --> 00:20:24.000
then you're also like our shell provides authentication, and like
318
00:20:24.039 --> 00:20:28.400
a lot of other stuff that the the individual apps
319
00:20:28.400 --> 00:20:31.559
themselves don't necessarily know about. And then if you want
320
00:20:31.599 --> 00:20:36.519
to try to test integration between apps like that is
321
00:20:36.559 --> 00:20:38.799
also a nightmare because then you got to run all
322
00:20:38.839 --> 00:20:39.599
of them.
323
00:20:39.920 --> 00:20:43.039
So yeah, thank you, Yeah you're welcome.
324
00:20:43.519 --> 00:20:46.279
Yeah, you need to do this, especially when you need
325
00:20:46.359 --> 00:20:50.240
to test integration or if you need something from a
326
00:20:50.319 --> 00:20:55.599
different microfound and Dan yeas I would say, ideally, I
327
00:20:55.640 --> 00:20:59.680
know it's not always possible, but ideally, in this beautiful
328
00:20:59.759 --> 00:21:05.480
shot any world, we might imagine you have the maturity
329
00:21:05.559 --> 00:21:09.119
of the tasks in just one application. And perhaps this
330
00:21:09.240 --> 00:21:14.519
one application, when it starts in development as a standalone application,
331
00:21:15.160 --> 00:21:19.839
it has already baked in dumbyshell, a dumbichell that gives
332
00:21:19.920 --> 00:21:24.640
you some dummy implementations of a shell service like authentication
333
00:21:24.799 --> 00:21:27.519
to fake user. You just have to make sure that
334
00:21:27.559 --> 00:21:32.000
the dumbyshell never makes it to production, because then you
335
00:21:32.160 --> 00:21:37.039
really have other issues. Give me to test the integration
336
00:21:37.359 --> 00:21:40.839
or the communication. Then you need to start more than
337
00:21:41.039 --> 00:21:45.160
one application. Hopefully this is not in the maturity of cases.
338
00:21:45.720 --> 00:21:50.319
Yeah, interesting, what are the okay?
339
00:21:50.319 --> 00:21:53.839
So sometimes there are services that you have to share
340
00:21:54.519 --> 00:21:58.799
between microphone applications you obviously don't like. Like you said,
341
00:21:58.839 --> 00:22:02.160
they're meant to be very discrete apps that don't necessarily
342
00:22:02.200 --> 00:22:04.200
know much about each other.
343
00:22:05.440 --> 00:22:07.720
What have you found are the most common.
344
00:22:07.400 --> 00:22:11.160
Services that you need to share between the different apps.
345
00:22:11.799 --> 00:22:17.519
Yeah, it's often some kind of context information that is
346
00:22:17.640 --> 00:22:22.559
wellid system wide. It can be a handful of primitive
347
00:22:22.720 --> 00:22:26.640
dot dot diypes like who is the current user his
348
00:22:26.880 --> 00:22:31.000
or her ID? Or do we talk about this standard
349
00:22:31.240 --> 00:22:33.960
or a different eend? Or do we talk about this
350
00:22:34.119 --> 00:22:37.759
physical year or their last physical year? Something like this,
351
00:22:37.880 --> 00:22:42.799
some general context information you want to share for the
352
00:22:42.920 --> 00:22:46.359
sake of usability. The user don't want to select the
353
00:22:46.400 --> 00:22:53.039
same data diamand again you should not share stuff for
354
00:22:53.319 --> 00:22:58.160
the case of caching, because this really couples your domains together,
355
00:22:58.720 --> 00:23:01.799
and it's also a trade off. If you really go
356
00:23:01.880 --> 00:23:06.160
down this road, you sometimes might load the same data
357
00:23:06.279 --> 00:23:11.200
in different domains, in different microfroundands, and you don't catch
358
00:23:11.279 --> 00:23:15.279
it because you don't want to bind yourself to other verticals.
359
00:23:15.640 --> 00:23:19.039
On the other side, chances are that it is not
360
00:23:19.240 --> 00:23:23.680
exactly the same data because often in different domains you
361
00:23:23.759 --> 00:23:27.519
have a different perspective to the same data. A product
362
00:23:27.599 --> 00:23:32.440
from your stock perspective looks different than a product from
363
00:23:32.519 --> 00:23:36.359
your shop perspective or from marketing, so it might be
364
00:23:36.480 --> 00:23:41.119
the same but in a different shape. Yeah. And another
365
00:23:41.200 --> 00:23:45.799
thing we often share is a simple let's call it
366
00:23:45.920 --> 00:23:50.559
shell service, a service with weel please now display this
367
00:23:50.799 --> 00:23:54.119
to the user in a unified way, an a message
368
00:23:54.200 --> 00:23:57.279
pop it up, or a dosed message. Perhaps we don't
369
00:23:57.319 --> 00:24:00.680
even call it dosed. Perhaps we call it in neutral
370
00:24:00.720 --> 00:24:05.200
way so that the shell itself can decide how it's displayed.
371
00:24:06.759 --> 00:24:07.200
Interesting.
372
00:24:07.319 --> 00:24:09.200
Yeah, one of the things we share is feature flags,
373
00:24:09.200 --> 00:24:10.480
but I don't know if we're supposed to do it
374
00:24:10.480 --> 00:24:12.920
that way, so.
375
00:24:12.920 --> 00:24:16.160
It's possible, or you could also define that each and
376
00:24:16.279 --> 00:24:20.279
every vertically, each and every microfront and has its own
377
00:24:20.319 --> 00:24:21.319
feature flags.
378
00:24:21.519 --> 00:24:21.799
Yeah.
379
00:24:21.839 --> 00:24:24.519
I think we have the base services part of the shell,
380
00:24:24.680 --> 00:24:28.960
and then each service, each micro service defines its own
381
00:24:29.119 --> 00:24:31.359
set of flags that it uses.
382
00:24:31.440 --> 00:24:33.400
So man, it's complicated.
383
00:24:34.240 --> 00:24:37.119
So yeah, and it's always trade off. There is no
384
00:24:37.319 --> 00:24:42.000
right solution. It's always a trade off. I think if
385
00:24:42.039 --> 00:24:45.519
you are aware of this tradeoff, and if it is
386
00:24:45.559 --> 00:24:48.759
a deliberate decisions where you take all the bros and
387
00:24:48.839 --> 00:24:51.480
cons into account, then it's fine.
388
00:24:52.279 --> 00:24:53.079
So if it just.
389
00:24:53.119 --> 00:24:56.759
Happened by incident, then perhaps you might end up in
390
00:24:56.799 --> 00:24:59.960
an in an how do you call it that?
391
00:25:00.079 --> 00:25:03.759
And yeah, yeah, so if you're if you were so,
392
00:25:03.880 --> 00:25:06.400
Let's say you were taking on a new client and
393
00:25:06.440 --> 00:25:11.839
they were considering implementing microphone and architecture with federation in
394
00:25:11.920 --> 00:25:17.079
their and their apps. What kind of questions are you
395
00:25:17.160 --> 00:25:20.200
going to be asking to determine if they actually need it.
396
00:25:21.200 --> 00:25:24.960
Yeah, that's that's a good point because I really like
397
00:25:25.079 --> 00:25:28.440
the idea of microfroundance and I have helped a lot
398
00:25:28.480 --> 00:25:32.279
of companies with it, but I have also advised against
399
00:25:32.319 --> 00:25:36.440
it quite often because it does not always fit and
400
00:25:36.880 --> 00:25:41.400
if you use it without really a need, then you
401
00:25:41.519 --> 00:25:45.720
have a lot of troubles, a lot of extra work
402
00:25:45.759 --> 00:25:48.880
to do. So the first thing is I want to
403
00:25:48.960 --> 00:25:53.400
find out why they need this kind of architecture, and
404
00:25:53.720 --> 00:25:57.279
if it is not about steam autonomy, if they would say, well,
405
00:25:57.599 --> 00:26:01.039
it's totally fine, we only have one or two teams
406
00:26:01.359 --> 00:26:05.000
and they can perfectly work together in one mono repository,
407
00:26:05.400 --> 00:26:08.799
then I would really stick with something like an AX
408
00:26:08.960 --> 00:26:12.880
and or a share with because it's a default architecture.
409
00:26:13.240 --> 00:26:17.759
We get everything scareful that everyone knows it and it's
410
00:26:17.799 --> 00:26:21.880
heavily tested, so I would really stick with it. On
411
00:26:21.920 --> 00:26:25.279
the other side, if you are a bank that says, well,
412
00:26:25.559 --> 00:26:29.480
we have different developers around the entire clube with different
413
00:26:29.720 --> 00:26:34.079
betteralist knowledge and they don't work together. They are in
414
00:26:34.160 --> 00:26:39.440
different knowledge spheres and putting them in one mono repository
415
00:26:39.400 --> 00:26:43.599
it does not work. Then yeah, this approach is quite tempting.
416
00:26:44.000 --> 00:26:46.440
Then perhaps we need to make sure they are not
417
00:26:46.640 --> 00:26:50.079
running into open knives, that they are doing it safely,
418
00:26:50.519 --> 00:26:53.400
that they are aware of some challenges like you know,
419
00:26:53.680 --> 00:26:59.599
different routers or abstracting different versions of different frameworks, stuff
420
00:26:59.640 --> 00:27:02.920
like this. But this is then the roads we go down.
421
00:27:05.359 --> 00:27:08.440
Good morning, you know that moment when your coffee hasn't
422
00:27:08.519 --> 00:27:11.039
kicked in yet but your slack is already blowing up
423
00:27:11.039 --> 00:27:13.559
with Hey did you hear about that new framework that
424
00:27:13.680 --> 00:27:14.200
just dropped?
425
00:27:14.680 --> 00:27:16.000
Yeah, me too.
426
00:27:17.079 --> 00:27:20.079
That's why I created the Weekly dev Spur, the newsletter
427
00:27:20.119 --> 00:27:22.839
that catches you up on all the web deaf chaos
428
00:27:22.960 --> 00:27:25.880
while you're still on your first cup. Oh look, another
429
00:27:25.920 --> 00:27:30.279
anger feature was just released, and what's this typescripts doing
430
00:27:30.759 --> 00:27:36.440
something again? Look also through the poor requests and change
431
00:27:36.440 --> 00:27:39.119
shot gramma so you don't have to five minutes with
432
00:27:39.279 --> 00:27:42.680
my newsletter on Wednesday morning, and you'll be the most
433
00:27:42.720 --> 00:27:47.440
informed person in your standard. Ah, that's better the Weekly
434
00:27:47.480 --> 00:27:50.599
desper because your brain deserves a gentle onboarding to the
435
00:27:50.640 --> 00:27:54.720
week's tech madness. Sign up at Weeklybrew dot dev and
436
00:27:54.799 --> 00:27:57.480
get your dose of deaf news with your morning caffee.
437
00:27:57.599 --> 00:28:00.759
No hype, no clickbait, just the updates that actually matter.
438
00:28:01.319 --> 00:28:06.480
Your Wednesday morning self will thank you. Would you generally
439
00:28:06.680 --> 00:28:11.640
say that doing microfundance in a mono repository is easier
440
00:28:12.039 --> 00:28:16.039
versus when they are separate or poly rapos.
441
00:28:16.359 --> 00:28:20.359
Yeah, it's a bit easier because you are forced to
442
00:28:20.640 --> 00:28:24.000
just have at least one version at one time. Also,
443
00:28:24.279 --> 00:28:28.759
sharing stuff is easier. Of course, in theory we should
444
00:28:28.960 --> 00:28:32.640
not share a thing, but in practice sometimes we need
445
00:28:32.680 --> 00:28:36.960
to share something, and if it is not use case specific,
446
00:28:37.119 --> 00:28:40.880
it's something technically we need to share our way of
447
00:28:41.000 --> 00:28:45.359
doing authentication in our big corporation, for instance, which is
448
00:28:45.440 --> 00:28:49.759
quite common, or our design system, and yeah, this is
449
00:28:49.920 --> 00:28:52.200
this is easier to be shared in a in a
450
00:28:52.279 --> 00:28:56.359
mono repository. Saying this it does not give you the
451
00:28:56.480 --> 00:28:58.839
full team autonomy. It gives you a bit of it.
452
00:28:59.240 --> 00:29:04.799
But this it gives you also some some advantages less
453
00:29:04.880 --> 00:29:07.079
pan when sharing things.
454
00:29:08.160 --> 00:29:11.839
What are some of the most common issues you see
455
00:29:12.200 --> 00:29:14.519
with people adopting.
456
00:29:15.880 --> 00:29:24.440
Microphone Well, I think one difficult topic is not even
457
00:29:24.640 --> 00:29:29.039
a technically topic. It's about slicing the system into parts
458
00:29:29.480 --> 00:29:32.480
that don't need to know much about each other. Because
459
00:29:32.519 --> 00:29:35.680
there is never a perfect way of slicing things. There
460
00:29:35.720 --> 00:29:39.880
are several heuristics do main driven design has defined some
461
00:29:39.960 --> 00:29:42.920
of them. They are in handy, but at the end
462
00:29:42.960 --> 00:29:48.680
of the day, you only have possible candidates for slices,
463
00:29:48.960 --> 00:29:51.880
and none of them is perfect. So this is one
464
00:29:51.960 --> 00:29:54.920
of the challenges. You have to find out which of
465
00:29:54.960 --> 00:30:01.400
those candidates have more advantages than disadvantages. And when you
466
00:30:01.599 --> 00:30:08.720
start sharing libraries, sometimes if you have an exotic library,
467
00:30:10.039 --> 00:30:13.480
it might cause some troubles. It's becoming better and better
468
00:30:14.000 --> 00:30:19.160
because we gain more and more experience with this kind
469
00:30:19.240 --> 00:30:23.839
of exotic libraries or libraries we would not have expected
470
00:30:23.880 --> 00:30:28.039
to do this or that's that way. But yeah, sometimes
471
00:30:28.119 --> 00:30:30.720
if we compile it to be shared at run time,
472
00:30:31.400 --> 00:30:35.039
we have some issues, like one best that it with
473
00:30:35.119 --> 00:30:39.640
this compilation mode, with this off level usage of compilation.
474
00:30:40.559 --> 00:30:43.200
Do you have an example of such an exotic library.
475
00:30:44.599 --> 00:30:46.400
I'll just wrap my head around it.
476
00:30:47.000 --> 00:30:51.440
Yeah, so one example we have. Meanwhile, it's solved. But
477
00:30:51.640 --> 00:30:56.920
one thing we did not think about is a component
478
00:30:57.079 --> 00:31:02.680
library that has a taming system that is separate from
479
00:31:02.720 --> 00:31:07.359
the component library, and if I compile both of them
480
00:31:07.440 --> 00:31:11.599
separately so that they can be shared separately, at run time,
481
00:31:12.000 --> 00:31:14.839
they don't know about each other, which might be a
482
00:31:14.839 --> 00:31:17.880
good thing at first sight, but at second sight they
483
00:31:17.920 --> 00:31:21.440
have been designed to know about each other because the
484
00:31:21.519 --> 00:31:27.079
component library is asking the theming library about colors and shapes, and.
485
00:31:27.000 --> 00:31:28.480
So yeah, that makes sense.
486
00:31:29.400 --> 00:31:32.200
So meanwhile, we have a solution for this, but this
487
00:31:32.519 --> 00:31:36.720
was one of the things we did not think about originally.
488
00:31:37.559 --> 00:31:40.079
I think it's hard to so my team, we were
489
00:31:40.240 --> 00:31:46.119
working exclusively in a mono repo, and so switching the
490
00:31:46.200 --> 00:31:50.400
microfront ends has been it's been a challenge just because
491
00:31:51.039 --> 00:31:55.119
we're used to the mono repo, and I mean we're
492
00:31:55.119 --> 00:31:58.960
still in a mono repo, which is nice because we're
493
00:31:59.000 --> 00:32:02.200
really kind of getting away with it, but at this
494
00:32:02.279 --> 00:32:06.799
point we've seen a lot of additional complexity. We use
495
00:32:06.839 --> 00:32:11.160
a registry to run locally, so if I run my
496
00:32:11.799 --> 00:32:15.759
app I'm working on locally, it just pulls down what's
497
00:32:15.839 --> 00:32:20.640
on dev for the shell, which works fine, but it's
498
00:32:20.680 --> 00:32:23.440
another point of failure. So if anything goes wrong with
499
00:32:23.480 --> 00:32:26.759
that that registry, then there's another point of failure there.
500
00:32:27.599 --> 00:32:30.079
And you know, when you're developing a new system, like
501
00:32:30.119 --> 00:32:33.079
from the ground up, it can be really like not
502
00:32:33.119 --> 00:32:35.960
only are we developing things, but the teams that are
503
00:32:35.960 --> 00:32:39.279
supporting all the pipelines are developing things and all of that,
504
00:32:39.359 --> 00:32:42.160
and so there's just we've had a lot more points
505
00:32:42.200 --> 00:32:45.640
of failure that have been really difficult to kind of.
506
00:32:47.000 --> 00:32:47.880
They cause delays.
507
00:32:48.720 --> 00:32:51.200
I completely feel you, and this brings us to a
508
00:32:51.240 --> 00:32:54.880
critically point. If you really want to succeed with this
509
00:32:55.079 --> 00:32:58.640
architectural style, and I have seen this at several customers,
510
00:32:59.039 --> 00:33:01.599
you need to have a blood form team that takes
511
00:33:01.640 --> 00:33:05.640
care of all those issues so that the feature teams
512
00:33:05.720 --> 00:33:10.160
don't need to do research, don't need to reinvent the
513
00:33:10.200 --> 00:33:15.240
wil I have seen huge systems with eighty teams around
514
00:33:15.279 --> 00:33:19.400
the globe and they had three people, three architects in
515
00:33:19.519 --> 00:33:22.839
the in the blood form team that have foreseen the
516
00:33:22.960 --> 00:33:27.839
possible issues, that developed solutions for them, so that the
517
00:33:27.920 --> 00:33:31.400
majority of the future teams just could have done but
518
00:33:31.599 --> 00:33:35.400
they are supposed to do namely produce business value in
519
00:33:35.480 --> 00:33:36.599
their areas.
520
00:33:37.200 --> 00:33:39.640
Yeah, I could. I can back that up as well.
521
00:33:40.000 --> 00:33:42.119
One of the things that we did early on was
522
00:33:42.519 --> 00:33:46.960
we wrote several generators like nex plug ins, so that
523
00:33:47.279 --> 00:33:49.359
when people wanted to make a new app, they didn't
524
00:33:49.440 --> 00:33:52.319
have to know how to configure it to work with
525
00:33:52.440 --> 00:33:55.519
the front like with the microphone end. It just it's
526
00:33:55.559 --> 00:33:58.720
born that way. Same thing with all our light like.
527
00:33:58.799 --> 00:34:02.000
So we support a we the generators, which have been
528
00:34:02.119 --> 00:34:07.319
very helpful because that was definitely as a feature doing
529
00:34:07.319 --> 00:34:09.039
feature work, I don't want to have to think about
530
00:34:09.039 --> 00:34:12.000
how do we configure the microphont end now because also
531
00:34:12.239 --> 00:34:14.920
it changes, especially as you mature and realize okay, that
532
00:34:14.960 --> 00:34:16.559
doesn't work now, we need to move on and do
533
00:34:16.639 --> 00:34:19.960
it this way. So yeah, because if you look at
534
00:34:19.960 --> 00:34:23.480
your example, your example looks very simple. Oh, there's a
535
00:34:23.519 --> 00:34:27.039
host and then and then there's remotes, and I just
536
00:34:27.079 --> 00:34:28.880
have to tell the host where the remotes are.
537
00:34:29.360 --> 00:34:33.639
It's easy. And then they're like, oh, except what about
538
00:34:34.159 --> 00:34:35.599
Yeah there's a lot of what abouts.
539
00:34:36.920 --> 00:34:40.400
Yeah, I completely feel you, and having gender rate us
540
00:34:40.519 --> 00:34:45.880
is really a great way to get those issues at
541
00:34:45.920 --> 00:34:50.639
least partially solved. It's bad than such a documentation, you know,
542
00:34:50.800 --> 00:34:54.679
because I don't know about you, but here in Austria,
543
00:34:54.800 --> 00:34:57.800
we don't read a lot of documentation. We just work,
544
00:34:57.920 --> 00:35:02.320
you know, and so we have to generate that you
545
00:35:02.400 --> 00:35:04.800
get it generated and then you have at least your
546
00:35:04.840 --> 00:35:10.559
skeleton that is not not not not fully wrong, that
547
00:35:10.679 --> 00:35:12.559
already goes into their right direction.
548
00:35:13.039 --> 00:35:13.280
Yeah.
549
00:35:13.360 --> 00:35:15.280
I love putting in the generator too, like this is
550
00:35:15.320 --> 00:35:18.880
how you run it, because that's usually the command people
551
00:35:18.880 --> 00:35:20.119
are like, how do I run this thing?
552
00:35:20.159 --> 00:35:20.440
Again?
553
00:35:20.559 --> 00:35:24.760
Like this Like okay, you just have to so so yeah,
554
00:35:24.760 --> 00:35:26.800
it's a great place to document that kind of stuff too.
555
00:35:26.800 --> 00:35:29.039
And also I would say with AI, like I don't
556
00:35:29.079 --> 00:35:32.679
love to write documentation. AI is good at writing documentation,
557
00:35:32.800 --> 00:35:35.000
but it is soberbose that I don't want to read it.
558
00:35:35.360 --> 00:35:39.760
Oh yeah, perhaps we have to use it on both sides.
559
00:35:39.880 --> 00:35:44.079
Wants to blow up some words to sentences and then
560
00:35:44.119 --> 00:35:45.840
shrink it down the words again.
561
00:35:46.519 --> 00:35:48.199
Just give me the three things I need to know
562
00:35:48.239 --> 00:35:49.800
how to this giant text.
563
00:35:50.280 --> 00:35:54.280
Yeah, yeah you do.
564
00:35:56.800 --> 00:35:58.920
Oh that's funny.
565
00:36:00.039 --> 00:36:02.880
So what are some of the best applications that you've
566
00:36:02.920 --> 00:36:07.079
seen of the microfront and architecture, Like situations where it's
567
00:36:07.119 --> 00:36:08.719
just really working for people.
568
00:36:10.119 --> 00:36:15.840
So one example is this huge car manufactorer that wanted
569
00:36:15.960 --> 00:36:21.039
to streamline the communication with their traders out there. And
570
00:36:21.199 --> 00:36:24.519
I did not know before, but there is a lot
571
00:36:24.639 --> 00:36:30.119
of communication. They have about eighty domains, eighty verticals, with
572
00:36:30.400 --> 00:36:33.480
all the possible things like doing a test drive, doing
573
00:36:33.519 --> 00:36:36.960
an insurance, sending you some cars you can have their
574
00:36:37.320 --> 00:36:39.760
perhaps they are sent back when they are not sold.
575
00:36:39.760 --> 00:36:45.119
Stuff like this. So really dozens of things. And yeah,
576
00:36:45.159 --> 00:36:49.320
they sit around the globe and they even use different
577
00:36:49.440 --> 00:36:55.000
technologies because it was not possible to force all of
578
00:36:55.039 --> 00:36:59.199
them into one tax stack. Some of those applications have
579
00:36:59.360 --> 00:37:03.119
already been there and just needed to be integrated. So
580
00:37:03.239 --> 00:37:06.960
they have a very smart shell that not only knows
581
00:37:07.000 --> 00:37:10.800
how to load via Native Federation, it also knows how
582
00:37:10.840 --> 00:37:15.400
to load via Marshall Federation, how to load via iframes,
583
00:37:15.880 --> 00:37:20.199
how do loads via web components, just to bring everything
584
00:37:20.280 --> 00:37:24.119
together to this one integrated trader platform.
585
00:37:24.360 --> 00:37:27.159
Interesting, Okay, so you like in theory the shell can
586
00:37:27.840 --> 00:37:31.639
use more than one federation strategy or even iframes.
587
00:37:32.320 --> 00:37:33.519
Yeah yeah, yeah.
588
00:37:33.599 --> 00:37:34.079
Interesting.
589
00:37:34.480 --> 00:37:37.920
Also SAP is doing this. They have this Luici framework.
590
00:37:38.400 --> 00:37:43.400
They had a similar challenge integrating existing solutions to one
591
00:37:43.519 --> 00:37:44.960
big cloud based solution.
592
00:37:45.480 --> 00:37:46.000
Interesting.
593
00:37:46.280 --> 00:37:48.119
I'd like to that you point out the different teams
594
00:37:48.119 --> 00:37:51.119
because I know, so we're an Angular team at Cisco.
595
00:37:51.519 --> 00:37:53.800
There's a lot of React teams at Cisco's.
596
00:37:53.840 --> 00:37:57.239
There's also some View teams at Cisco, and it is,
597
00:37:59.039 --> 00:38:02.000
you know, I think as Angular devs, I know a
598
00:38:02.000 --> 00:38:04.679
lot of us always get the conversation of well, why
599
00:38:04.679 --> 00:38:08.400
don't we just use React? It comes up a lot.
600
00:38:09.119 --> 00:38:10.920
You know, it's like, well, because I want to. I mean,
601
00:38:10.960 --> 00:38:13.440
actually I have a whole list of reasons why why
602
00:38:13.480 --> 00:38:16.679
I prefer to use Angular, And especially like on our teams.
603
00:38:16.880 --> 00:38:19.440
You know, we work across the globe, we work with
604
00:38:19.639 --> 00:38:22.960
hundreds of other developers. I like the guardrails I can
605
00:38:22.960 --> 00:38:28.559
put into Angular. I've had issues working with React. I
606
00:38:28.599 --> 00:38:31.119
know that some teams are very successful working with React,
607
00:38:32.840 --> 00:38:36.239
but I know no team that likes to be told
608
00:38:36.440 --> 00:38:38.559
I know you're a React team and now you're working
609
00:38:38.639 --> 00:38:40.679
in Angular, or I know you're an Angular team and
610
00:38:40.719 --> 00:38:45.079
now you're working in React. And so it's that is
611
00:38:45.199 --> 00:38:50.159
one benefit of it. But again, like you said, it
612
00:38:50.960 --> 00:38:55.360
requires a sophisticated platform shell to be able to pull
613
00:38:55.400 --> 00:38:55.880
that off.
614
00:38:55.960 --> 00:39:00.880
So yeah, it's really broad checked within the broadchat to
615
00:39:00.920 --> 00:39:02.440
make a sound platform.
616
00:39:02.719 --> 00:39:02.920
Yeah.
617
00:39:03.199 --> 00:39:06.400
Yeah, So if you're gonna if you're to the listeners
618
00:39:06.440 --> 00:39:09.559
that are out there thinking should I use a microphone
619
00:39:09.599 --> 00:39:13.199
and architecture? First of all, A do you need it?
620
00:39:13.840 --> 00:39:15.960
What are your reasons for needing it? And B just
621
00:39:16.039 --> 00:39:18.079
know you're going to spend some time on that shell
622
00:39:18.280 --> 00:39:21.519
app to make it work right for everybody. Also, don't
623
00:39:21.559 --> 00:39:22.480
forget local development.
624
00:39:23.679 --> 00:39:28.440
Yeah, and if you just have one deem, then chances
625
00:39:28.519 --> 00:39:31.639
are you don't need it. It's an overkill. Perhaps there
626
00:39:31.719 --> 00:39:37.519
is one exception to this, which is somewhere in between
627
00:39:37.679 --> 00:39:41.840
microft round dance and the black in system technology bias.
628
00:39:41.920 --> 00:39:45.400
It's about the same on a logic level, it's something different.
629
00:39:45.760 --> 00:39:48.079
But let's say you have a software as a service
630
00:39:48.119 --> 00:39:52.280
platform for severaldenance, then you might need to load some
631
00:39:52.519 --> 00:39:56.920
blug ins for some of your tenants and different plugins
632
00:39:56.960 --> 00:40:00.840
for different dance. Then it also might makes sense if
633
00:40:00.840 --> 00:40:04.119
you just have one team, But then it's more like
634
00:40:04.280 --> 00:40:07.440
blacking scent less like real microfrontance.
635
00:40:08.679 --> 00:40:11.599
Is there I'm sure the answer is it depends.
636
00:40:11.159 --> 00:40:13.280
But is there kind of like always depends?
637
00:40:13.760 --> 00:40:14.760
That's always the answer, right?
638
00:40:14.840 --> 00:40:15.880
Is it depends?
639
00:40:16.440 --> 00:40:20.079
Is there like a point that you would suggest for
640
00:40:20.280 --> 00:40:23.880
someone like someone is in a company would go to
641
00:40:24.039 --> 00:40:27.639
the go to the microphone and native federation type system
642
00:40:27.760 --> 00:40:32.360
versus just like a single hap like is it probably
643
00:40:32.800 --> 00:40:36.280
four teams with each of their own Like I'm sure
644
00:40:36.320 --> 00:40:38.880
that there isn't actually an answer, but maybe some of
645
00:40:38.880 --> 00:40:41.400
our illsteners are thinking like am I on the line,
646
00:40:41.400 --> 00:40:42.840
like should I be using this? Or should I not?
647
00:40:42.920 --> 00:40:44.480
Or am I not big enough? Or my too small?
648
00:40:44.599 --> 00:40:48.159
Like I'm sure there's no answer, So can you verify
649
00:40:48.199 --> 00:40:51.079
that there's no like actual like hardline where you where
650
00:40:51.079 --> 00:40:52.199
you decide to.
651
00:40:52.320 --> 00:40:54.400
Yeah, so it's it's indeed, it's hard to tell a
652
00:40:54.480 --> 00:40:58.519
number because one of the things I had to learn
653
00:40:58.639 --> 00:41:02.559
when it was all they are consulting companies. It really
654
00:41:02.679 --> 00:41:07.159
also depends on the company culture. For some companies, it's
655
00:41:07.199 --> 00:41:11.360
a nightmare. Then four teams need to work together in
656
00:41:11.400 --> 00:41:17.039
one rabusitory, especially when they have different knowledge areas or
657
00:41:17.079 --> 00:41:21.559
a different background. And then I have seen companies where
658
00:41:21.719 --> 00:41:24.599
it is totally fine to have eight or ten or
659
00:41:24.639 --> 00:41:30.760
even more teams working together in one mono repository. Culture
660
00:41:31.119 --> 00:41:35.199
is for sure one thing that influences this. The question
661
00:41:35.280 --> 00:41:39.079
is also which pain are you are you up to
662
00:41:39.320 --> 00:41:42.039
take on? You is it a pane of micro front
663
00:41:42.119 --> 00:41:45.360
and integration or is it some other kind of pain
664
00:41:45.440 --> 00:41:47.920
you have in a big mono repository. Also there you
665
00:41:47.960 --> 00:41:53.199
have some challenges and which Paine is, but you can
666
00:41:53.320 --> 00:41:54.159
take better.
667
00:41:55.159 --> 00:41:58.039
Yeah, I wonder if it's easier to write a platform
668
00:41:58.079 --> 00:42:01.840
shell that can handle the difference and how like how
669
00:42:02.679 --> 00:42:06.559
like can a platform shall actually solve the problem of
670
00:42:06.840 --> 00:42:10.920
team like lack of communication between teams or does it
671
00:42:11.039 --> 00:42:14.199
exacerbate it, like does it make it worse because like
672
00:42:15.000 --> 00:42:16.639
there aren't following rules or something.
673
00:42:18.480 --> 00:42:22.159
That's that's the big question. So yeah, perhaps if we
674
00:42:22.280 --> 00:42:26.480
have different domains that really don't need to know much
675
00:42:26.519 --> 00:42:30.480
about each other, just is container with data that is
676
00:42:30.559 --> 00:42:37.320
sometimes coming from left to right. Like let's say I
677
00:42:37.320 --> 00:42:42.159
I purchase a product here and then I just sent
678
00:42:42.440 --> 00:42:46.280
Oba the least with the items that have been purchased,
679
00:42:46.280 --> 00:42:49.760
and then you are responsible for shipping them. Then it
680
00:42:49.880 --> 00:42:54.039
might work quite nicely. If I need to jump around,
681
00:42:54.119 --> 00:42:58.000
for one desk between a lot of different microfround thens,
682
00:42:58.280 --> 00:43:01.840
different teams built, then this might not be the best
683
00:43:01.920 --> 00:43:02.920
user experience.
684
00:43:05.159 --> 00:43:07.840
What problems do you see people trying to solve with
685
00:43:08.000 --> 00:43:08.840
microphone ends?
686
00:43:08.840 --> 00:43:12.079
That microphone ends just can't solve m.
687
00:43:13.800 --> 00:43:19.920
So what can microfront and is not solve Well, you
688
00:43:20.079 --> 00:43:25.159
still need some amount of communication between the teams because
689
00:43:25.159 --> 00:43:30.320
there's always an interface between those teams and the barts
690
00:43:30.360 --> 00:43:34.079
the teams are implementing, because there is a reason why
691
00:43:34.119 --> 00:43:37.599
it's one system and not two systems. So some amount
692
00:43:37.639 --> 00:43:41.760
of communication you will always have, and you also need
693
00:43:42.039 --> 00:43:49.559
some kind of of governance. In theory, you have all
694
00:43:49.599 --> 00:43:54.480
the freedom with microfround thence, but in practice you should
695
00:43:54.599 --> 00:43:57.519
limit yourself a bit. We don't want to have a
696
00:43:57.559 --> 00:44:01.360
framework zoo. We don't want to use all the possible
697
00:44:01.480 --> 00:44:04.960
frameworks just for fun. Perhaps there's a good reason, as
698
00:44:05.039 --> 00:44:07.559
you say, you have talent for a react, you have
699
00:44:07.639 --> 00:44:12.239
talent for Angola, and you'll have to utilize this talent
700
00:44:12.760 --> 00:44:17.039
and forcing people into using a completely different framework is
701
00:44:17.079 --> 00:44:21.719
not especially motivating. So yeah, this is a good reason,
702
00:44:22.239 --> 00:44:26.679
but just for fun introducing further frameworks just for fund
703
00:44:26.719 --> 00:44:30.360
saying oh, swelled is nice and solid chess is nice.
704
00:44:30.599 --> 00:44:33.639
Let's added to the game, because why not. It's possible
705
00:44:33.880 --> 00:44:36.360
this would be the wrong base, so you need some governance.
706
00:44:36.800 --> 00:44:40.159
Yeah, I could see that well, and you know too,
707
00:44:40.400 --> 00:44:43.920
like the more different versions, everything is on it's just
708
00:44:44.039 --> 00:44:46.840
more code that's getting pulled down into the browser.
709
00:44:47.039 --> 00:44:50.079
And so yeah.
710
00:44:51.039 --> 00:44:55.199
The hopefully lazily, but yeah, it's still pulled down at
711
00:44:55.239 --> 00:44:56.199
some point in time.
712
00:44:56.280 --> 00:45:00.679
And yeah, interesting, Okay, so what does the what does
713
00:45:00.760 --> 00:45:06.519
the integration testing story look like with microphone ends? Why
714
00:45:06.559 --> 00:45:08.119
did you sort of go to with that?
715
00:45:09.000 --> 00:45:13.639
So ideally the maturity of tests are isolated to one
716
00:45:13.760 --> 00:45:18.039
microft roundant, but we also need integration tests. I would
717
00:45:18.039 --> 00:45:23.199
say we need them anyway, but they are more important,
718
00:45:23.280 --> 00:45:26.679
even more important when we have micro round ins, because
719
00:45:26.760 --> 00:45:30.079
you have to make sure that those moving parts play
720
00:45:30.119 --> 00:45:33.039
well the data. Then they meet for the first time
721
00:45:33.079 --> 00:45:36.800
at runtime. So usually you have some kind of staging
722
00:45:36.920 --> 00:45:41.400
environment where you but relish everything, where you test everything
723
00:45:41.960 --> 00:45:45.000
and only if it works there you move it further
724
00:45:45.039 --> 00:45:45.760
into production.
725
00:45:46.559 --> 00:45:48.760
Do you do like when you do tests like that?
726
00:45:48.880 --> 00:45:51.480
Do you do like a full stack integration where you're
727
00:45:51.519 --> 00:45:54.760
just literally just running the app and say writing like
728
00:45:54.760 --> 00:45:58.239
a playwright test to just make sure that you can access.
729
00:45:57.840 --> 00:45:58.679
Each of the apps?
730
00:45:58.679 --> 00:46:01.400
Like what level of testing are you doing at that point?
731
00:46:02.280 --> 00:46:06.440
Yeah, so it's this kind of testing where we know,
732
00:46:06.639 --> 00:46:10.440
at this point in the application we need to phone
733
00:46:10.480 --> 00:46:15.400
over to another vertically to another microfroundance or if you say, well, here,
734
00:46:15.480 --> 00:46:18.880
we have the hyperlink going over there, and we need
735
00:46:18.920 --> 00:46:21.679
to send over the sporameter so that we can go
736
00:46:21.800 --> 00:46:25.840
on with the with the task over there. So this
737
00:46:26.039 --> 00:46:28.199
is something I would focus on.
738
00:46:28.719 --> 00:46:31.280
But mostly just the like the connecting points, not so
739
00:46:31.400 --> 00:46:33.239
much the if I go over there, and then I
740
00:46:33.280 --> 00:46:35.800
can go ahead and do this task, like the task
741
00:46:35.880 --> 00:46:39.559
should be tested within the app itself, and then you're
742
00:46:39.639 --> 00:46:40.159
just connecting.
743
00:46:40.199 --> 00:46:44.559
You're testing the connection points. Mostly yeah, yeah, okay, that
744
00:46:44.599 --> 00:46:51.079
makes a good Yeah, that makes sense. What other like,
745
00:46:51.159 --> 00:46:54.280
what are some of the biggest gatcha's you've seen with people.
746
00:46:54.719 --> 00:46:58.320
Using microphone architecture, Like mistake common mistakes that people make
747
00:46:59.800 --> 00:47:02.199
that that you want people to avoid.
748
00:47:03.840 --> 00:47:06.519
We have one for shures using it when you don't
749
00:47:06.599 --> 00:47:11.519
need it, and I would say the maturity of projects
750
00:47:11.519 --> 00:47:14.679
out there don't need it. We also see this in our.
751
00:47:14.559 --> 00:47:20.119
Workshops where we discuss several architectural styles and the majority,
752
00:47:20.199 --> 00:47:23.320
let's say two thirds, always say, well, we are good
753
00:47:23.440 --> 00:47:27.440
with a monolith, a monolith that is nicely structured internally
754
00:47:27.840 --> 00:47:28.559
in terms of.
755
00:47:28.599 --> 00:47:32.599
All dos or libraries we share with and or an X.
756
00:47:33.400 --> 00:47:37.480
But as soon as you have several tams. People say,
757
00:47:37.519 --> 00:47:40.280
and often this is one third of our audience in
758
00:47:40.360 --> 00:47:44.960
public workshops. Then of course they say, yeah, we have
759
00:47:45.079 --> 00:47:49.239
to go the difficult way and we have to apply
760
00:47:49.599 --> 00:47:54.920
some kind of microfround and strategy. So this is one mistake.
761
00:47:55.159 --> 00:47:58.400
Using it when you don't need it. Then of course
762
00:47:58.480 --> 00:48:01.559
you need to have a platform. If you don't have it,
763
00:48:01.679 --> 00:48:05.280
you will fail. I'm quite sure you will fail. I've
764
00:48:05.320 --> 00:48:09.079
seen this several times when people did it just for
765
00:48:09.239 --> 00:48:14.840
fun without a joint foundation. It's really a nightmare. You
766
00:48:14.920 --> 00:48:18.519
have to think about sharing, but not over sharing stuff,
767
00:48:19.480 --> 00:48:24.119
and somehow you need some kind of design system. Most
768
00:48:24.159 --> 00:48:27.960
people share it via libraries or MBM packages.
769
00:48:29.639 --> 00:48:31.440
Makes it because you don't want your app to look
770
00:48:31.559 --> 00:48:34.480
like it's five different apps patchwork together.
771
00:48:36.239 --> 00:48:38.880
Should not look like a Franckenstein creature.
772
00:48:39.000 --> 00:48:41.719
Right unless you're just like, that's who you are, that's
773
00:48:41.760 --> 00:48:48.960
your company incorporated exactly, doesn't matter what it looks like.
774
00:48:50.480 --> 00:48:54.639
I feel like the well structured monolith solution can get
775
00:48:54.679 --> 00:48:58.840
you pretty far. That's what That's how Trials operates like.
776
00:48:58.840 --> 00:49:01.400
We have multiple apps, but not in the micro front
777
00:49:01.480 --> 00:49:05.480
end type situation. They're literally just like very different business cases.
778
00:49:06.519 --> 00:49:10.199
But there's like there's two or three, like two that
779
00:49:10.239 --> 00:49:12.480
are pretty big and then a couple like smaller ones.
780
00:49:12.480 --> 00:49:14.639
And I think that like for us at least, we're
781
00:49:14.639 --> 00:49:16.239
all small team though, right it's me and then three
782
00:49:16.280 --> 00:49:19.599
others and are developing, right, so and we all work
783
00:49:19.639 --> 00:49:23.960
on everything. But the model iss have gotten us pretty
784
00:49:23.960 --> 00:49:27.039
far in terms of we have yet to come across
785
00:49:27.039 --> 00:49:29.440
the situation where we feel like micro front ends are
786
00:49:29.960 --> 00:49:33.159
even remotely in the conversation for solving any of our problems.
787
00:49:33.280 --> 00:49:35.440
It just needs to way to like the see money
788
00:49:35.519 --> 00:49:38.400
is involved. You scale up like twenty teams in two weeks,
789
00:49:38.440 --> 00:49:40.599
and there you go, and we're.
790
00:49:40.480 --> 00:49:43.920
Way past seed stage. Man, we're way paste stage at
791
00:49:43.960 --> 00:49:46.320
this point, and we're not raising seed rounds like these.
792
00:49:46.360 --> 00:49:52.280
AIBC said, Okay, yeah, I know you're around for a
793
00:49:52.320 --> 00:49:52.880
little bit.
794
00:49:55.000 --> 00:49:58.840
But yeah, that's a really good situation. I always say,
795
00:49:59.000 --> 00:50:01.840
and I have really done both and was a young engineer.
796
00:50:02.320 --> 00:50:07.079
Under engineering is as bad as oboengineering. In both situations,
797
00:50:07.119 --> 00:50:11.199
you end up with a solution that is more difficult
798
00:50:11.239 --> 00:50:13.079
to be maintained than necessary.
799
00:50:14.559 --> 00:50:15.480
Is it difficult?
800
00:50:15.519 --> 00:50:19.400
Like say, let's say Jay, they do get twenty more
801
00:50:19.440 --> 00:50:22.440
teams and they think, ah, now, is the point where
802
00:50:22.559 --> 00:50:26.480
I think we do want microphone and architecture. How difficult
803
00:50:26.599 --> 00:50:28.920
is it to apply to an existing application.
804
00:50:31.239 --> 00:50:32.760
That's a question for you, because I have no idea.
805
00:50:34.920 --> 00:50:39.679
You could use an ex module boundaries or share if
806
00:50:40.320 --> 00:50:44.920
and if you do it, you nowadays already have the
807
00:50:44.960 --> 00:50:48.480
benefits that not everything is in doming it. But if
808
00:50:48.480 --> 00:50:51.920
there are some boundaries, it's easier to migrate to a
809
00:50:52.039 --> 00:50:54.440
later point in time, at a later point in time
810
00:50:54.800 --> 00:50:58.360
to microfroundance. And if we don't need it, even better,
811
00:50:58.440 --> 00:51:00.960
then we stick with a simple solution. So this is
812
00:51:01.320 --> 00:51:03.119
an approach I really like to go with.
813
00:51:04.159 --> 00:51:06.280
Yeah, just if you're not sure if you need it,
814
00:51:06.360 --> 00:51:08.800
start with the monolith or mono like a mono repo,
815
00:51:09.480 --> 00:51:12.840
make sure and define your clear boundaries between your applications,
816
00:51:13.239 --> 00:51:15.039
and then if you do mature to the point that
817
00:51:15.119 --> 00:51:17.599
you do need to tackle it at that point, I
818
00:51:18.480 --> 00:51:19.079
like that plan.
819
00:51:19.480 --> 00:51:21.719
I think that's going to start you well, regardless of
820
00:51:21.760 --> 00:51:23.960
if you go to micro friends in the future anyway,
821
00:51:24.039 --> 00:51:27.559
like yeah, should they need stuff correctly from the get go,
822
00:51:27.719 --> 00:51:30.760
regardless of if you even remotely figure Yeah, so our
823
00:51:30.800 --> 00:51:34.760
listeners know like structure correctly, even even in a.
824
00:51:34.760 --> 00:51:37.760
Monolith yeah, yeah, yeah, yeah, Well I feel like too,
825
00:51:37.880 --> 00:51:41.800
like as as I've matured as an engineer, as i've
826
00:51:42.199 --> 00:51:45.159
you know, like you know, there's when you start your
827
00:51:45.159 --> 00:51:46.679
career you're kind of like, oh, I'm not sure what
828
00:51:46.719 --> 00:51:47.079
I'm doing.
829
00:51:47.079 --> 00:51:49.320
And then you're like, let's do all the things. I
830
00:51:49.360 --> 00:51:51.480
want to try, all the patterns and all the things.
831
00:51:51.519 --> 00:51:52.840
And then you get to the point where you're like,
832
00:51:52.920 --> 00:51:55.559
do we wait, do we actually need this? Like this
833
00:51:55.639 --> 00:51:57.760
sounds like a pain, Like mostly in my brain, what
834
00:51:57.840 --> 00:52:00.320
I'm saying is that sounds like a pain. Do we
835
00:52:00.360 --> 00:52:05.320
really want to maintain that? So you know, it's like
836
00:52:05.360 --> 00:52:10.159
the fewer moving parts you have, the better, Like yeah,
837
00:52:10.199 --> 00:52:13.159
like the fewer points of failure, you know, Like we've
838
00:52:13.239 --> 00:52:14.920
had solutions where we're like, well, I guess we could
839
00:52:14.960 --> 00:52:16.960
spin up a server that sits between here and here,
840
00:52:17.239 --> 00:52:18.800
but then you got to maintain that server and what
841
00:52:18.840 --> 00:52:21.679
happens when that goes down? And so there's all these
842
00:52:21.920 --> 00:52:24.559
anytime you add complexity, you add more points of failure,
843
00:52:24.880 --> 00:52:28.519
more complication, and yeah, you just make your lives harder.
844
00:52:28.559 --> 00:52:32.920
So jop security though, job.
845
00:52:32.840 --> 00:52:35.159
Security, I'm literally the only one that knows how this
846
00:52:35.239 --> 00:52:35.760
thing works.
847
00:52:39.960 --> 00:52:46.920
I can't save you from what I did here, what
848
00:52:47.000 --> 00:52:51.800
do you see for the future of module or Native Federation?
849
00:52:52.519 --> 00:52:57.559
Mm hmm, well you see currently quite a huge adoption.
850
00:52:58.559 --> 00:53:03.320
So then the look into Module Federation, which has meanwhile
851
00:53:03.440 --> 00:53:07.679
be bored to our as back, not to is built
852
00:53:07.760 --> 00:53:11.920
unfortunately because it's too different from that back, but it
853
00:53:12.000 --> 00:53:15.559
has been boarded to our ASPEC. Then we see that
854
00:53:15.639 --> 00:53:18.800
a lot of companies are using it, a lot of
855
00:53:18.960 --> 00:53:25.360
well known companies, and also Native Federation, which is nice
856
00:53:25.480 --> 00:53:28.280
because it allows us to stay close to the angle
857
00:53:28.320 --> 00:53:33.400
of CLI is meanwhile in cooperated by some pretty big names.
858
00:53:33.840 --> 00:53:36.840
Some of them are companies we help, some of them
859
00:53:36.880 --> 00:53:40.519
are companies we just heard about that they are using it.
860
00:53:40.679 --> 00:53:44.400
And this is really awesome when you see, well, such
861
00:53:44.400 --> 00:53:48.519
a big name is using this concept we have worked
862
00:53:48.639 --> 00:53:53.000
with or helped to bring alive. So I think this
863
00:53:53.119 --> 00:53:57.119
is one of the big things there. Another thing that
864
00:53:57.440 --> 00:54:00.719
might help is now we are moving a bit more
865
00:54:00.760 --> 00:54:04.000
back to the backhands don't be with hydration and server
866
00:54:04.159 --> 00:54:09.559
side rendering. So that means that hyperlink integration is not
867
00:54:09.599 --> 00:54:14.480
that painful anymore, because loading a completely new single bitch
868
00:54:14.519 --> 00:54:18.559
application is pretty fast because of re rendering and so
869
00:54:19.280 --> 00:54:22.519
so also this might might help in this space.
870
00:54:23.119 --> 00:54:26.440
Interesting, I guess we did never even we have time now,
871
00:54:26.519 --> 00:54:29.360
but we didn't actually talk about how SSR factors into
872
00:54:29.360 --> 00:54:29.840
this whole life.
873
00:54:29.920 --> 00:54:32.000
Oh yeah, conversation, M.
874
00:54:33.840 --> 00:54:34.039
Yeah.
875
00:54:36.199 --> 00:54:40.079
Short answer is it takes some pine away from hyperlink
876
00:54:40.119 --> 00:54:43.920
integration because it's easier to jump over to a completely
877
00:54:43.960 --> 00:54:45.000
different application.
878
00:54:45.559 --> 00:54:46.159
Makes sense.
879
00:54:47.039 --> 00:54:49.719
So for somebody who wants to let's say you are on.
880
00:54:49.679 --> 00:54:52.320
A team and you've decided microphone and architecture is the
881
00:54:52.320 --> 00:54:55.400
thing I need. Where do you recommend people get started?
882
00:54:56.559 --> 00:55:03.199
Well, there are some good For instance, o'relli has a
883
00:55:03.320 --> 00:55:07.960
good general book on microfroundance. It's written in a way
884
00:55:08.039 --> 00:55:10.480
and I really like this in a way that will
885
00:55:10.559 --> 00:55:14.320
even be relevant in ten or twenty years because it's
886
00:55:14.400 --> 00:55:18.360
about the concepts you know, and concepts stick everything else.
887
00:55:18.400 --> 00:55:22.639
Technology is changing, but concepts will be there in twenty years.
888
00:55:23.079 --> 00:55:25.480
So this is a good starting point when it comes
889
00:55:25.519 --> 00:55:29.599
to the you know, to the Mantel model. We also
890
00:55:29.679 --> 00:55:32.679
have a free book, perhaps we can link hit somewhere
891
00:55:32.719 --> 00:55:38.519
here that looks at the same topic from the perspective
892
00:55:38.599 --> 00:55:42.559
of an Angler developer. It explains how to add federation,
893
00:55:43.119 --> 00:55:48.519
how to share libraries, how to implement dynamic routing, dynamic
894
00:55:48.639 --> 00:55:53.400
black ins and stuff like this helps those Those sources
895
00:55:53.440 --> 00:55:57.280
are not bad, especially when you are in the Anglo space.
896
00:55:58.000 --> 00:56:00.440
I know, like we really in very heavily on the
897
00:56:00.519 --> 00:56:09.280
documentation that you provide with your Native Federation package pretty much.
898
00:56:09.320 --> 00:56:12.360
That's mostly how we got started when we set up
899
00:56:12.360 --> 00:56:12.960
at Cisco.
900
00:56:14.079 --> 00:56:16.559
So that's a great place to So.
901
00:56:16.719 --> 00:56:19.639
We're getting up to the top of the hour here, Manfred.
902
00:56:19.719 --> 00:56:22.280
How should people reach out to you if they have
903
00:56:22.400 --> 00:56:25.920
questions or if they want to chat.
904
00:56:27.480 --> 00:56:32.159
Yeah, you can with pleasure reach out on social media.
905
00:56:32.440 --> 00:56:37.239
I'm on most platforms like you know, x, Twitter, Facebook,
906
00:56:37.679 --> 00:56:42.239
Blue Sky. Meanwhile, LinkedIn is currently a very friendly space.
907
00:56:42.679 --> 00:56:45.119
I think it helps when everything is in there with
908
00:56:45.199 --> 00:56:48.039
their CV, it helps that people stay friendly.
909
00:56:49.360 --> 00:56:49.639
Yeah.
910
00:56:49.679 --> 00:56:53.039
But also we have a contact for on our website,
911
00:56:53.079 --> 00:56:54.360
so as it pleases you.
912
00:56:54.559 --> 00:56:57.320
We can put your personal phone number in the show notes.
913
00:56:58.039 --> 00:57:02.000
Yeah, yeah, please please note phone numbers. I'm really I'm
914
00:57:02.039 --> 00:57:06.159
really bad at using the phone the time in silent mode.
915
00:57:06.320 --> 00:57:10.639
I don't like I know, I like mine is always
916
00:57:10.639 --> 00:57:14.519
on silent. Nothing is allowed to send me notifications. If
917
00:57:14.559 --> 00:57:16.559
I answer you, it's because I went looking to see
918
00:57:17.119 --> 00:57:20.559
so well, thank you so much for your time today
919
00:57:20.559 --> 00:57:21.400
for joining us.
920
00:57:21.800 --> 00:57:23.199
It's always a pleasure to have you on.
921
00:57:24.440 --> 00:57:27.760
I know this episode will air after ERGI Comp, but
922
00:57:27.800 --> 00:57:29.960
I'm really excited to see you again at ERGIE Comp.
923
00:57:32.000 --> 00:57:34.880
Will you be at any of the conferences in Europe
924
00:57:34.960 --> 00:57:35.679
later this year?
925
00:57:36.960 --> 00:57:39.639
Yeah, will be at some of them, at ANCHI Poland
926
00:57:39.719 --> 00:57:44.599
for instance. Nice also an shet in Berlin, so perhaps
927
00:57:44.639 --> 00:57:48.000
we can also catch up somewhere at those conferences.
928
00:57:48.280 --> 00:57:51.079
Nice, Yeah, pretty much. I feel like you're at You're
929
00:57:51.119 --> 00:57:53.360
at most of them. So it's always if you see
930
00:57:53.400 --> 00:57:53.880
don for it.
931
00:57:53.880 --> 00:57:54.400
To say hi.
932
00:57:55.719 --> 00:58:01.920
You're always gracious happy to tell you. So Yeah, thank
933
00:58:01.960 --> 00:58:03.880
you for your time today. Thank you for all that
934
00:58:03.920 --> 00:58:07.639
you contribute to the community. You make our jobs easier.
935
00:58:08.239 --> 00:58:12.639
We very much appreciate that, you know, and I love
936
00:58:12.679 --> 00:58:15.039
what your team has been doing. I know not just
937
00:58:15.159 --> 00:58:17.480
you are contributing, but a lot of the people that
938
00:58:17.519 --> 00:58:20.719
you work with every day are also heavy contributors to
939
00:58:20.760 --> 00:58:23.599
the community, and we appreciate all of the effort that y'all.
940
00:58:23.400 --> 00:58:23.960
Put into that.
941
00:58:24.159 --> 00:58:28.440
So to the listener, thank you for joining us today.
942
00:58:28.559 --> 00:58:31.280
If you would like more content like this, please subscribe
943
00:58:31.280 --> 00:58:34.719
to the podcast. That's how we get the big bucks.
944
00:58:34.400 --> 00:58:41.440
To pay for editing, so thank you for joining us
945
00:58:41.480 --> 00:58:43.920
today and have a great day.
946
00:58:45.199 --> 00:58:46.719
Hey, this is pressed on mine. I'm one of the
947
00:58:46.800 --> 00:58:50.119
NNGI Champions writers. In our daily battle to crush out code,
948
00:58:50.239 --> 00:58:53.639
we run into problems and sometimes those problems aren't easily solved.
949
00:58:54.199 --> 00:58:58.119
Njikompf broadcasts articles and tutorials from NDIE champions like myself
950
00:58:58.159 --> 00:59:00.920
that help make other developers' lives just a little bit easier.
951
00:59:01.480 --> 00:59:04.639
To access these articles, visit medium dot com, forward Slash,
952
00:59:04.760 --> 00:59:05.239
n gcomm.
953
00:59:06.800 --> 00:59:08.960
Thank you for listening to the Angular Plus Show, a
954
00:59:09.239 --> 00:59:13.039
NGCOFF podcast. We'd like to thank our sponsors, the ngcoff
955
00:59:13.159 --> 00:59:17.239
organizers Joe Eames and Aaron Frost, our producer Genebourne, and
956
00:59:17.320 --> 00:59:20.840
our podcast editor and engineer Patrick Kays. You can find
957
00:59:20.880 --> 00:59:31.880
him at spoonful ofmedia dot com.