Marek Panti is an Angular developer at UNIQA Insurance Group AG. He joins the panel to talk about his article, "Angular Standalone Components". Standalone components simplify the process of creating Angular applications. He explains how he was able to come up with the idea for his article.

Hey there and welcome to another episode of Adventures in Angular. This week on our panel, we have Lucas Paganini.

 

Hey Chuck, good to be back again.

 

Yeah, I'm Charles Max Wood from Top End Devs. Um, and this week we're talking to, uh, Merrick Ponte. Did I, did I get close on your name?

 

Yeah, yeah, it was perfect. Thank you.

 

Do

 

I

 

you

 

am

 

wanna

 

an Angular developer

 

introduce yourself?

 

from

 

Yeah.

 

Bratislava. Yeah, yeah, sure. I am an Angular developer from Bratislava. Basically, I started my career as a designer. But later on, I realized that it wasn't as creative as I thought. So I became more and more into coding. And so I became a big fan of. frontend and angular, but also I do a little bit of node.js and Python and things like this.

 

Very cool. Yeah, we ran across your article about Angular standalone components and some of the things that you had there around the architecture of the app and stuff like that. Do you want to kind of give us the high level view on what standalone components are and how they work just for people who are newer and may not know what they are?

 

Oh, sure, sure. So this is a little bit longer topic. But the thing is that until recently, Angular had everything wrapped up into modules. So it means that you had one page app divided into a couple of feature module. And in

 

Mm-hmm.

 

the highest level of the Angular app, you had the router. And then the router lazy loaded each model. So if you went to a specific route, for example, home or dashboard, you got the model dashboard. But then the trouble was that if the dashboard was big, you still got the big thing lazy loaded. And if you wanted to have some other division, you needed to. create another submodule of that feature module and lazy load it to submodules. And there was another issue that if you had a shared module of some direct use, utilities, helper functions, and so on, and you imported a shared module into some feature module, we imported basically the whole bucket of functionality, even though you used only one method. And then you had the question whether Like if you were about to write a new directive, which would be in a shared directory, for example, you had a question whether you will import it into the shared module or create some small sub-module which would be imported in some feature module. And basically with standalone components we get rid of this, how to say it, of this robust thinking. But it allows us to have a better granularity, basically. But just let me go a little bit back in the history of how this modularity started. It was, I think, 2012 or 2011 when Angular was created. And up until this time, there was only two or three frontend frameworks. frameworks, and none of them was designed or really didn't know that we will do all application in browser. And later, we didn't know that we will use Angular

 

Mm-hmm.

 

for mobiles and for everything. So it was a little bit different kind of thinking. In that case, module made sense because the thinking behind the modules was that it won't be as big. It will be granularized. And yeah, it was a little bit thinking like in the back end. But then React came with sort of better modularity. And

 

Mm-hmm.

 

Angular team realized it, I think it was version 8. But it was very hard to do this separation in the engine. So now I think, now is the time.

 

So it sounds like there's, I guess, more to the architecture discussion here than... Because

 

Definitely.

 

when I initially started thinking about standalone components versus, I guess, a fully-blown Angular app, I was just thinking, okay, this is just feature A, feature B, but it's not. There's more to it than that. So, yeah. So how do you start making the decision, hey, I need a standalone component here versus building in a full... Yeah, I guess. an app that I would normally think of that Angular does.

 

Yeah, so it's very easy. You should either decide at the beginning when you are starting the AD app or if you want to refactor it, you need to think that you need to refactor everything. Luckily, it is quite easy to refactor it to stand alone architecture, but how you should think about it? Well, the first thing is you have to realize if your team is flexible. Like if you have three teams and you are in some robust corporation and everything needs to be approved by management and you are not able to explain the benefits of transforming to standalone components, I think this situation can be hard. Then I would rather continue with modules and maybe in three years start to talk about it. But I can't imagine that this could be trouble because it will take some time to transform it. But if you are starting an app from scratch, I would recommend using the standalone architecture. It has really a lot of benefits. And I would say that the two biggest benefits beside others is the granularity and also the lazy loading, because each component can be now lazy loaded in a router level. And also we have standalone directives and pipes. And also the app component, which is now in the highest part of the app, can be standalone as well and that app component will bootstrap the application.

 

One thing that I thought was interesting that made me click on your argument, and I think it would be beneficial to clarify that to the audience is, even before we had standalone components, correct me if I'm wrong, even before we could already benefit from the most important advice that you're giving him. here because you're actually given two advices. One is to prefer standalone components, standalone pipes and etc. over ng-modularized components. But the other more important advice is that your whole application should not be in a single module. So for example, or you should not have many things defined in a feature module or any other kind of module. So Even before we had standalone

 

Definitely.

 

components in Angular, so for everyone that is running Angular 13 or before, they can already benefit from the structure by having modules that define a single component, such as what Angular Material used to do. So you have

 

Yes.

 

a module just to import and define a single component. And that is the most beneficial advice here, because that will later make it easy to isolate those things. in even other libraries if you want to isolate and reuse. That's right.

 

Exactly, exactly. But basically, before I start to talk about it, we need to say that everything is about good software. If you have something written in a very spaghetti mode, each change or each thing which you want to change is hard and difficult. And sometimes you can be in a decision whether this wrong... code base shouldn't be done from scratch because the harassing situation where refactoring could take actually longer than rewriting it. And this is what we are talking today is basically, those points are about collaboration. So if you are five or more developers, if you want to have a sustainable code base, which would... be possible to maintain even after 10 years from now on. Those are, let's say, some basic things. Yeah. Because of course, we can be very strict. We can have 80% code coverage, for example. We can have, like there are a lot of things which can be done, but this architectural point of view is just like the higher overview on the app. how to make it maintainable, I would say. So, from like my experience is that I was working on a lot of three to four month projects beside my main work. And this is where I learned some of the most practical things from the architecture points. The first thing is that On 50% of projects, after some time, they realize that, ah, we want to have another app and another app and we want to have it together. Basically, in some time,

 

