S8E15 | Angular testing, micro-frontends, and more! | Rainer Hahnekamp - The Angular Plus Show

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.

Speaker 2 (00:21):
Hi there, welcome to another episode of the Angular Plus Show.
I'm going to be your host today. My name is
Brian Love and I am joined today by Chow. How
are you doing today?

Speaker 3 (00:29):
Chow good as usual, putting out fire on a Wednesday.

Speaker 2 (00:33):
Putting out fire. Last time Chaw and I were on
the podcast, if you've already listened to it, you go
back and listen to it. Cha was putting out a
production authentication issue. So that was exciting to watch Chow
try to do that and record a podcast at the
same time, which I think you did very well, so
I hed my yeah.

Speaker 3 (00:51):
Yeah. It was really fun though, because the episode actually
is on authentication.

Speaker 4 (00:56):
That's right.

Speaker 2 (00:57):
That was the funny part about it, was like, hey,
we just like go to a parents that year and
figure this out. Authentication is one of those things that's
we all need it and it's necessary, but it's kind
of a challenging thing and so or it can be
a challenging thing. Anyways, today we are joined by excellent guest.

(01:19):
I don't think we've had him on the podcast so
I'm very excited for this episode. So for the listener,
definitely tune in subscribe. You're gonna love this. Today we
have ranair Hana komp. He's a Google Developer Expert or
GDE and a trusted collaborator on the NGRX team. He
works as a trainer and consultant in the Angular Architects
Expert Network and runs ENGI News, which you might have

(01:41):
seen in your feed, a weekly Angular newsletter. Bryanaire, welcome
to the Angular Plus show. We are very excited to
have you go ahead and say hello to the folks
and introduce yourself as well.

Speaker 4 (01:52):
Yeah, so hello console, congratulations to the pronunciation of my
name perfect German excent.

Speaker 2 (01:58):
I lived in Germany, very very side now, I lived
in Munich for several miles, so I had a very
small taste of the of the language, but not very good.
That's about as good as I can do, so eage
perfect perfect.

Speaker 4 (02:16):
Yeah, So I'm actually love from Germany. I'm from Austria,
but of course Joan speaking country. I'm part of Englan
Architects already, and yeah I'm with Engul Architects since twenty twenty.
Just had my fifth Annivassory in the before that, so
my kind of way into the Angular community. I started

(02:36):
to do freelancing in the late nineties. At that time,
it was kind of Microsoft with dot net, or actually
before dot net. Yeah, and if you look at the
evolution of the web in the old days, it was
just kind of service are grangering. But then much much
better and better JavaScript frameworks arrived. So I started with

(02:58):
prototype less then moved on to you. Yeah exactly. Then
XGS or censure I think that's the name of don't show,
and then everyone was kind of talking about Angulo said
I think we have to switch to Angler as well
because this is now the new stuff. And since then

(03:21):
I stayed with Angela and I don't regret it.

Speaker 2 (03:26):
Yeah, yeah, and you've been a big part of the community.
For those that are listening, if you haven't heard of
Angular Architects, I dropped a link in our show notes,
so go ahead and check that out after the podcast.
That's Angular Architects dot io. You can learn more about
what the team is doing there. One of the other
folks that's very involved in that is Manfred stay here.

(03:47):
Hopefully I didn't pronounce that one too bad. Manfred has
been a huge contributor of the community for many years,
also a Google developer expert angular and has been really
one of the kind of lead just bringing a ton
of knowledge to the community around modular federation and micro
friend ends and some of the complexities around bringing big

(04:09):
projects together at organizations where you might be struggling with
different layers of technology, different types of technology and kind
of trying to bring those all together to be able
to kind of collaborate and work together across teams and
things like that. So be sure to check out their
website and get architects dot io. I know they do
a lot of training and workshops, they're very involved in

(04:30):
the community and bright there you are one of the
kind of the leads on that as well, at least
from my perspective community, and so certainly before we even
get started, just thank you for your contributions to the community.
For those that are like myself and like many others,
you know, we listen and we follow a lot of
the work that you do and it can have a

(04:51):
large impact in our day to day jobs, and so
just certainly want to say thank you Donka Schern for
all of your effort and your work putting your work
out there and share in it with the community. And
you recently just spoke at a conference on micro front
ends you said in Vienna as well, and so congratulations. Yeah,
just a big thank you to all your work. It's
really been a joy to follow along and to listen to.

(05:13):
So those of you that are listening, definitely check out
the Angler Architects on our website. And you can also
check out Blair's enginemus. I think it's ng dash news, right,
but you just you just put it on your own account, right.

Speaker 5 (05:26):
And it's actually everywhere I try to be active in
all ye social media, so YouTube, Twitter, blue Sky also
def too, medium LinkedIn now and I still want to
create an own website.

Speaker 4 (05:41):
I have the domain engine us death of course.

Speaker 2 (05:44):
You of course you do, yes, like a good software
developer domain. But yeah, but I got the domain.

Speaker 6 (05:53):
Baby.

Speaker 2 (05:54):
I'll pay it that twelve dollars a year, so you
bet you one of these days you'll be.

Speaker 4 (05:57):
Able to check it out.

Speaker 6 (06:00):
Right here.

Speaker 2 (06:00):
One of the things that you mentioned is that you're
very involved in open source as well, and so I'd
love to hear a little bit about kind of what
kind of you involved in open source and tell us
a little bit about the projects that you're involved in.
I know you're heavily involved with the NNGRX team and
collaborating there. You're also involved in some of the testing
things around njr X, and you're also involved in testing
around Playwright and some of the component testing. So I

(06:21):
feel a lot at you. Let's just kind of get
started and talk a little bit about what you do
in the open source community and how you got involved.

