Nx & Monorepo Setup

[00:00:00]
>> What annex does, is it separates your apps from your libs. And so think of your components or something that a user sees or interacts with the surface area of something to be consumed that goes into. The app. So in the dashboard, if you did nccih new and you generated an application, it would be here.

[00:00:31]
And so classic component. You got your CSS, I'm just gonna delete this. Now we don't need this Rashad. I'll leave it in there for a moment. But it generates the spec, the component, and the module and so on are coming from the assumption that we are at least somewhat familiar with Angular.

[00:00:52]
I'm not going to explain which everything here does. But what I do want to point out is that we have an app and then in parallel to that We have our end to end test. And so not only do you get a working angular application with all of this extra stuff, you get Cypress baked into and end to end or baked into this monorepo, which is really, really Important.

[00:01:24]
I know for a fact that the angular team is evaluating their intent options. It is my desire not to be disparaging with anybody that was involved with protractor, but protractor is, I believe in a severe disadvantage because it's based on selenium. Cypress on the other hand, whereas Selenium is kind of the NASA in automated end to end test, Cypress would be the SpaceX.

[00:01:52]
And so the fact that you get a workspace with Jest and Cypress baked right in is really, really cool. And so This is where your end to end tests go for this application. And then, because we generated an API, then we have our nest application right here. And then we have our libs which is where our shareable code will go.

[00:02:23]
And so this next step is let's start to generate some code. And let's see how this is built out. Before I do that, does anybody have any questions about what I've said so far?
>> What is the difference between using the Angular COI and then just using an X and also if an X is something similar to next js or next.

[00:02:51]
>> Under the hood, and x uses the angular COI but for the nest portion It uses the NES COI, and for the React portion, it uses another COI. And so think of NX is kind of a layer on top of all of the COIs, which is great because then you get the best of everything.

[00:03:17]
And so, inside of the apps folder here This annex is using the angular CLR to generate this, or at least the dashboard portion. So if you went did nccih new, this is what you would get. The difference is is that NX is essentially asserting some opinions on the file structure so that you can have More than one application.

[00:03:44]
And then more importantly, is that you can share your code across multiple applications. And so that's the difference is that NX is essentially a layer on top of the angular COI and then NX also uses next or. React or whatever it is that you wanna use on top of that.

[00:04:07]
So it's a way for you to have more than one project or application in a single place, which, again, I think it makes sense in terms of cohesion. Like if I have an API that I'm using in a front end application, like I really want those to be together.

[00:04:24]
And I want to be able to kind of control the data model in the versioning of the different things around that. Just to summarize is when does it not make sense to use a monorepo? I would say there are cases to be made, where it doesn't make sense.

[00:04:41]
And I think one
>> Is, you can kind of tip over from kind of cohesion into coupling. So for instance, my threshold on a monorepo is group a technology stack within the model repo, but then if you have a totally separate unrelated technology stack, Create a new monorepo.

[00:05:06]
And so where I differ, I believe then, let's say Google, where they have all of their entire code base in a single mono repo Now, can you imagine, you know, if you showed up and you're like, I need to build this thing and I've got to download all the code

[00:05:26]
>> And so there is some overhead, to where the overhead for the monorepo, no longer makes sense. And so for me my threshold is I organize essentially by a technology stack. That you might have an API that has a couple Front End web applications that consume it. And I would put that together.

[00:05:47]
But if I had like, let's say like an IOS application that's a completely unrelated set of technology. It's totally unrelated. So let's say It has nothing to do with what I'm working on. I wouldn't force that into that monorepo because that wouldn't make sense. And so I think where it does get a little tricky, is around, it's great for consumption.

[00:06:10]
Like if I'm working in this paid, you know, on this code over here, and I work want to jump over to this code, it's amazing. But, when you start to deploy, and one of the big things that I've ran into, is that If you're building Docker images For your application, and you have a nest app and an Angular app, you do not want your Angular dependencies to go into your next Docker image.

[00:06:41]
And that's where in terms of actually building it back out. There's some techniques around that to do that. But, you know, it's really good for consumption. But as you start to build it back out, you have to be mindful of that as well. And so the build like the build complexity goes up, but your developer ergonomics are a lot better.