Bye.

 

they realize that maybe we should have a monorepo or we should think about micro-app architecture. And if you want to have a monorepo or micro-app architecture, you need to copy basically some of the common models into libraries. and then having some separate

 

Mm-hmm.

 

applications which are connected in some common dashboard or something like this. Yeah, now imagine a situation that you are starting an app and when you think about this upfront then this decision to bring your monorep or micro app is very easy because you just copy your modules into libraries and that's it. You have... It may be work for two to three days. It's not the work for half a year then. Yeah. From this point, we can talk about some details. For example, my suggestion is that authentication is always a separate module because that authentication

 

Mm-hmm.

 

will be later used for each of your projects and it will be in the library. If not, it's not a problem. Yeah, because... it will be only a separate module in your app. Then another suggestion is to create a so-called, at least I call it a signed-in module. And that signed-in module is basically your whole application. It is just that at the beginning, if you are not signed in, you decide whether you go to that signed-in module or to that authentication module. And that side in a module will have the logic with all the user permissions and there will be all there will be other lazy loaded feature modules connected to that side the model. Yeah. And then, then also another big topic is the state management. And I think this is one of the most crucial things because Also, from my experience, a lot of people use either NGRX or No State at all. And this is a very sensitive thing because again, NGRX is a very robust thing. And it has a big boilerplate. Yeah. We need to admit that. It is good, of course, but it's good for big teams. When you have two to three frontend teams, it's very good to have these NGRX because you have one structure. And you are used to the system that maybe the development will get a bit slower, but it is consistent. But if you have a smaller app where you are two to three developers, you can benefit from some easier solutions. You can even use some type behavior subjects, which would be stored in a service facade. And that subject would be a service basically would hold the data structure to the same level as your view does. And from that point, you can just use your async pipe, and you are done. And also, when you are using the behavior subject, it is very easy to recognize whether you need to do some data update. So when you destroy some component and come back, you don't need to reload your. data from API. It's a very, very easy thing. Yes. So, but then you are using this behavior subject, the development from my experience is maybe from 15 to 20% faster than if you have the NGRX. Because the problem is that on a smaller project, if you are using the NGRX, you need to think strongly about things like, is my property loading? Is it in edit states? And those... to small metadata, you need to store them somewhere. And usually in smaller projects, everything is done in very big speed. And then you don't have time for these decisions and then the NGRX become very badly managed. So it's a bit of a contra-productive. So basically there are a lot of points which needs to be covered up front for my experience.

 

It's funny that you mentioned that because the last episode that we recorded was with Iash and we were talking exactly about that. So

 

Mm-hmm.

 

we had

 

Nice.

 

the entire last episode discussing some native, like not native, but a seed solution that you can build and reuse for your projects in terms of state management or just go directly with NGRX. and Iash was explaining the solution that she created, and every time she starts a new project, she starts with that base structure for state management, and this does not use NGRX, but

 

Yes.

 

it does have a simpler way to manage state, and then later on, sometimes the company chooses to migrate to NGRX, a lot of times

 

Mm-hmm.

 

they don't. and they just keep this seed project due

 

Yeah,

 

to the

 

yeah,

 

simpler,

 

exactly.

 

yeah.

 

No,

 

Interesting.

 

exactly. Also, there are other things here, because if you are using NGRX and at the same time you have test coverage policy on front end, it's a little bit complicated to have all the tests for your effect. Because for effects, you need marbles. And again, I remember that the marbles There is some mocked RXJS which has been changed during last three years, I think two or three times. So on each update, you need to rewrite all your tests. And I'm not sure if this is really a good direction. Because in

 

I

 

the

 

agree,

 

architecture

 

I agree.

 

point of view, I need to

 

Honestly,

 

think

 

the-

 

also about uni tests.

 

Yes, yes. I don't know if you looked into it, but one of the best things that I've done, what my team has done in our projects is to use NGRX data instead of vanilla NGRX. I don't know if you looked into that, but it's really interesting because that means that we don't have to create so much boilerplate for every store, so we don't have to...

 

Yeah,

 

create

 

exactly.

 

each individual

 

It's from

 

effect

 

last

 

and

 

year,

 

then the

 

I think.

 

mocked test for each effect. Yes. Yes. much cleaner approach. So if you want to have task-driven development with NGRX from the beginning, if you're using something like NGRX data, it gets much easier on your side.

 

Yeah, definitely. Definitely, but all two things are... After four years of intense work on Frontend, I realized that this world is quite complex and there is a lot of things which can go wrong from the beginning. And

 

Mm-hmm.

 

then it's really very hard to refactor it because... Some say that, yeah, when you are doing the refactoring, you should do it like step by step. But this step-by-step approach is usually not really possible. Even if I was in some work environment where I had allocated time for refactoring, I knew that I just need to do it at once, because the step-by-step is simply not working. So this can be very tricky, because when everything is everywhere, then it gets very, very bad. And regarding this test driven development, there are, like on front end, there are a couple question marks. And the first question mark is whether you need some percentage of test coverage. Because in my opinion, you don't need to have like 80% test coverage on front end because most of the tests would be click on button, the button was clicked. This is not something you really need. It will just take time to maintain it. What you need is to test your facades and your validation services, your helpers, your utilities, and this is enough. The rest will be covered. But then you cannot have test-driven development, but you can have something. I call it method driven development. And it's basically, I write a method name before I start a new feature. Like I simply download the methods and in comments, I write the return value. Yeah, and then I started developing it. And with that system, you can be quite efficient. It's fast and you are, it's more or less the same as test driven development without the need of maintaining everything.

 

subrat:

Yeah, I think our test development is always a debating topic like we should allow that like we should use that in our component or not because It depends a lot of things I think in real scenario a lot of times you will Not know all the things before before deploying like you will experiment with something then Come up come up with the with approach. So yeah and any type of testing for unit testing can be I think from front end test development TDD is most I I haven't seen much company or team using that as a practice like in back end so in back end it's little easier to go with

 

Yeah,

 

subrat:

TDD than the front

 

yeah,

 

subrat:

end

 

exactly.

 

Also,

 

Also.

 

you were talking about the testing for facades and state management. I would even go one step further on that. So, and I think this is going to be a popular topic because it is what I say in my most popular video so far. So, the most popular video I have is a video about how to organize front-end projects. And the insight that I talk in this video, that I say in this video, the biggest insight is to... isolate your API calls. So even, I think that this is relevant here because I think that even the state module can be broken into two. Because one thing is for you to manage the data that is already cached in your front end and you just want to distribute that. And another responsibility entirely is how do you connect the front end to the back end, which when you create the new user, what is exactly... API route does it make the request to, what is the method used in this HTTP request, how the headers are allocated, all those things. I believe that they can be isolated. I think I'll go even one step further and say that, I think that they should even be framework agnostic. I see no reason for those things to be. Angular specific.

 

Exactly.

 

You could even say, oh, it needs to be Angular specific so that we can use the HTTP client. You can use the HTTP client and still make it framework agnostic. You just have to create a library that connects the browser, the frontend, to your API, and then in your library, you can take the fetch function as an argument. I did that before. I created a library that when you instantiate the API client... you can optionally give it the Fetch function. So if you don't give it, it's just going to use the browser-native Fetch function, but if you give it a Fetch function, it's going to use the custom one. So what I did is, if I'm running my API client in an Angular application, I give it the HTTP client formatted in a Fetch function, and then the API client internally uses the Angular HTTP client. So this way, you can even break the state module that we were talking about in two. You can have the API client, which is simply responsible for making connections to the backend and requesting and receiving data from the correct endpoints. And you can have another layer, which is your data management, your front end data management, which then you would have the

 

Yes.

 

discussion between using NGRX or not, or any other solution. But... That way, I think it becomes even more decoupled.

 

I fully agree. And from what you said is that in this case, this API management would means that you can have different front end apps in different frameworks and they all will share our services. Yeah. And these HTTP client or fetch would be just a variable. Yeah. It's I completely agree because this is This is the granularity which we need, especially for a big project. And the developers need to learn and understand that this is something that we need. I have a friend, and this is a bit of a funny thing. He says that developers, sometimes we are a masochist because we write harmful things, which harms our colleagues and we have headaches. But... When the reality is that when I had junior colleagues, which learned this granularity concept, then they realized that developing new features to such architecture is so easy. Like then everything becomes very easy and you know immediately what needs to be done. Also, If I come to a new project, which is where architecture is like that, it takes me maybe less than one day to understand which functionality is where. In comparison, if everything is somewhere, then it can be even six months. So

 

And it's

 

that's

 

not just

 

the difference.

 

the overhead of the developers understanding, right? It's also faster in terms of actual computing speed for development because if you're using NX or Turbo repo, any kind of monorepository system, they will most likely have a way to build and rebuild only the part of the system that you made changes to. So if you have things in a more granularized way, and you make a change

 

Yes.

 

to a single module, it doesn't rebuild the whole application, it just rebuilds that single module. So even for

 

Yeah,

 

actual

 

exactly.

 

development workflow, it's much faster.

 

Yeah, and this is also another of the things, like sometimes when I open Google Chrome and I have more, like, I don't know, 10 tabs, and I look on my RAM and it has six gigabytes, I'm not sure if this is correct. If because the modern technology allowed us to become a bit lazy. This laziness is basically also killing projects. Yeah, because you can just start writing your random code and after three or four years, you realize that even a small change takes you one week of work. So then basically it kills the project because you actually can bring your project to the point where it's not possible to maintain. And

 

And Marek,

 

then,

 

what advice

 

okay.

 

would you have for the developers just joining a startup and trying to convince, not convinced in the bad

 

Bye.

 

way, not in a manipulative way, but convinced in terms of explaining the reasons why. So how can a new developer in a startup explain to the business side of the company why the developers should take some time to... decide on a better architecture for the project if it's just starting out or if it has already started out, how can they justify it to the business side that they need to stop for a little while and refactor that structure before it gets harder to refactor later. So, and I'm trying to come up with something in terms of the tech depth is not big enough that it became noticeable to the business side yet.

 

Yeah,

 

So

 

yeah, yeah,

 

it's not

 

I understand.

 

in a terrible state yet, but it's coming to that direction.

 

Actually, it's quite easy there and there are two possibilities. The first is just you start a small talk with your management and you see whether they are open-minded or they have some structure. If they are open-minded, you will explain all the arguments which were said here or in your previous podcast. I think on 80% they will just take it and they will understand it. And also I would recommend to show, to have some example, to have some small, small project and some, some example to show it to them. And then very good metaphorical example is electricity in a house. So when the electricity is nicely documented and all cable is shown on a project and you need to do some change or you need to have a new new light switch, then it's easy to connect it. But when you buy a hundred year house, and you want to do some connection, and you call free electricians, and no one knows what needs to be done, yeah?

 

Hahaha!

 

So this is... Ha ha ha. Ha ha ha. Ha ha ha. Ha ha ha. Ha ha ha.

 

I love this

 

You've

 

perfect

 

worked on the

 

analogy.

 

electric coal in my mom's house, that's what you're telling me.

 

Ha ha ha. Ha ha ha. Ha ha ha. Ha ha ha. Yeah, so, I was living in Sydney for two years, we were renting an old house, so yeah, that's... Ha ha ha. which wasn't documented.

 

Mm.

 

Yeah, and then the other approach is...

 

Yeah,

 

Sorry.

 

the way we figure out which circuit the fuses go to in my mom's house is we have somebody go stand in the room we're trying to kill power to, and then we start flipping switches and they yell when it turns off.

 

Yeah, yeah, yeah,

 

I'm not

 

I

 

even

 

know that.

 

joking, the timing of this analogy was so perfect that 15 minutes before this episode, I was trying to use the microwave to heat up my lunch and it wasn't working because somebody is trying to fix the electricity. And I was like, hey, can you please just turn on the power to the microwave so that I can use it? And they were like, I don't know which one is it. Let me go try some here and then you let me know. We were like 10 minutes trying out different connections

 