Speaker 4 (06:29):
Yeah, sure, yes, sure so. I so it took me
sometimes when I started working with architects. For me, it
was the first time that I had to do something
like consulting and creating workshops, creating content. So it took
me two or three years to get used to it.
And then in a way I kind of had the
feeling that I'm missing coding and missing implementing something. I

(06:53):
still want to have this feeling when I talk about
something that I know what I'm how it feels that
if you like this stuff. I had some side projects,
but with the work in the community, you also get
to know other people, and so, for example, I get
in touch with Marcus do Minovitch from the njr X team.
For example, there are some connections that grew and grew

(07:14):
and grew, and then at some point in time Marcus said,
don't you want to join the teams as a trusted
collaborate in this case? And I was very happy that
he asked me because it was always some kind of
a dream job. So this is what I'm currently working most.
Then we also have from other or I'm also involved
in other things, like the Sheriff project, which is coming

(07:37):
also from Angular Architects. It has more an architectural approach,
so not like state management or so. Also the NJRX Toolkit,
which is in kind of an extension to the nj
X Signal Store. We try to keep it very community
related so that a lot of the kind of people
can also contribute their extensions, like Jek's extension that Jaw

(08:01):
is doing within kind of debt, you know. And then
there's also this other project which I guess most people
haven't heard about so far, and that's in Playwright together
with Unice Shady something for component testing for Angula, which
we are currently working on.

Speaker 2 (08:20):
You are a busy man, that's take kind of one
piece of time. Tell us a little bit about your
collaboration with the j X team and with Marco, and
let's just give him a quick shout out. Marco is
one of the primary or I guess the primary author
of the injur X Signals to A project has been
just an overwhelming success from my perspective in terms of

(08:41):
kind of the launch and kind of the implementation there.
And that's been a really exciting to kind of latch
on with all of the work that the Angler team
is doing to really kind of building out this new,
really exciting way of building apps with anger. So tell
us a little bit about that and that project, and
let's let's get into Andy. I'm really excited.

Speaker 4 (09:03):
Yeah. Sure. So I've been a big fan of the
Ngeriic store, so the Global store, and in a way
we were all a little bit surprised when Marco, i
think two years ago announced like a prototype for the
Signal Store, which is kind of a third store. And
at that point in time, there was also Angi cons
and our team where he flew to Salt Lake City

(09:25):
and in the very early morning was getting used to
the American way of life because it was my first
time in the US as well, and there was some
man standing out smoking on the street and he greeted me,
and I thought, I don't I don't know who it is,
because he also had some classes on and he said, yeah,
he's market from Injuricks Okay, And so that's how we

(09:48):
got into the inter into touch and then weld the
of obviously also had some discussions about the Signal store.
My concern has always been like, yeah, why don't you
try to put it into the component or the global store.
And so it went on, so you hadn't already a connection,
and the discussions then continued online. At some point in time,

(10:10):
I made a lot of kind of proposals, you can
do this, we can do that, and Marcus said, no, no, no, no,
this is not part of the core. Maybe this is
something for the community. If you want and you think
it's a good addition, then do it yourself. And that's
the way then how I got my way into injur x.
By starting out kind of extensions or also try certain

(10:31):
things for the signals store, kind of raised some pr
sense on and so forth. Also did some videos about
injur X, tried to promote it on conferences and talks
and yeah, and so one thing led to another, and
in summer last year, I was then invited to the
dur X team. And now it's interesting the times, I

(10:51):
would say, because with all the signals that we have,
we always, of course we want to be as close
as possible to the new development of the signals. So
there are a lot of things to do, with a
lot of things to discuss. That's yeah, as I said,
interesting times, Yeah.

Speaker 2 (11:08):
That's very cool. I also dropped some links for those
that ares that are listening. Yeah, check out check out
some of the work that ran here and the Angular
Architect's team here is doing on the nd X toolkit.
Looks like they've got a website that you just google
it and you can pull up toolkit. It's probably an
easier way to get to it. But I've also got
some links down in the show notes as well, so

(11:29):
you can check those out. Tell us a little bit
more about the process of actually tackling Like, so you
created this new repository, You kind of started building your
own thing to kind of integrate with NNGRX in the
signal store. What was that process, Like, I mean, obviously
you were connecting communication with Marco and some of the team,
and so you kind of had their like, hey, go ahead,
you know do this and you started building these extensions.

(11:52):
Tell us a little bit more about the toolkit and
what it provides to the developers that might want to
pick it up.

Speaker 4 (11:56):
Yeah, yeah, sure. I mean the first idea was likeind
of integrating the reduct deft tools into the Signal Store.
That's what That's what was the feature. It was already
missing in the Component store. And for us, I mean
when we saw the potential of the Signal Store with
its extensibility, we thought we we thought it needs to
be the Signal Store and an integration for the deaf

(12:17):
tools is definitely something we want to have in a
way kind of we've got the timing, I think, right. So,
there was this Christmas meet up in Gratz, Austria. They
are also Marco was guest, and I had that the
opportunity to kind of present the thing that we just made.
We also made the release live stage. It was all

(12:41):
the very nice and Marko always said, we are not
going to can We are not. We don't have the
resources to support it, but we can at least promote it.
We can give it, we can give the links into
the seqs and so. And I think this was also
a learning from my side that it's not just enough
to build something. You also need to be you have

(13:01):
a voice or you need to have someone who has
a wide reach that helps you to get to get
it out to the community. This is very important. That's
cool and on you. And once you have it out,
you also have to maintain it. So it's like a promise.
People are using it, they trust that you maintain it,
keep it up to date. And this is also something

(13:23):
that you should not underestimate. If a new version of
Injuris comes out, you need to be fast, right because
everyone is waiting. They are saying, we have the death
tools because you made it, we trust you when it's
the release coming.