Mm-hmm.

 

until we made it work. So this was the perfect timing for this example.

 

Thank you,

 

Yeah,

 

have

 

but

 

a happy happy

 

I

 

birthday.

 

have had the exact same thing happen with the code, right? Where it's like, it's like, okay, I need to go add this feature or whatever, right? And so I'll go modify the code where I think the thing is. And yeah, I run my test and nothing changes. And so then I, oh, oh, it's actually over here. And especially with my client projects, there's been a feature that, or a couple of features that I've been adding into these integrations that I've been writing for the last. few months and it's literally been one thing after the other where it's, oh,

 

subrat:

I just figured out that it's a good time to have a little bit of a break.

 

I just figured out that this was the thing that was holding me up to which,

 

subrat:

I feel like I'm not going to be able to do it.

 

you know, somebody else on the team goes, oh,

 

subrat:

Oh, I do want to do it, right?

 

I knew that, right?

 

subrat:

So I'm going to stick with the movement to figure out what to do.

 

But it took me two weeks to figure out what they could have told

 

subrat:

Stick with what we do.

 

me in two

 

Ja, ik zeg het.

 

minutes.

 

subrat:

And I'm going to work with the men and women because of COVID.

 

And it's because the code isn't set up that way to give

 

subrat:

So I'm going to work with the women.

 

you the kind of information you need.

 

subrat:

Yeah, I also had an

 

Yeah, like

 

subrat:

example

 

I,

 

subrat:

like in the

 

yeah.

 

subrat:

You know,

 

Sorry.

 

subrat:

what I was saying is in my first job, I had an example of like, it was a pretty old project, kind of 15 year project with JSF. And we proposed to convert that to Angular when just Angular came, just Angular 2 came. So that is it. So what my approach was like, develop a whole full application with and as a POC. So we put angular as a front end and spring boot as a back end and showcase that how it's easy and how it's easy to tweak that these things and you if you want to change something now it's taking suppose a week and it will take a day or half a day to to change and showcase so then they agree and then the whole whole project changed to angular and spring boot so that's i think the better way to justify a business is to give a monetary value Then like okay, so this will going to save this much a developer time and developer cost is this much and You are saving this this many dollars and

 

Yes,

 

subrat:

so

 

but

 

subrat:

So that's

 

some

 

subrat:

that's

 

things

 

subrat:

a good

 

are

 

subrat:

good

 

not

 

subrat:

way

 

possible

 

subrat:

to approach

 

to measure

 

subrat:

Yeah,

 

because

 

subrat:

yeah

 

it's like measuring, like if you have some company and you have the billboards, you cannot really measure how much revenue it gives you, but it gives you

 

subrat:

Mm-hmm.

 

the profit that if someone new comes to the project, he knows where you are. And also you are happy because I can... I can get really frustrated when I look on the code and I can even go away from such a company if they don't want to change it. But

 

subrat:

Mm-hmm.

 

also regarding the management, it can happen that they will say, no, I won't give you the additional time. And they won't understand it. It can happen. Then you have two possibilities. If you want to stay in that project because you like it, I would just put. higher estimates on everything and I would do that architecture without explaining it to the management. I would just explain it to the team leader, to

 

subrat:

Mm-hmm.

 

my software colleagues. If your developing team has this understanding then you are basically safe. Because it can happen is not the manager of the app and he doesn't understand it and there is some higher hierarchy and it's hard to communicate this issue to the correct person, it can happen. Then I would just do it on a software developer, on a developing team and I would just have higher estimate and that's it.

 

I am going to take a guess here. I don't know if that exists or not, but I think that somebody has already had this trouble in such a hard way that they created the solution. So I'm going to bet that the universe has created the solution that I'm about to say, which is, I think that there is a standardized way of calculating the developer onboarding in a project. So, I'll... Something, for example, create a component, fix this bug and create a service, I don't know, like a set of instructions that you would give to a developer that deeply understands the technologies involved but may not understand your project structure, gives to these developers and tells them to do those three things. So how long it takes for a new developer to do those things. So if you can't... Create such a metric, and if that doesn't exist, it's probably easy to create in your company, in your project. So if you did all the things that we discussed here, you're still having trouble with management, I would say try to come up with a set of instructions that you can give to somebody that doesn't work in your project but understands Angular, and tell them to do those things. Track how long it takes. And then you give this metric to the management side of your business and ask for this person to do the same thing in another project that is using this better structure. And then this other project can be a project from scratch or something like that. And this way you can tell the business side, hey, a new developer joining the company is going to take this X amount of time to... do those simple tasks that every developer will have to do eventually in this project. So this can give you a metric to show to them, which it can be kind of flawed because it depends on the person that takes it, but at least it is a metric. I think it's easier to talk to management in terms of metrics because that way, that's how they would like to see all areas. Like not saying that in a bad way, but... The easiest management ever is when all areas have some kind of performance metric that is quantifiable, and then you can simply try to make that metric better, either making it shorter, or if it's a good metric, such as profit, then you want to enlarge that. So if you can translate your issues into metrics, I think that's a good way to talk to the business side.

 

I like

 

This

 

that.

 

is a really nice approach. I really like this.

 

Yep. My approach

 

Also,

 

has always

 

I think,

 

been, I

 

yep.

 

had clients that basically told me that I'm not paying you to write tests. I'm not paying you to fiddle with all the architecture stuff. Just cram features in. What that eventually wound up with, because I found that I could move as fast or faster doing TDD with my projects. I just put the test directory under gitignore.

 

Hehehehe

 

and then do them anyway.

 

That's genius.

 

Yeah, it's actually exactly as I told before that you should do it anyway

 

subrat:

Yep.

 

Yeah, because this good architecture is not only for the project and for the company, it's even for you as a developer. Like, it won't hurt you. Otherwise, if something is wrong, and especially in modern JavaScript days, when you have a library which is supported until some time and once... someone decided that I'm not gonna support this library, we'll use something else. But you have new Angular which you cannot update because you are using that old library which is deprecated. In this case, it's a must to have a perfect architecture. Otherwise you will go crazy.

 

Yeah. Let's recap some things here, Marek. So help me out if I miss something. Just because we talked about so many things that the audience may have some trouble trying to collect all the insights. So let's recap for a person that is just starting a new project or maybe already has a project but liked our idea and so they want to separate their Angular application into... modules that can be later even isolated in libraries using NX or some other monorepo solution. So we talked about generic things that most applications will benefit from. So most applications will need a state module, which later can become a state library. And this will be responsible for managing the cached state that you have in your application and distributing that. in a reactive way to all the consumers. We can also, so that's one. We can also have another, which would be a library or a module responsible just for the connection between the front end and the back end. It could also have the TypeScript definitions, the types for what you get from the back end and what the back end expects to receive. So we already have two. In the beginning, you mentioned another one, which would be the authentication module.

 

Yes.

 

or signing module. So that one would be fully responsible for the authentication side of your front-end application. And what else can we give for somebody in this situation? So they are either starting a new project or they want to use this structure in their current project, but maybe they don't know how they should separate concerns. So we already gave them three things that... are probably applicable to their scenario, what else can we give into advice of common structures that somebody can use for that scenario?

 

Yeah, if I can generalize it and start from beginning, you should start with answering some questions. Is my application going to be big, medium, or small? Is it for public, or is it for business to business cases? And based on these questions, you need to decide if it's going to be big, if it's going to be medium and for public, I will use NGRX. like official NGRX, I will have at least a minimum of unit tests. And I will start, if it's big, I will start directly with a monorepo because the things will come. If it's small, it's exactly, we will start with the small granular modules. And we need to have in our mind that this model could be possibly later become part of a library. And another topic is to think about also style guide upfront. You have to install your pretty early inter and have a strict TypeScript. And also, I think also there is this SCSS architecture, at least so you should think whether you will have some dark mode or things like this, because if your app will be small and you know that your app will be small, in this case, you might not have such a strict rules for SCSS and you... could have random colors in your components. But if you know that your app is going to be big, you need to also take care about your SESS. But there's a different topic.

 

And what about the feature modules? How can people break that down into more granular structures? For example, let's say that I have a system and I have the users module, so I have a list of users in my system. I have groups. I may have files, like uploaded files. Let's talk about a To Do app. Everybody's familiar with that. So

 

Yeah.

 

you have tasks. You have users, you may have groups or teams. So let's say that you have those three things, those three types of resources in your system. Users, groups, and tasks. Would you create a library for each or would you just put all of them in the main core application and not break it down in terms of feature? Or would you break it down? make it even more granular and inside of users, you would make maybe some of the functionalities of interacting with users in a folder and the actual visual components in another. So how would you make your architecture for the feature modules in the case of a to-do application?

 

Yeah, like basically now I would start with standalone components, which would be like feature standalone components. So we would have tasks component, user components and what was the third? It was task users and settings

 

Groups.

 

groups, sorry, yeah.

 

Groups.

 

And then in the users, I would have another even more granular components and services which would be connected to the domain. And in the app level, we would have router which would lazy load these three features. Like now I think if you are doing the app from scratch, I really recommend to start it with a standalone component. It has a lot of benefits and it will save a lot of trouble. And also, these standalone components, they push you to make granular architecture.

 

Nice, thank you.

 

Thank you very much.

 

And what about actual Monorepo technologies? Do you have a favorite? Is the Grand NX or do you have some other Monorepo technology that you particularly like?

 

This is a good question. Yeah, for me it's NX, just because of the big support. They have a lot of things already in build. And also you have some... It is possible now to track your package JSON, the updates and the vulnerabilities, and if something needs to be updated or if something is deprecated. great handled it within NX. But now at the end of last year or in the middle of last year, the NPM brought its own monorepo. To be honest, I haven't tried it yet, but I think this can be also really great. And also I think Lerna and others are good. I just don't have experience with them, so I cannot compare.

 

You're talking about NPM workspaces?

 

Oh, yes, yeah, sorry, yeah.

 

Oh yeah, yeah, I played a bit with that. I don't know if it could compete with NX, to be honest, because NX also integrates so well with the Angular ecosystem that npm workspaces could never compete with

 

Yeah,

 

that. What

 

done.

 

I can see happening is perhaps NX using npm workspaces to better isolate...

 

Ah, yeah, yeah.

 

the individual parts of the monorepo. But I think that npm workspaces will never have all the features that NX has. But it's an interesting choice for perhaps you just want to start it out. Perhaps you're not even coding in Angular. My use case for using npm workspaces was a library, just a node library. It was not for frontend. It was... actually it was for frontend but also backend so it was a utilities library that I wanted to create and I wanted it to work in frontend and backend so any environment that had JavaScript. And this library would also have some helpers that I wanted to isolate so I tried using npm workspaces to isolate those two things and it it worked out well but it was... It was a bit of a pain to set things up, and especially to make the build process work because one of the libraries needs to import the sibling and that doesn't necessarily works out so well with the build system that you might have for a single library. So I think NX already deals with all that setup for us. So I think it would win, but I haven't checked Learner, so. That could be interesting.

 

Yeah, I think Lerna is maybe easier to set up in some cases, but it doesn't have such a big community. And also, regarding NX, it's good that it supports not only Angular, but also React, Vue, and all the combination of Node.js frameworks. So if you have, I don't know, React and Next, or Angular and Nest, or even if you have Angular on backend Java or Python or whatever, and you are using some tool to export the types. It works perfectly, and it is very easy to set up.

 

Mm-hmm.

 

But there are also

 

Yeah, we

 

some...

 

had Lars

 

Oh

 

Brink

 

yeah.

 

on to talk about NX. Yeah.

 

So what

 

Anyway,

 

you're saying,

 

you were saying?

 