Speaker 2 (13:37):
Yes, that's correct. Yeah, it's always fun to build something new.
It's it's you know, there's like that classic eighty twenty
you know what I mean, Like twenty percent of the time,
it's like when you build something new, and then eighty
percent of time is when you have to maintain it
and like keep it going right. And that's this is
just such a truth. Oftentimes I don't know about eighty
twenty percent, but it's such a truth in terms of

(13:58):
software engineering and and kind of software architecture, right, it's like, hey,
we build this a really exciting new thing. We build
the prototype, we get it out there and we tweak it,
and we get to a V one launch. You know,
the balloons go up in the air. We're all excited,
and then it's the six or ten year slog. You're
an action say slog six or ten year like love
of just like caring for this this new thing that

(14:20):
you created and keeping it alive. And yeah, so that's
I love that you called that out. Yeah, So for
the listener, if you haven't checked out the n j
X tool kit, go check that out. It's pretty neat.
It's I love that you've you've wired up the dev tools.
The death tools are invaluable sometimes, especially with nj X,
when you're debugging. I think you can get a bye

(14:43):
without the dev tools. Like if you're just pretty solid
with nj X and Angular and our ARCHJSS, like you
could probably get by without it, but at some point
you start doing a whole bunch of taps and console
logs and breakpoints, and the death tools are just so
much better in terms of being able to actually see
the state what's happening, and of the mutations and kind
of what's going on there. So that's great. So you

(15:03):
got some hooks to basically take the Signal Store and
then basically invoke with dev tools kind of wire that up,
and then you also have with reducts and tell us
what inspired you to kind of bring that reduce pattern
back into the Signal Store and kind of what was
the motivation there and have you seen kind of good
success with that and are you using it in projects

(15:25):
that you're working on.

Speaker 4 (15:27):
Yeah. To be honest, I don't use it because I
was kind of at some point in time I was
sold that maybe it is not necessary. But we know
from a lot of companies who have been saying and
still say it. Look, we see the benefit of the
Signal Store with everything that it got, but we steal
from our application from all one protection exactly, we want

(15:51):
to have this event based architecture and as long as
the Signal Store can provide it to us, we are
not going to use it. And well, the first idea was,
then okay, let's just create a write an extension for
it that can do this kind of redox pattern, and
you know it's out. Unfortunately, I don't know the numbers
of the people who are using it. My guess is

(16:13):
should those people download the toolkit because of the death Tools?
So that's that's I mean, I know the official download
numbers of the toolkit, but I don't know exactly how
many people are not using which kind of extension? That's yeah, Okay,
I have I.

Speaker 3 (16:32):
Have a question because it's really cool that we have
a reduct extension or even the death tools extension for
the Signal store. But my question is, like I know
that you implemented it, but my question is which signal
we don't? We don't. Basically, we kind of like the
way that it works with Signal is that we don't

(16:53):
have all of the updates all the time. So how
do you work that into the design or thementation of
the Reducs store, the Redox extension, or even the death
tools extension? Like, at what point do you record an
event to the death tools Joe?

Speaker 4 (17:10):
Do you know what I mean? The great three efect
we are changes to the signals are dropped.

Speaker 3 (17:14):
The signal interrupt?

Speaker 4 (17:16):
Yeah no, no, no, no, no no no, not the signal interrupt.
Do you mean when when the signal changes synchronously multiple
times that you're not able to track this? Okay? Yeah, correct? Correct. Yeah,
So in the first version there was just no possibility. Uh.
And then Marco. Together with Marco, we brought up an
RFD because whenever you want to change something in the

(17:38):
Signal store, you can't just say signal update or signal set.
There is a utility function on top of it, which
is called patch state, so we know exactly when this
signal is going to change, and that's why we can
then also track the synchronous changes there. So there is
now an option in the in the death tools starting
from version ninety where you can say you want to

(18:02):
have the glitch tracking. I think that's silent that I
have it there as well, and then you really see
every change of any of every signal which you're currently cracking.
So that's the way how we did it.

Speaker 3 (18:14):
God, I got it.

Speaker 2 (18:16):
It's a great question, child though, because I was wondering
the same thing and then I saw it in the docks.

Speaker 4 (18:20):
Yeah.

Speaker 2 (18:20):
So they've got this additional function with glitch tracking that
you use add in conjunction with dev tools, which will
allow you to see those intermediary state updates that otherwise
you wouldn't notice exactly.

Speaker 4 (18:32):
And before it was just a simple effect. So we
knew a lot of things were just dropped, but at
least you saw something which is already which is already
also very.

Speaker 2 (18:43):
Helpful, very cool, very cool. So we've talked a little
bit about ngr X and your involvement in the team
there and engrx toolkit, and we definitely want to encourage
people to go check that out if you don't mind,
I'm really curious to talk a little bit more about
kind of what you and Unit are doing in the
play rights space. Is that that to me got my light?

(19:04):
Blah blah blah. I was like dinging, Hey, I want
to hear about this, I guess, So the listener, maybe
before we even get into the component testing and stuff,
give us just a broad overview kind of Playwright and
how that, what that is, and why you're using it,
and then let's talk about component testing specifically, and then
we'll get into kind of what you and units are

(19:25):
kind of tackling.

Speaker 4 (19:27):
Yes, sure, yes, sure. So. So Playwright is actually known
as an end to end testing framework like Cypress. It
is coming from Microsoft, and in a way we can
say there are a lot of similarities, but the main
difference between Playwright and Cypress is that Playwright runs the
tests outside of the browser, so we have full control
whatever we want to do in our tests, and there

(19:49):
are not so many constraints if if you do it
as Cypress is doing it, running the test inside of
the browser. In addition, Playwright next that it has unlimited
resources from Microsoft, so to say, also provides features where
I usually have to pay when you use a Cypress,
like the trace viewer, which is test three playing Cypress,

(20:12):
and also the paralyzation which you also usually get from
the Cypress cloud. So at the moment, I used to
be a big fan of Cypress, but we just see
a lot of companies are in a way kind of switching.
And if you do this, then of course the question
is also not from Cypress to Playwright. Cypress has an
excellent component testing for Angular. I want to have that

(20:34):
in Playwright as well. So this is what has always been,
at least for me, one of the main obstacles when
I was considering a switch from Cypress to Playwright, because
with Cypress component testing, what you can do you don't
need to boot up the application, you don't need you
don't have the application running. You just write like a
component integration test. However, you call it. You have to

(20:56):
test that way. You configure your testing module, You define
the components you want to have also maybe a little
bit of the services, which services you want to moxt
up fake however you want to call it, and then
you only just test that part of the application. It's
in a way like a replacement for what we can
already for what we use these days chess or chessman.

(21:18):
But the big thing is if you use an end
to end testing tool for component testing, you have first
of all, you see something but ready a big help
if you see the component how it behaves to your test.
And also these end to ntesting frameworks they have waiting
features built in, so you don't have to care about
asynchronous tasks which are not executed or that you have

(21:40):
to manage. They will do it for you. Dominvans. If
you say, for example, you type something into an input field,
then in chess mean you have to set the value property,
but then you also have to dispatch the event because
the storm control is listening for the event. You need
to know this. Then to n testing, that's not a problem.
They are doing the real thing for you, so it

(22:01):
becomes much much easier. There is also downside tests are
becoming slower, but I'm happily to I'm I'm happy to
pay the price for it because it definitely improves the
productivity from from my son going and this is the
stage or school at the moment, I would say.

Speaker 2 (22:18):
Yeah, I think that's you think you did a good
job of capturing that. Yeah, so you've got these, You've
got you know, broadly speaking, uh, and end tests using
other cypress or play right. Play right definitely brings a
lot of advantages. I think. One of the things is
the asynchronous coding style and one of the things that
often with me, I haven't it's been a while since

(22:40):
I've write some Cyprus tests now that I think about this,
But the Cybris test, it's kind of got this like
internal qu right, and so you like you kind of
write your test, it's got this like asynchronous like and
I'm using like air quotes, uh for the listener. It's
like async like in that I write these tests. I
write them in like kind of the synchronous fashion. They

(23:01):
get cued and then executed when the function returns or
my test function returns, and then they get executed asynchronously.
And so there's just some nuance around there. And I
think one of the things for me anyways as a developer,
and this is a preference, is just the asinc a
weight approach that it's being used by Playwright is just
much more straightforward for me. It's not like it doesn't

(23:23):
cause some of that confusion around the asynchronosity, at least
the way I think about it, in the way I
write my test. With that said, let's then talk a
little bit more about like component testing specifically. And I
know the component testing is something that has been built
into Cypress, but they must have launched it, I want
to say, like two years ago, maybe a little longer

(23:44):
something like that.

Speaker 4 (23:45):
Yeah, yeah, kind of like that.

Speaker 2 (23:48):
And so the idea here is is rather than doing
like a full integration test or a full end to
end test, now I just want to actually test like
just a component. But I still want to do it
using the Cypress APIs, and this that I'm talking about
were obviously the Playwright APIs. But I still want to
just run a single component and kind of in a
test bed, so to speak. And I want to execute
this component right, run tests against it in the browser,

(24:11):
and so it's a much more narrower focus but you're
still using the same tooling and kind of infrastructure tooling
around that component test instead of just writing like a
unit test where you're just testing this particular unit of
the code. So talk to us a little bit about
what Playwright brings to the table in terms of component
testing and kind of where you you're coming in. You're

(24:32):
I know you're working with Unis on this, so we
definitely want to give a shout out to him. But
tell us a little bit about that. I know that
if I go to the website for Playwright, they have
a page called experimental for component testing, and I don't
think there's much on there about Angular. So tell us
about what you guys are doing and how you're changing that.

Speaker 4 (24:49):
Yeah, yeah, that's always a long background story. So the
component testing, as you said in Playwright, is experimental. It's
for other frameworks, not for INGUDA. And the the way
how Playwright always wanted to have component testing is that
they were saying, look, we can integrate. We can use
any front end framework you want as long as it

(25:10):
is based or that it as long as it works
with WHEAT. This was always the main requirement of Playwright.
In the there was a community project which where I
was not involved. There was Standard from the Netherlands also
units and they have been working also together with Brenton
and some other people from the community kind of integrating

(25:31):
or bringing together WHEAT with Playwright and of course Angular
so that Angler fits into the component testing and exactly
the same way as Playwright wants it. This kind of
project was kind of done. Everyone was waiting for the
final merg of the pull request, and then all of
a sudden there wasn't much a message like no, it's

(25:53):
not going to happen exactly exactly exactly and as a
coincidence at the same time, so I've been thinking about
Playwright component testing although for a long time, and I
was always thinking, is it really worth to try to
to to really kind of squeeze England into this weed
play right environment? What if we just try to do

(26:15):
something like what Angula, what did what we did in Cypress?
Kind of let the Angular Cli run, let it build
the components as it usually does it, and then we
just need to build this setup around it where the
component is then executed in the browser, or this pest,
this test that environment is executed in the browser. There
is no need for WAT and then you have in

(26:36):
a way like a small application running with Angie Serf
or which just was built, and then you can use
Playwright into end testing as you would do with any
other thing. The challenge is you want that Playwright executes
certain code in the browser. For example, you want to
say test pad configure testing module, and this is the