Marek, is that Lerna is more flexible than NX. So if you're using things that NX doesn't support, so for example, some parts of your application are outside of the JavaScript ecosystem. So you have, for example, backend microservices, and one of them is in Java, the other is in Elixir or whatever. So Lerna is a monorepo tool that can integrate. in that scenario

 

No, no, no,

 

or

 

sorry. I was talking

 

am I

 

about

 

wrong?

 

NX with that. I mean, Lerna is maybe easier to maintain when you have just a simple Angular apps, or if you have maybe some simpler use case. But I don't really have a big experience with it. It would have to be tried. No, so also there are still some issues, even with NX, for example. like most recently, Angular is doing updates every half a year. And I think now there was a problem that with Angular 15, you couldn't have the most recent version of NX. We needed to wait for the new NPM package. Yeah, so, so those are, but I think those issues are in JavaScript world overall. So there are still some troubles with the updates. It's not so consistent. So this is something you need to manage as well. Maybe this is also one of the points what we forgot to talk about when we were talking about the architecture, that it doesn't matter if you have React, Vue or Angular, you need to have some update plan. And you need to also have... in your architecture, you need to think that each six months or at least once per year you should do the updating of everything. This

 

Hmm.

 

is also a big topic.

 

subrat:

yeah I think the easiest way will be remove as much dependency as well like if you are using NX you are dependent on NX but that's not the like the actual way people are doing but if you are if you want to update as angular is updating or react or view then you should always follow their concept and not depends on other packages

 

Yeah,

 

subrat:

or

 

yeah, exactly.

 

subrat:

I think that's what most of the product company do I know one company I was interviewing with what they are, what he asked me, should I use this very popular, like from back end I'm saying, should I use the spring boot in our product or not? So I said, yes, it's widely used, it's tested, but what the approach he told that each and everything should be developed by us so that we are not depend at all with any other things. But that's I don't see nowadays it's happening or it should happen because all the packages are also pretty pretty good and like like the annex they are are doing but you might might be three four months behind the

 

Yeah.

 

subrat:

behind the latest release but yeah.

 

Yeah, exactly. Also these things like you have two extremes, like you said, not updating at all and having everything written

 

subrat:

Mm-hmm.

 

by you or having mid-tones of other packages. With the packages and libraries, it's very... This is the thing which I'm not even

 

subrat:

Et...

 

sure if there are some rules. It's maybe a little bit like you need to be a good artist. and a good artist, he just knows what he has to do. So you're new as a tech lead or software architect, you need to understand like which packages to add and what should be written by yourself. This is like a sixth sense or something like that. I'm not sure if it's possible to define how to decide on it.

 

subrat:

याँपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपाइपा

 

Yeah.

 

Yeah.

 

Yep.

 

Marek, before we start to wrap things up,

 

I was.

 

I have one question. So, by the way, sorry Chuck, you were saying something?

 

No, I was going to say I was about to start having us wrap up, so go ahead. And then we'll

 

Oh,

 

wrap up. Ha

 

sorry.

 

ha ha!

 

Okay, let's see if we have time for just one more question.

 

Yeah.

 

So, what I'm wondering is, how are libraries shared between all the micro apps inside your monorepo? So, for example, if you install Lodash, like utilities library, and then, actually, let's use rxjs, since we're talking about Angular, that people will be more familiarized with that. So if you install, you depend on RxJS. Okay, but you actually have many sub-parts of your application, and maybe RxJS releases a new version, and you want to update to this new version, but can you do that part by part in your modularized architecture? Can you update RxJS... to a new major version in just one

 

one.

 

micro application inside your Monorepor? Or do you have to upgrade in all of them at the same time because they're all sharing the same version of the globally installed library? How does that work?

 

It's a very good point. And when you have this question, like if any of your projects starts to have this sort of questions, then it's time to move from monorepo to micro apps. Because when you have micro apps, then you can individually update every app as you want.

 

So there is a

 

In Monorepo, I think,

 

difference in

 

yeah.

 

this definition. So a monorepo,

 

Yes.

 

you're sharing things, you have different parts, but they're sharing a global something in common that is being shared. And when you have micro apps, then it is completely isolated. Is that right?

 

Yes, exactly. And then basically your micro apps are wrapped in one dashboard app or something. They are lazy loaded as well. But the structure is very similar to Monorepo, but the difference is exactly in the, in the package management and everything. But yeah, this, when this becomes a problem, you will, you'll need to move to the micro apps.

 

Gotcha.

 

But a good point, I almost forgot about it.

 

subrat:

I think if you have a lot of small component, I think if you have a lot of small apps, it's always better to go with either micro apps or micro front end. So that will that will be easier in the maintenance phase later.

 

Yeah. Also, I think this topic, like

 

All right. Thank

 

we

 

you, Merrick.

 

talked about a lot of complex things, and it brings the idea about having one tech lead or one senior developer, but someone who understands this on a deep level per project. This is something which companies need to realize.

 

So companies need to realize that they need to hire Merrick to do the architecture

 

Hahaha,

 

subrat:

Hehehehehehe

 

for

 

Hahaha.

 

them.

 

right?

 

I completely agree with that, yes. And how can they do that Merrick, if a company desperately needs to hire you, the co-base is all over the place, you're going to love this project, how can they contact you?

 

via LinkedIn or email. We can do the consultancy.

 

Yeah. If people want to follow you and just see, you know, what you're posting or working on or things like that, um, where do they find you like on Twitter or LinkedIn

 

Yeah, actually,

 

or

 

I don't have I really don't have

 

GitHub?

 

a Twitter. Yeah, so I'm using I'm using only LinkedIn, GitHub and Medium for now. I think LinkedIn is at least at least in Europe, it is more,

 

Okay.

 

it is a bit more comfortable for me to to have everything only on LinkedIn.

 

That makes sense. Yeah, just drop a link in the chat or in the forum and we'll make sure that people get linked up to you if they wanna connect with you.

 

Yeah, I already posted it

 

All right,

 

in the

 

well

 

forum.

 