(26:58):
command which is not allowed to running Playwright. You don't
even have to import the file in Playwright because done
and I was the compilable break. You need to find
a way how to extract it from the Playwright end
to end test and put it into the browser. And
this was the idea.

Speaker 7 (27:14):
And I call and I in that net Units at
ANGID in Germany, and I talked to him and I said, look,
this is the idea that I have in case the
current approach doesn't work, maybe we can think about it.

Speaker 4 (27:29):
And then the next day this kind of message from
Playwright came out. We are not going to support it.
And then, of course the conference was still ongoing. I
went to UNIS and I said, what are we going
to do and he said, yeah, let's give it a try,
let's collaborate, and let's follow the other approach. And Units
also had already a prototype. He had this run in

(27:51):
browser thing. He just showed it to me on his
laptop and he said, is this is what you had
in mind? Yes, exactly, this is this is what I
want to do, you know, and we're working on it.

Speaker 2 (28:02):
That's wonderful. Tell me a little bit more and hopefully
we don't get into the weed, because this might be
a difficult question to answer or really just a difficult
question to wrap our heads around, just as listeners and
not looking at code. But tell me a little bit
more about Like, so you mentioned that playwright component. Testing
as it is is kind of uh, I'm not using

(28:23):
your words here. This is the way I understand it.
It's kind of strongly coupled to the VAT ecosystem and
kind of how the building and how that works.

Speaker 4 (28:30):
Okay.

Speaker 2 (28:30):
And we also know that Angular to some extent uses
beat for the dev server, but doesn't use meat for
the build process. What's the kind of the blocker there, like,
kind of what do you do? You have a good
understanding or maybe you can kind of for the listener
to kind of help understand. I don't understand. Maybe I'm
an Angular developer and I'm like, okay, well, but why
don't why doesn't this work? Like why is Angular not

(28:51):
congruned with the rest of the ecosystem around like kind
of the BEAT infrastructure. They're a good way to summarize
that just for the listener as we're kind of thinking
about this and why Angler has to take this different approach.

Speaker 4 (29:03):
To be honest, I don't know exactly. I cannot challenge like, yeah, yeah, yes,
he should, should he should tell.

Speaker 2 (29:14):
Us Jo Why don't you tell us, Joe? Give us
give the listener a like.

Speaker 8 (29:20):
High level overview of kind of what the differences are
and why those differences exist, and kind of why Angler
is a part and and why it doesn't plug into
that same V ecosystem that works with Playwright and Compona
testing And yeah.

Speaker 3 (29:38):
So this is uh, this is internal chat with me
and Brandon, But so I'm not gonna I'm gonna speak
for any Angler c l I team here, but we
know that the Angler people, I guess I the Angle
the team kind of want to uh put people in

(29:59):
a path that they can support and uh and and
provide continuous support, right sure. And with something like VT
we have extensibility, and I just think that extensibility and
the Angleared team doesn't really play well with each other.
Even with the very old web Pack day, with the

(30:21):
web Pack conflict, we even have to use a custom
builder for it. So there's really not much How did
you talk to it? Honestly, it's just the way it
is for just.

Speaker 2 (30:34):
The way that the way the build process works. Maybe
summarize it. The way the build process works is, while
we use v for the dev server, that's just a
local dev AHTP server, right, we don't actually use the
VAT in the plug in ecosystem around THEA in order
to actually do the build process. It's a separate build
process to the Angular goes through. And so when I'm
running something like NG serve or of course NG build,

(30:57):
it's going to go through that separate pipeline, and then
NG nerve is going to kind of then hand that
off and say okay, here now be run this dev
server and set up this websitet connection, and I'll tell
you when things change, and you can do like HMR
and whatnot. But but we're not using the entire meat
like build process in order to actually take all of
our components, compile them, ship them, and like kind of

(31:18):
package them and make them ready for the browser to understand. Right,
I know that's where the disconnect.

Speaker 3 (31:23):
Is, right. I don't want to get I don't want
to get into the weed of that either, because it's
going to coles my understanding. Yeah, but it just I
think it's the limitation of the Angler build pipeline right
now where there's no single file compilation.

Speaker 2 (31:37):
So that's right. Yeah, so that's right. So we can't
we can't compile a single component like in isolation. In
angular it has to know about the entire kind of
structure and world of the entire component structure and how
everything fits together, and then it can kind of compile
that component and build it. But it still has to
know about everything right to a certain extent? Is my
understanding is that writer? Did I miss misspoke there?

Speaker 4 (32:00):
To me, it sounds very similar to what Alex Rickabo
has been talking about. I also when you mentioned the
engine modules, which is not a thing anymore, but exactly
this single file compilation seems to be the main problem.
And as I said before, I mean, if you look
at the amount of work that the team has put
into the VAT integration for Playwright, you really have to

(32:23):
ask the question, is this really what I want as
what whether I want to do is not the VAT integration,
something that needs to come from Angula itself. And if
that's not going to happen, is there another way around
it where I say, look, I don't try it even
because then I have to have the same issues with
every Angler upgrade. I need to check what has changed

(32:44):
in the building process. Do I have to adopt it?
Whereas I also say, look, there is the engine serf
running Angler is doing what Angel is doing. They will
compile the code and I just invest the limited amount
of time that I have into providing the glue code
which connects the end two in test together with the
Angler SELI. Yeah, that's sure.

Speaker 3 (33:04):
Yeah, that's that's a little sidetracking. But that's also our
approach with the analog file momat. Yeah, because we kind
of like, uh, do we even want to be like
our O compiler, But we just say, hey, we're gonna
output a compliant ANGLE component and let the angle compilent

(33:25):
does it work, because we're not going to go back
and try and backward compil everything.

Speaker 4 (33:29):
That makes sense.

Speaker 2 (33:30):
Actually, that makes sense. So r in there, you and
Unice are teamed up and you guys are building this
this ability to build direct component tests, use in Angler
with Playwright. Yes, what's the status of the project? Can
is that something that as an Angular developer I can
go ahead and pick up now start using or is
that currently in development or kind of where are you
guys at with it?

Speaker 4 (33:50):
We are currently so everyone, the two of us, we
have independently created some prototypes, so we know kind of
approval of the concept. It works for me. It was
important for example that I can really do this test
bed set up, ride it into a Playwright test and
it just really executed in the browser. And what I
also know the usual things that you know ready from

(34:11):
Cyprus component testing, like at the end of the test
you want to maybe get access to a service vetchet
from dependency injection, you want to check if a certain
property is set because there is just no other way
how to evaluate it. So these things are already running,
and we have now spent a lot of time into
writing specifications like what things we have to think about,

(34:37):
how does it work when Playwright starts out multiple rock
up processes, How this does work together with the UI
mode which as a file watcher, how do we do
the caching and all that stuff? And so a lot
of things into the design and we really have to
hope that once we do the fire implementation that we
get it right in the first run. I think this

(34:59):
is also important. And by the way, if you have
Unice as guests, you might want to ask him about
his approach on how to write design documents. He can
speak about it for hours. It's one of his foods.

Speaker 2 (35:13):
That's as he's right there now. That sounds interesting. I'm
not sure how many of our listeners would be interesting.
Maybe not, but that's very interesting to me. That sounds
like something. Yeah, that sounds like a very good skill
to have as you're especially if you're building out something
like this. Okay, so it's working. It's still a work
in progress. It sounds like y'all have a repo maybe

(35:34):
on Unis's.

Speaker 4 (35:38):
We decided and not to put it into CHS Cutlery,
but it's going to be Playwright CT at the moment.
That's the working name. There is also a chance that
it lands in Playwright community. We still are unsure about it,
but play has created an own guitub reposits and a
git up organization for community projects off Payloight and would

(35:59):
be happy if we glen.

Speaker 2 (36:00):
That would be fantastic.

Speaker 4 (36:02):
Yeah.

Speaker 2 (36:02):
So if it doesn't roll into the actual official package,
I see your hand up, child. If it doesn't roll
into the official package, hopefully it will be in the community,
broadly speaking a little bit more accessible. You guys would
still be the kind of the maintainers and own that
piece of it, but still part of the broader ecosystem
with then players, go ahead, child, please.

Speaker 3 (36:20):
Yeah. So my question is, let's assume that you and
unit is going to get this thing over the finish line,
and with the amount of trust and faith that I
have in you guys, I would love to to use
this or to migrate to this thing play right component
testing for Angler when it lands now. But I don't

(36:40):
want to use this in this stage right now. What
can I do in my Angler applications, in my Angler
components in terms of testing strategy to set me up
for success when this thing comes down?

Speaker 4 (36:53):
We hope that the that the tests set up this
is the one that you have to make ruct of course,
then that also for the normal tests that you take,
the same test ped setup that you have today, you
put it them into Playwright, and then when it comes
to interaction with your components. Yeah, then you need to
use the playwright API all this way, so you have
to page where, then have your locat us and all

(37:14):
that stuff, so that it's going to change, but when
it comes to the test setup, that one should still
be the same test ped configuration as it is today
with Chester with Chesney.

Speaker 2 (37:26):
That's fantastic, very good, good question. All right, we talked
about njr X, talked about NGRX toolkit, We've talked about
Playwright ct Reradier. Tell us a little bit more about
what you guys are doing in the microfront end space.
I know some people probably know you and your team
for that. Maybe they're going to skip all the way
to this part of the episode, like this is what
I want to listen to. Finally, Brian has asked the question.

(37:46):
Tell us a little bit about what's going on. Give
us a snapshot of kind of what's going on in
the microphone end space and kind of what you're doing
and what your involvement Isn't.

Speaker 4 (37:54):
That yeah, sure, sure sure. So first of all, micro
Fonton's the issue with micro Fulton's I think it's that
it's not of socially supported by INDO law, and we
would have and we wouldn't touch to think about it.
The same old applies of course to NX. They also
do moduo federation for a very long time now. And yeah,
so we are usually active in Germany and there you

(38:17):
have a lot of banks, insurances, big companies using Anglo
all the time. And there you might have hundreds of
developers working on one big application. You never see because
all it's all internal and they always have the same
problem kind of we have so many people, collaboration between
them is impossible anymore. We need to be able to
split the application into multiple pieces, implement them separately from

(38:41):
each other, and during their run time kind of merge
everything together. Maybe also do a separate deployment. And this
is in a way like where microfrontence is important and
there are now different approaches. There is this model federation
approach which started out to be coupled to webpas, which
we had a version A. NIX also had a version.

(39:04):
There was a collaboration between the twos, the two of
us with column from from an X and then of
course also with Sanfred Jo. Manfred then kind of started
to research a little bit like coming up with something
bundler independently, so where you would say, the only thing
when when when when the different microfront thems are merged

(39:24):
together during run time, the only kind of standard or
API that they should have is like em so they
should be Atmoscript modules and then we can just merge
them together. Because with model federation you are in a
way kind of bound to the way how webpec does it.
And this s istem where we started to call the
thing native Federation, which is then really based on the

(39:47):
native exam support from the browser itself. At the same time, yeah,
and at the same time, of course, also NIX has
also continued. I mean I want to mention this as well.
For example with RSPEC, which is now in a way
the successor and you also call them, is doing a
lot of research. Manfred is also interesting in it, so
we have also chats about this as well. And yeah,

(40:10):
it continues to evolve. And what we are currently doing
is that we want to improve how should I say
the things around it. For example, we want to kind
of provide a real documentation website. It should be easier
for developers to contribute, so the documentation is necessarily not
just on how you use it, but also how you