let's go ahead and. Okay. All right, sounds good. All right, well, I'm going to move us along. Now we did add the, hey, this is the stuff we've got going on, the stuff we wanted to let people know we're working on. So Lucas, what are you working on?

 

subrat:

Thank you.

 

Oh, well, that's a great question because I am just starting a new course today. So I am starting a course on web animations. So if anyone is interested in that, they can go to lucaspaganini.com slash web animations. You can type this all together with a hyphen. I'm gonna accept you either way that you type this URL. Don't worry. And then this course is not ready yet, but if you go to this URL, you will be able to join the waiting list. And I promise that this is going to be a very accessible course. I'm not planning on making it super expensive or anything like that. And it will teach you the fundamentals of web animations. So by the end of this small course, you will be able to craft CSS transitions, animations, and also JavaScript. animations from scratch, confident about what you're doing. You will also be able to use libraries, but you will know how those libraries are being used internally. On top of that, if you just want some free content, I will be posting in the next few weeks some practice examples in my YouTube channel. So there you will be able to see me coding some animations from scratch. So you can just check that out for free. So go to LucasPaganini.com, there you will be able to find a link to join the waiting list of this course and you can also go to my YouTube channel from there and see all those free videos about me coding things from scratch with the pressure of you watching me.

 

Nice. All right, I'm going to throw mine in here real quick. We've talked a bit about architecture and the book we're doing for the Developer Book Club on Top End Devs is Clean Architecture by Robert C. Martin, Uncle Bob. He was on the call last week for our kickoff call for the book club, probably will be there tonight. And so, yeah, go to topendevs.com slash book club if you want to get in on the rest of that. I'm working on getting the video posted from the last one. So you can get caught up, right? You can see what our discussion was and what it was like. But yeah, pretty excited about that. We're gonna be doing clean architecture through the end of January. And then we're looking at a couple of options for the next book. I had a few people ask me to do the Domain Driven Design by Eric Evans. And so I've been reaching out to Eric to see if we can get him in. So yeah, two architecture

 

subrat:

So yeah,

 

books,

 

subrat:

you are

 

I

 

subrat:

just

 

guess.

 

subrat:

a little bit quicker.

 

back

 

subrat:

So we'll

 

to back,

 

subrat:

move back

 

but we'll see

 

subrat:

to

 

how it goes.

 

subrat:

that in a minute. And

 

And then,

 

subrat:

then, yeah, the

 

yeah, just

 

subrat:

other thing

 

the

 

subrat:

is, we've

 

other

 

subrat:

got a lot

 

few things

 

subrat:

of

 

that

 

subrat:

people

 

I've got

 

subrat:

who

 

going on,

 

subrat:

have been

 

I have

 

subrat:

working

 

been

 

subrat:

with

 

doing

 

subrat:

us on this.

 

some

 

subrat:

So we'll take

 

coaching

 

subrat:

a few

 

consulting

 

subrat:

more photos.

 

with

 

subrat:

And

 

some

 

subrat:

then

 

folks

 

subrat:

we'll move

 

who

 

subrat:

on

 

are

 

subrat:

to

 

trying to get their

 

subrat:

the

 

career,

 

subrat:

next one. So we'll

 

you know,

 

subrat:

move on

 

to

 

subrat:

to

 

kind

 

subrat:

the

 

of

 

subrat:

next slide. So

 

slide

 

subrat:

we'll

 

into

 

subrat:

move

 

the next level,

 

subrat:

on to

 

right?

 

subrat:

the next

 

Whether

 

subrat:

one.

 

it's

 

subrat:

So we'll move

 

being

 

subrat:

on

 

in leadership

 

subrat:

to the next one.

 

or becoming a senior developer or things like that, that just feel stuck and, you know. I usually help them get unstuck in that half hour, but then, you know, we have ongoing coaching programs that you can join. So if you go to topbendevs.com slash coaching, you can pick which level you want. One of them is one on one and the other one is a group coaching. If you apply to either one, it doesn't mean that you're locked into that one. You know, we can figure out what's the best fit for you. But yeah, getting some pretty good results for some folks. So that's just another thing that we've got going on. And then finally, I've been putting together a directory of JavaScript related resources. And I'm looking for folks to help contribute to that. And all I'm really looking for is, you know, helping find podcasts, blog posts, books, videos, conferences, conference talks, and just get them, get the information into listings is all, is all I'm looking for, right? You know, nothing fancy. You don't have to be a JavaScript expert. You just have to be able to find it. I don't have time to go and Google all of them and find them all. So if you're interested in doing that, let me know. I can just invite you and give you a Content Manager account on the directory. And then, yeah, I've been working on tweaking the layouts and fixing the data fields and stuff on some of those so that you can find what you're looking for. But yeah. Right now I'm focused on podcasts and conferences, but we are going to add in like YouTube channels and stuff. So, uh, just, just keep an eye out for that. If you want the directory and yeah, feel free to come contribute if you want to be in the directory, because that's the other thing is I'm hoping to have things set up so that if we add something to the directory and you want to come along and claim it, right, cause you're the author or creator, um, that way you can maintain your own listing and. You know, put in what you need to. So that's what I've got, what I'm working on and what people can go participate in. Subra, do you have anything that you're working on that you want to let people know about?

 

subrat:

Yep, like I'm working on currently on little bit on micro front end and try to make a videos on that which is long pending for me and and also also working on started working on deno like it's a then or denotes it depends on who says what so denote land so it's a pretty good good thing to approach like a secure way no one no other packages can hack your code and that's that's the one I'm going on and I'm pretty thrilled by chart GPT I'm just checking it how you can use it to do a better better web it's a pretty good thing.

 

Cool. How about you, Merrick? Anything you're working on that you want people to know about?

 