(40:32):
can contribute to it. The testing thing has to be
done a little bit better. Also, the CI process needs
to work a little bit better. And this is where
I currently make my first steps into Native Federation, definitely
becoming a contributor in that case.

Speaker 2 (40:49):
Okay, I've dropped also some more links. I know, I
feel like I'm saying this again and again. You can
of course search for module Federation plug in and architects.
You can get to their documentary. I know you guys
have read me here around Native Federation for angler and
kind of talks through a little bit of what that
is and kind of how you can use that alongside
of module Federation with weird pack and how you can

(41:11):
migrate and that kind of thing. Tell us a little
bit more about your involvement in the project in terms
of kind of some of the tests. You said, some
of the things are still a little short, like documentation.
That's a kind of a classic open source problem to solve.
But talk to us a little bit about some of
these other problems that you're working to solve around, like
testing and some of the things that you mentioned.

Speaker 4 (41:30):
Yeah, So at the moment, I think Manfred is doing
the majority of the work and we want to make
that we want to. We want to also kind of
contributevie it a little bit more. And at the moment
it's a little bit challenging to get into the project.
That's the issue, and so testing could be a little
bit done better. So for example, if you do a change,

(41:52):
you run the test and you know immediately if you're
breaking something or not. Also the way how you can
kind of you want to have something like a minimal
reproducible application, way you can play with it because you
have to know, doing micro fontings is not so easy.
You have to have at least two different applications running.

(42:13):
You also need to do the build process, so there
is a lot of kind of boiler blade work that
you have to do. And this just can be automized
or can be in a way how that development experience
can be improved quite a lot, and then we hope
we can do it way more things that we can
do today.

Speaker 2 (42:32):
That's fantastic some for the listener. If something that checkout
would be the Native Federation and the work that they're
doing here from the Angler Architects team, and then you
also mentioned rs pack and some of the work that
the NX team is doing. We're going to give them
a shout out as well. I know that they're kind
of involved in solving this problem as well and working
of course, that's going to be tightly coupled to the
NX kind of an ecosystem and using NX and all

(42:56):
of that. So that's something that you're not interested in
or not ready for. You know, you could look at
this or you could use there's certainly no reason you
could use the what you guys have built with Native
Federation in NAX. Right, there's no problem there. I can't imagine, right.

Speaker 4 (43:12):
A good question, to be honest, Yeah, you caught me.

Speaker 2 (43:19):
I think the module Federation that people are using with
Webpack and module Federation that was tightly coupled NX, and
I know Colin Colin and a lot of those folks,
so that that's an easy question to answer, right. I mean,
if I'm using web Pack and module Federation NX, all
that works together, no problem. But if I want to
use the native Federation that you guys are building, does
that work with NX? I think is kind of what

(43:39):
I was curious about. And if you don't know the answer,
that's fine. We can we can leave that as a
teaser and people can follow you online and get the
answer later.

Speaker 4 (43:47):
Yeah, but in the end, I mean, as I said,
it is kind of the complete Native Federation story is
built upon that. It doesn't matter. Yeah, in the background,
it's just important that you get use them and then
then Native Federation will do the rest regarding what tool
you use to build it has to be and if
it X springs on our.

Speaker 2 (44:06):
M got it understood. Very cool, Yeah, really wonderful stuff
that you guys are doing here. Tell us a little
bit more about So you mentioned the use case and
some of the folks that are using Module Federation and
Native Federation and the packages that you guys are building.
Is there an easy story that you could tell us
about maybe one of your clients or something without exposing
any sort of details around like kind of the problem

(44:28):
that they solve by using these tools.

Speaker 4 (44:31):
Yeah, of course. So what we usually encounter next to
kind of having two different instances like an old angel
and a new one. But the usual things that we
kind of face is separate deployment, even for smaller teams
when they say, look, I don't want to always deploy everything.

(44:51):
It was I just changed one part of my application
and I just want to deploy this and leave the
rest as it is. This is a very easy fix.
Another thing is, for example, if you have your applications
split into different parts, the build time is if you
have a long build time, you don't have to build
everything at once. That also improves of course a lot.

(45:12):
And of course then the main thing, as I said
in the beginning, is this collaboration. So the more people
you have, the harder it becomes to kind of communicate
manage them. And then it's really like best if you say,
look group A, group B, Group C, you do whatever
you want.

Speaker 2 (45:28):
There are some constraints together.

Speaker 4 (45:31):
There are some constraints though, so you have to make
sure that you that all of them stick to the
same version. That is important because otherwise Singla has an issue.
You can also then mix the web components, but then
things are becoming a little bit more complicated than they
already are. But yeah, that's I would say the main
use case that we encounter large companies having issues coordinating people.

Speaker 2 (45:53):
Do you think that this is a question is just
a personal question, actually, I guess do you think that
most of the people that what they're running into is
that organizational challenge around like large teams? Broad you know,
people working in different time zones. Is that the main
problem that's being solved, or is it the like the
independent what I call independent deployments, Like, is that the
primary issue or do you think the primary issue is

(46:14):
just large teams, large organizations and it's just easier to
keep things kind of siloed.

Speaker 4 (46:20):
Yes, I think it's it's the people, it's the organizational problem.
What I always like to say is, I think so
micro fontens is the art of turning an organizational problem into.

Speaker 2 (46:31):
A danger of technicals. Yes, agreed, agreed, I'm glad, I'm glad.
We see. I'm that otherwise we were going to go
to I was gonna to put my gloves on, you know,
I'm just getting But that is I've been involved in
some projects and that tends to be the case. That's
where micro friends. It's a technical solution to an organizational problem,
which is fossible. I'm not saying that that's a disconnect.
I'm just saying that that's where the problem space lies.

(46:52):
It's often not a technical problem that leads to a
technical solution in this case, you know, leading towards micro
friend ends. It can be, but that's not just my observation.
As it tends to be just organizational, it's just large organizations.
But you still have some of the limitations, like you mentioned,
like using the same Angler version and things like that
is still important. But of course you can also use

(47:13):
microprintends with Anguler and mix it with view and react
as well.

Speaker 4 (47:16):
Right, exactly, exactly, exactly, no problem.

Speaker 2 (47:19):
Then it even.

Speaker 4 (47:21):
Easier because you don't have this version. Yeah, multiple versions
come together.

Speaker 2 (47:27):
Yeah, that's interesting. Chi Any any other questions you have
for the expert here on one of the experts anyways. Uh,
leading folks in the community around micro friending.

Speaker 3 (47:38):
No, I don't post more. You you'll post keep my
brain working in England.

Speaker 2 (47:43):
Agreed, I will, I'll, I'll plus one that Yeah, agreed.
I enjoy kind of following along. It helps me. I
do a lot of Angler consulting as well, and so
it helps me to stay current in order to like
follow in some of the work that you and Monfred
are doing. Well, I might not be like writing the
actual code or something like that. You know, oftentimes it's
playing with some of the examples, watching talks kind of

(48:04):
understanding that. So that way, when I when I'm working
with a client, it's like okay, well, you know, we've
got this new thing over here native you know, do
we want to want to use that? Is that something
that we want to look at using, do a tactical spike,
prove a concept, whatever that looks like. But just knowing
about it and what are the pros and cons and
kind of seeing what you guys are doing is very
helpful for myself personally. So I really appreciate that. But

(48:26):
I hear man I Donka Sharon, thank you for coming
on the podcast. Thank you for sharing with us all
of the things that you're doing. Definitely want to give
a shout out to Unice and the work that you
guys are doing and the component test scenes and playwright.
That'll be exciting for us to follow. For the listener
that is interested in all of this and definitely want
that wants to kind of follow ENGI News and to

(48:48):
all that. Where where do you recommend we kind of
follow you on either blue Sky or x or LinkedIn
or whatever it is. Kind of give us some of
your social handles and we'll put those as links in
the show notes as well, so you don't have Japan
if you're driving, but I'll go ahead and kind of
drop those for us, and we'll get him in the
show notes as well.

Speaker 4 (49:05):
Yeah, sure, so, I mean, in the end, it's just
very easy. I have the same handle everywhere. It's Sima Honeycump.
Once you know how to pronounce my name, you found me,
and yeah.

Speaker 2 (49:14):
I love that.

Speaker 4 (49:15):
I love that.

Speaker 2 (49:16):
That's great. Yeah, I don't have the same handle everywhere
because there's other Brian loves out.

Speaker 4 (49:22):
Yes, yes, I guess so.

Speaker 2 (49:24):
But yeah, I was early in on a couple of them.
They got some sweet handles on like LinkedIn and and
how X. But but nonetheless, it's been an absolute pleasure
to meet you. Thank you for coming on the podcast,
Thanks for sharing with us on all the things that
you're doing. For those that are listening, definitely follow hire
Hong Kong, check out the work that he is doing.

(49:46):
Check out Angular Architects. If you're interested in in bringing
uh A Vanier or Manfred or some of the other
really knowledgeable angular folks that they have on their team,
reach out to them. They're at Angular Architects dot io.
I know that you I do a lot of work
in Germany and German speaking countries, but obviously you're available
to assist worldwide, and so if you are looking at

(50:10):
problems in your company or in your space where you
want to have somebody come on. That's just an actual
expert in Angular micro front ends, just Angular architecture in general.
Reach out to the team. I'm sure they would love
to kind of talk to you and see what they
can do to help you out.

Speaker 4 (50:25):
Child.

Speaker 2 (50:25):
Thank you, appreciate it, man, thanks for joining us today.
I hope you get your other production issue fixed the
best the luct you of my friend.

Speaker 4 (50:34):
Just ship it. You'll be fine.

Speaker 2 (50:35):
Put it behind uh, put it behind the flag.

Speaker 4 (50:38):
I don't know, but I believe in you.

Speaker 2 (50:41):
Okay, and thanks again, Child, And I know for those
that are listening to Child Brandon are doing a ton
of stuff with Analog and so appreciate everything that you
guys are doing there and solving some of those problems
as well. And so yeah, exciting time to be an
Angular developer. So thank you so much for in there
for the listener, Thank you for listening. Don't forget this.
Subscribe and we'll see you next time.

Speaker 4 (51:02):
Goodbye, all right, good bye, thank you. Hey.

Speaker 6 (51:07):
This is Prestoma. I'm one of the Enjie Champions writers
in our daily battle to crush out code we run
into problems, and sometimes those problems aren't easily solved. NGCOMF
broadcasts articles and tutorials from ngie champions like myself that
help make other developers' lives just a little bit easier.
To access these articles, visit medium, dot com, forward slash, ngcomp.

Speaker 1 (51:28):
Thank you for listening to the Angular Plus show in
Chicoff podcast. We'd like to thank our sponsors, the NGCOMF
organizers Joe Eames and Aaron Frost, our producer Gene Bourne,
and our podcast editor and engineer Patrick Kays. You can
find him at spoonful ofmedia dot com.

All Episodes

S8E15 | Angular testing, micro-frontends, and more! | Rainer Hahnekamp

Episode Transcript

Popular Podcasts

New Heights with Jason & Travis Kelce

The Breakfast Club

Fudd Around And Find Out

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}S8E15 | Angular testing, micro-frontends, and more! | Rainer Hahnekamp