Yeah, yeah. Well, actually, there are two things. The first is that I realized that I really love mentoring my colleagues and I love to show them some ways as a developer. Also, like you mentioned Charles, that a lot of developers are stucked and they need some push in some direction. And I think that I know what I need to say to someone like... Whether they should be only a senior developer or whether they should strive to something more, to be some manager or something like that. This is really useful. And the second thing is that I'm currently, I'm trying to run my own startup, which is called Sayre and it's startup for organizations. So if you have a gym or a restaurant, you are able to manage your stuff through that app. Your clients can register for an event, or they can, I don't know, book a table in a restaurant or whatever. So it's quite a bigger, big thing. And employees of that company, they have also their part in that app. So, maybe two things.

 

How can people find your startup, Mark?

 

It's not online yet, so it will be possible only from February or March. But I will post it on LinkedIn, definitely.

 

subrat:

or like email Mariko or send him a message.

 

Yeah, yeah, I will

 

Cool.

 

push it to the world next year.

 

subrat:

Yeah

 

Good deal. All right, well now we're gonna do picks and picks are just shout outs about stuff that we like. Let's do it in the same order, Lucas. Do you have some picks?

 

Yes, I do. So in the last episode, I picked the Logitech Brio webcam, which is the one that I'm using right now. I'm going to pick something here that is complementary to that, and it solves all my frustrations with this webcam, which is that I didn't knew how to manually customize things on this webcam. So it was always using the autofocus, the auto... white balance, the auto exposure. And I really hate that because for those of you that are watching us on YouTube or other providers that you can actually see our faces, you will notice that my background is completely black. I'm in my studio, everything here is dark, completely dark, because when I record a video, I want to be able to target the lighting. exactly to my face and I don't want it to bounce on the walls or anything, so everything

 

Mm-hmm.

 

needs to be black. And my camera, my webcam doesn't understand it. So if you point a webcam to me in this environment, no matter how much light I have on my face, the webcam is going to think that it's still pretty dark and it's going to try to increase the exposure. And then I look like Michael Jackson with powder in my face. and it just looks awful. So this is not a good way to start a meeting with a client. And

 

Hehehehe

 

I finally, finally found a way to manually change those settings because Logitech advised the buyers of that camera to install LogiCapture. But this software doesn't allow me to manually customize the exposure. And I've been just trying to deal with making the... auto exposure work for me for a while now. And today, I finally found the perfect software for that. So the software is called LogiTune. So because you are tuning your settings, obviously, how come I never thought about that before? So if you install LogiTune, now you will be able to manually set the settings of your Logitech Brio or any other Logitech webcam that you're using. So for all of you that are using Logitech webcams, highly recommend using LogiTune instead of any other softwares that Logitech provides.

 

Nice. All right, Subrat, what are your picks?

 

subrat:

yeah i think uh the peak i have already said that is the dino land so i was about to pick that one so i think the the new version already came like 1.28.3 so just go and watch that one and try to use because as more people will use and the companies will try to grab that and it is faster like it won't need to install anything on the start of the application it is secure and somehow i i liked it so so i will pick that one

 

Yeah, I've been wanting to play with Dino a little more, but I haven't had time.

 

subrat:

Yeah.

 

I'll go ahead and throw out some picks that I have here. Um, one of the picks that I'm going to toss out there is, um, a game. It's a card game. I can't remember if I've picked it before. I need to just like keep a list so that I know, but, uh, I do pick board games and card games like every week. Um, this one's called antidote and it's a card game and, uh, Effectively what it is is you, it's pretty simple, but you deal out the cards, everybody gets a turn and you can trade cards, you can pass a card to the right, pass a card to the left, or you can make people discard a card. And what you're doing is you have a bunch of antidotes in your hand, and then you've also got a couple of poisons in your hand. And so what you're trying to do is you're trying to at the end of the game, have the highest number in the correct antidote to the poison that everyone's been poisoned with. And you know, you usually have five or six cards in your hand. So, you know, just everybody takes a turn until you're done. And, uh, yeah, when you discard the cards, you discard them face up in front of you, unless it's an X card, which is one of the poisons or a syringe. And you can use the syringes to, uh, steal a card in front of somebody or steal a card out of somebody's hand. And I mean, that's, that's pretty much the whole game. It, you know, obviously there's some thinking and paying attention and, you know, seeing what people are doing. Um, but yeah, it's, it's a, it's a fun game. Takes about a half hour to play it. Um, it's a game that my kids can play with us. Um, board game geek, uh, waits it at 1.62. So like I said, it's a really easy game. But it's a ton of fun and you can play it with up to like six people. Yeah, you can get a group of people together and play it. So I'm going to pick Antidote. I'll put a link in the show notes to that one. A few other picks that I have. So JavaScript Picks is going to be hosted on a system called Brilliant Directories. And I'll put an affiliate link into there, just because, yeah, if you go sign up for it, then you can do it. I am planning on putting up another directory for Angular at some point. I'm kind of fine tuning the process with JavaScript picks first. So once that's done, I already own the domain for Angular picks. So we'll be doing that. I also own the domains for several of the other areas that we cover with their picks. So yeah, keep an eye out for that. And then my wife and I started watching the new Criminal Minds. Um, we've been getting it on Paramount Plus. I don't know if it's on TV, like proper TV or not, but it's on Paramount Plus. And yeah, it has a lot of the same characters in it that were in Criminal Minds, it's Criminal Minds Evolutions, but we've been enjoying that. So I'm going to pick that too. Um. And I think that's it. Merrick, do you have some picks?

 

Yeah, I definitely have one pick. And it's that since the summer, I started to write all the notes down. I'm using Remarkable. It's like ink tablet where you can write your notes. And it has very good format.

 

Mm-hmm.

 

It is like a bit smaller than A4 and it's actually like a physical book because the other e-readers were either too small or too big. And this is exactly as a book, it's very thin. You can write all the notes and when I'm thinking, I just, when I have the pen in my hand, it allows me to think and to organize my ideas. So I think it's much better than before when I was using some to-do apps or something like that. So I definitely recommend it, remarkable.

 

Awesome. All right, well, thanks for coming, Merrick. Good to see you guys, Subrata and Lucas. We're gonna go ahead and wrap this up and until next time, folks, Max out.

 

Thank you, bye.

 

Thank you very much.