Nx vs Angular CLI - The Showdown

so this is gonna be a bit of a longer video and mostly interesting to you if you're interested in the angular space or angular ecosystem in general or if you're an angular developer of course now we can still stick around if you're not because a lot of the tech that I'm gonna show today is very easily translatable to other Technologies as well even though we're gonna show it today on an angular project so what I want to do is kind of compare the nxcli and the angular CLI specifically for angular development and I want to show you a bit like how similar they are so the similarities between the two which makes it very easy for an angular developer today to switch to an X but then I also want to show you how additional power comes with an X to your angular workspace so some additional features that NX provides that are super valuable when it comes to angular development and also it opens up a lot of more possibilities as you keep growing your anger application ready let's check it out so first of all let's have a look at how we can create a new workspace so I have here on the right hand side the angular CLI in just a folder and here we have a folder specifically where we're gonna set up our NX CLI based project so let's start with the angular CLI and I'm using npx because I don't have it installed globally so I just invoke here that add angular CLI new and the name of the project myng app and so this will now install latest version of the angular CLI or basically pull it down and immediately invoke the new functionality here we're just gonna scaffold new project for me and so here we get already a couple of questions so do we want to have angle routing show why not uh different quests about the style sheet now I'm gonna keep it as simple as possible here and then you can see a new application here gets generated for us so let's switch over to NX and have a look what the setup process looks like there so again I invoke npx then I invoke the create NX workspace command here I usually append at latest to make sure I don't get a locally cached version and then I give it a name of my application again so my NG app now here I could already influence that I want to create an angular application by passing a specific preset I could say angular Standalone or angular mon repo depending on where I want to start now I want to start with a standalone setup which means this is a single produce workspace that is exactly the same structure as the angular CLI now if I don't know this preset I can also navigate through by basically just invoking here the CLI which will then ask me a couple of questions so it asked me which stack do I want to use and there we have angular as one of the different options so go with angular and then here again I go with Standalone now instead I'm not to be confused with the angular Standalone API but raw this creates a single project workspace so exactly what you would have for the angular client so it makes it very easy to compare here again for the stylesheet format I just want to keep it simple now what an accent audition asks me compared to the angular CLI is like which test Runner do I want to use for end-to-end testing or more functional testing and so here we have cybers and playwright let me just go with Cyprus for now it also asks me about whether I want to use the Standalone components API from angular so let's go with that let's get all the new goodies and do I want to add routing yeah for sure I do I want to add distributed caching to make my CI faster yeah sure and I'm gonna go into more detail here so for now let's not enable this such that we can then add it in later so I opened up both of them in vs code where here the left hand side is the NX workspace and the right hand side here is angular silai workspace so let's have a look at the structural differences let's start with the source folder first of all and you can already see these are almost perfectly identical there's one test setup that differs here we will in a second see why but other than that we have the exact same setup we have here the angular application setup like different angle modules we don't have that model here because I did set up the NX workspace to use the Standalone API from angular so we just have Standalone components here compared to Angie modules we would have done the same thing also for angular CLI I just didn't provide the proper flag there and since NX asked me here I just immediately jumped into the Standalone API setups if you go further down same thing right you have the main entry point which only differs here because we have chosen here the Standalone API versus just a classic setup of using Android modules so how do we build this application well for the angles CLI you just run MPX and G build and this now builds your application directly now for NX we can do exactly the same the only difference is we don't invoke NG but rather NX and then build and it will also run application build so how does this work well for the angular silai we usually have the angularjson which defines a build Target in here so you can see here there's like the project section my NG app which has a build Target which uses here the angular DAV kit build angular and for NX we have a similar situation where we have a produce Json file rather than an angular Json but it has this exact same structure or very similar structure we have here for this project a build Target defined which also here happens to use the exact same angular DAV kit Builder so we use the same underlying mechanism to build our angle application now why do we have a produce Json here the reason is that NX chooses to have one such configuration per project while the angular CLI approach is to have a single angular Json with one project node where all the products live in here now in this case we just have one project so the angular CLI node will just have that one product inside and similarly for an an X workspace we just have one project Json at the very root but we will later see that once we convert friends to a mono repo or have local libraries we will have multiple of these projects Json files and the nice thing there is that every project will have its own project Json file with its own configuration that just applies to that single project compared to having one single angularjson file at the root which potentially contains the configuration of all the different projects that you have in your workspace now this is a very big point in terms of scalability as you have more team members working on a potentially larger workspace also just for the purpose of avoiding merge conflicts so I had to build part here we are exactly the same the only difference that we can already highlight is that what happens if I run the NG build again here on the project it will just go and build it again now angular has some sort of caching mechanism underneath which it here stores in this angular version here where it has some angular webpack and Bobble cache that can be reused partially to rebuild the project which speeds it up a bit if we do the same here for the annex workspace and run NX build you can see it's immediate like it tooks only 34 milliseconds and so what the NXT light does here is it is able to Cache the entire computation because we didn't really change any configuration or any source files so it just directly Returns the output here again as well as the disc folder output that got generated before and it also leverages the angular CLI based cache obviously because if we use the same mechanism to build it underneath so let's explore four further things what about testing now if we run tests here we just run NG test again and this will here pre-compile our application and in the current configuration here the angular cell I will use Karma to set up the test so what happens behind the scenes is a browser window opens comma tests run and they spit out here the result three success now this one has long been launched in watchmore by default so let me just close this here in this terminal if we go to the annex project we can just run NX test very similar again and this will use just behind the scenes to run our tests locally here you can already see Justice faster here than the actual Karma output and to be noted here is that the angular CLI is currently looking into experimental Support also for jest so this might be coming in the future but at the time of this recording of the video it's not there yet clearly if you prefer to use Karm on your product for whatever reason you can totally do so even for NX you can just provide the recording test Runner flag to choose comma instead of just which is the default in an xcli setup so next thing linting very similar again let me run here NG lint now here you can see the angles like right now doesn't ship with a default linting setup out of the box so whenever you run lint the first time it will ask you to pre-configure it and so obviously we want to install here eslint and so this is now going to install it locally it also acts about adding this angular CLI the angular eslint schematic project which helps like configure the linking specifically for this angular product and so let's install these packages and so here what happens is that it will also add now a link Target here to our project such that we can now invoke it so you can see here is the test and now also the lint Target so we can just here invoke and Andy lint and now the linking will obviously happen and the lending will pass for the project here on the next side an X already ships with eslint configured so it used the exact same mechanism for the learning process and so you can see it already works out of the box again here if we run caching obviously hits if we run here we would relent application so let's have a look at end-trend testing Now Android testing can have different meanings actually depending on how you interpret it like Android testing can be going really end to end so from your application invoking a rest API whatever kind of technology used there hitting the database returning that and visualizing it in the user interface on the front end so this would be a real full round trip that one involves quite some setup to make sure these are not brittle on the other side end-to-end testing can also happen locally in your application meaning you want to end Trend test a full user flow where you launch application a browser you click a button add some text to the input and actually visualize whether that is being processed properly locally why you might still mock out the actual invocation of the end point so a rest API for instance so this makes these tests much more stable on the other side and really useful because you cover a lot of different aspects now if I run end-to-end tests here in the angular CLI what will happen is a similar situation to the linting before previously angular silage ship with protractor which kind of is a bit of an old technology was really useful once in a while but now it kind of got replaced and deprecated so now the angular CLI doesn't ship with that out of the box but it rather gives you the opportunity to configure one of the following here so Cypress night watch or pure web driver i o now I can go with Cyprus here for now but you can obviously choose whatever is works best for you again here the schematic wants to be installed from Cyprus that is pre-configuring our application with an end-to-end test and then we get a couple of different questions here for setting up Cypress then Trend test Target as well as component testing so once we've done that we now get a new end-trend Target here in our application but we also get here a Cypress configuration with our end-to-end test in here so to launch this now here on the end goer CLI side we can now actually run ngn Trend and the second time around now it already has Cypress installed so it will launch now the devser in watch mode it will open up Cyprus behind the scenes and so you can choose your browser and start start your end-to-end test which will then run basically on your project so on the NX side here we have a slightly different situation where we already have an end-to-end project now we have chosen to set this up with Cypress but you could also use playwright when you set up this product initially so this is already pre-configured to work with our application the difference is when we invoke it we invoke this with end Trend and this end-to-end target exists on and Trend project rather than our application because it's part of launching this project here and so the project is called end-to-end unfortunately and so we have an NX end-to-end end-to-end that we can run so if I invoke this this is not configured to be launched in watchmore by default so it's much more handy because you now just run it in your local cons console in a terminal output without actually opening up the Cypress water and ID you can obviously do so by just passing the watch dash dash watch flag and then you have the exact same experience which usually very handy for debugging purposes all right so until now both of them have been kind of the same so the NX CLI for instance comes right pre-configured with the blinting and end-to-end testing and it also uses just for testing while the angular CLI uses comma right now but just seems to be coming so the experience is pretty much similar you run and you build on the one hand side NX build on your other hand the project configuration is also almost the same so there's an angular CLI on the one hand side project Json on the other side both of them use a concept of an underlying package so-called Builder or executor on the other hand side of abstracting away some of the lower level details so this is much easier for you to configure a new build there's some key difference already in the sense that an x-ray comes with more stuff so it already also has a pretty Conflict for you to make sure your code formatting Works nicely and you don't have to argue about tabs and spaces but it's also a key differentiator in the sense of having a caching mechanism of your computation so as you have seen the linting and testing and building and potentially also custom commands that you add can be cached which has a significant impact on the speed overall but there's much more and this is where we're going from now on where NX adds things on top where the anger still doesn't have it just yet so going back to our workspace let me hear close the sign of the anger sea lion keep focusing here mostly on the nxclr workspace so one thing I want to explore a bit is how NX adds more generators to your workspace generators are schematics angular schematics in the NX language and they allow you to scaffold code or configuration or integrate with new tooling and some of them are really handy to invoke these generators we do it exactly the same way as you would do in angular world so you would do NG generate for an angular CLI but you can just use NX generate for the NX workspace and then you give it again the package that you want to use for invoking the generator so in this case we can use NX angular and then we have here setup Tailwind for instance that allows us to configure Tailwind for our project so we can invoke it it will ask me where to configure the Tailwind setup let's say my NG app and now it will add the tearing configuration to the project and make sure it sets it up in a way that it works for us so you can see here friends we get Tailwind config here set up and it also did all the adjustments that were needed here in the package.json and in the style CSS to make sure this works similar things are for storybooks so what we could do is generate a storybook setup for our application here so similar we can just run NX generate again NX angular and in this case we call it storybook configuration and I'm using the dry run to not effectively run it but just show you what it would look like and so here again we choose the project and we get a bunch of different questions asked with which the NX generator here does for us for instance do you want to have silveric interaction tests which is a new way of automated testing provided by storybook and so this would be set up for us do you want to have stories generated already for the existing components so you can see a lot of work is being taken away from you by exactly having such setup and additional generators so how do you find these though if you don't know which ones exist and where to use them and how to use them well one obvious approach is to go to annex.dev docs into the documentation but what the NX team also did is create a dedicated extension for vs code and IntelliJ webstorm that helps you navigate an NX workspace so this extension is called NX console and if you open it up it provides a set of facilities to actually help you kind of run prod run tasks run the build or also in our case what we are most interested in generating new stuff as if you click that generate menu then based on the plugins that you have already installed so these packages like NX angular or also the angular schematics itself it finds them and you can now search them and run these generators for instance for Cyprus we can just search cypress and it will list here the Cypress configuration for component tests that we can generate which we have already done in this workspace similarly also the ones that we have seen for storybook or just for creating new components where we can use here the NX angular generator that can help you set up a new component here or even a component test for Cypress now once you click these the generator opens up in a form where you can now fill out the details and then click generate and directly have that code generated you can always copy the command so for further use for instance if you have to do this multiple times and just change couple of flags it's very handy to copy the underlying generator command such as you can then just paste it in your terminal and get going much more quickly so as you listen along you hear me talk about generators instead of schematics or project Json instead of angularjson or executor instead of Builder so you might be wondering can I not run them like can I not run an angular schematic or an angular builder in NX well incredible we have seen already works so we actually referenced here in our config if we go back to our project Json you can see here in the executor we actually leverage an angular Builder it comes from the angular dev kit package but underneath NX actually has its own dev kit which is optimized in the sense of being able to work much more easily with it having promises support out of the box or being that the native primitive there it also however has very similar Concepts than the Android dev kit so there is a virtual tree it allows for dry runs and much more and in order to make sure that these two things are compatible there's a compatibility layer so very similar as we here are able to run the executor we can also run angular schematics in fact if I search here for component you can see the add angular schematics component and if I here give it a name like hello worlds and the project here will be myng app let me copy here the command then you will see that I can run this through the NX CLI so actually you can just run Nix generate and then provide whatever angular schematic I want to pass through an x and x automatically detects that and actually runs it through this compatibility layer to make sure it still works so even though the angular schematic here expects for instance just a single angular Json and in an Annex workspace you might have a project Json this compatibility layer will make sure to translate that properly but there is even more than just generators for instance a common thing that you often need here in your Builder configuration is the ability to pass a custom webpack config and there are custom packages out there custom angular Builder package that allow you to do that in NX we have a bunch of these automations already built in so instead of having the angular dev kit Builder here you can actually also use the add NX angular webpack browser package and this has further properties it has the same properties as the angular Builder itself expects but also morph if you go to the documentation to packages angular and then we scroll to the executors we can search for this webpack browser Builder and this has the ability for instance to pass directly in that custom webpack config a pass to a custom WebEx config that it then extends with the one that is already being provided by the underlying buildered angular Builder so there's a lot of these utilities be it generators to integrate Tailwind or storybook or having a custom executor that allows you to customize your webpack config these are just examples or some of the examples that NX has built in because NX team has found it extremely valuable when it comes to working with angular code bases in particular larger code bases but what about the NG update command is kind of famous for having introduced that command to allow you to automatically update your angular CLI your configuration but also the actual framework of angular and source code to the latest version and they do that by allowing you to run NG update which then will trigger a series of code modification scripts that adjust your configuration adjust your source code if needed obviously update your package.json and PM packages to the latest version and this is crucial if you want to have your people and your developers be up to date with the latest version such that they get the latest security patches but it allows also the team itself like the angular team at this point to iterate more quickly because they make sure that people can keep up with them now NX has exactly the same concept it is called NX migrate so let me show it to you quickly on a project here which has on purpose an older version of an X here and also of angular so we have here a workspace that uses angular 15.2 and it also uses the older nx16 version while we're now already at 16.7 now to update this workspace instead of running NG update because we don't really have NG installed here but rather we use NX we run MPX NX migrate latest meaning we want to migrate to the latest version NX is now going to analyze your workspace to install packages in the package.json and it will build up a list of scripts to be run the main difference between the NX migrate command and the NG update command is that the NX minor command comes in multiple steps so it will first show you what will need to be done you can then intervene in a sense of adjusted to your workspace and this is crucial if you have a large workspace and then you can adjust it and then actually run it to apply it to your workspace underneath this also allows you to keep the script and run it multiple times if needed for instance on outdated PRS that have been forked off the main branch before the update has happened and landed in Main so as you can see at the end of this First Command what we get is a package.json app being updated and a migrations Json being generated so the package Json is similar to what you would expect in the sense of having the new updated versions in it both for angular itself but also for NX and related Technologies like eslint and the typescript parse or in this case also jest now the migrations Json here has been placed at the root of our workspace and this contains a series of migration scripts the angular Clan is does exactly the same thing it just doesn't expose it to you but rather it just runs it right away now this allows you to look into it inspect what is being done by reading your description or even looking at actual implementation and then you can run it on the workspace to run it just follow the instructions here which means running here run migrations this will now pick up this migration file and run all these scripts here on this workspace so after migration has run we can see the different changes that have been applied and this specific run some changes have been added here to the main TS so some code logic has been extracted into new app config yes for instance and this works pretty well if you look here at this burst diagram which shows the distribution of the NX installations you can see that the majority of people are already on latest two versions of NX on the latest two majors and this is thanks to such an upgrade mechanism which allows to easily upgrade to the latest version so NX does very similar to the angular CLI first of all update itself but then also update related Technologies which include Cyprus storybook just eslint and potentially orders that you might be using and obviously also runs the underlining angular upgrades if they are applicable now if you're wondering which version of an X you need to use for which version of anger and NX is actually compatible with all the latest LTS versions so meaning you can use the latest version of NX but still have an older version of angular going back to version 14 at the time of this recording one week differentiator between NX and angry CLI is that NX allows to start small so in a very similar fashion as the angular CLI with a single project workspace but then it helps you grow as your needs grow so as your workspace gets bigger as you may be on board multiple teams or more team members you will need different mechanisms to make sure your code base keeps growing and keeps scaling and so let's have a look at some of these mechanisms so first of all when we have a bigger application usually what happens is that you have some local folders in here which manage your domain let's say you have a folder for products or the product list for orders authentication so maybe shared utilities or UI components and usually group them within this Source folder now this is a very lightweight way of grouping these things and separating these things but at the same time it is very easy to mess it up by having a lot of inner dependencies between them so one thing that NX allows you to do in such a situation is generate local libraries now next being also a tool from mono repos the concept of libraries is already built in but we can also apply this to such a single project workspace as we have in this case so you can just generate such a local library using the NX angular Library generator and let's call this products and I want to generate this into a directory called features and I also want to pass Standalone in this way we use the angular Standalone API rather than creating entry modules and so now you can see we get this features folder and our products library in there let's generate a new one also for orders and potentially an auto one for our UI components and the director there might be something like features shared because UI components would probably be shared across all these different areas so now you can see how our workspace shapes each of these is a library in the sense that it is consistent it has an entry point it has inside components this entry point allows you furthermore to change the visibility so only what is being exported from this entry point can also be used outside so this gives you another visibility mechanism in your workspace and all of these libraries as we generate them are being directly referenced down here in our typescript based config via this typescript pass mapping aliases now these allow you to import them very easily into our application so let's go to our app component for instance and so we can just import here our features orders component so by segmenting your code base in this way it allows you to scale it much more easily because first of all you can assign team members or entire teams to a subset of these libraries so they can work independently on them and we can even test them independently so each of these projects is literally a fully worthy project in the angular workspace here powered by an X and so to run them each of them has a project Json with according targets like testing linting and if they're buildable even a build Target and so the name here for instance feature orders and so to test just this specific Library I can just run Annex test very similarly as we did before Ford application but now appending here the name of this project and so this would now run the test for this project as you can see if I run it again it hits directly the cache so all these things also apply for these sub products or local libraries that we have you can then also visualize these libraries by using NX graph so if you go to the browser and then open up here the local browsing of the next graph you can see the different nodes of our workspace these are literally the products that we have right now you can also see that these are not connected to anything while the features orders is something that we imported into my app and so therefore it is connected to Via that important app component and these features are really helpful for debugging a workspace and as it grows also to inspect it and see how the different feature errors are connected to each other so what you can also do is to have some sort of boundaries around these features because again as as you have multiple team members working on a project what you might want to do is for instance impose rules where someone like working in the features UI components should not be able to import from something like features products or features orders but they should be able to do that vice versa because clearly UI components are shared across domain areas while a component that lives within the product area shouldn't probably be used here in the UI components which is a more smaller fine-grained UI component living there now if you want to learn more about this go to our NX docs and there is a chapter in the core features about model boundaries and how these can be applied to your code base and how you can leverage them to have a more maintainable code base in the long run as your code base grows and yes you start moderizing it more and more with such local libraries you might reach the point where you actually might want to even have another application whether that's another angular application or even an auto react application or even just a mobile application that lives alongside your main desktop product now given that NX is a mono repo tool in the end as well it allows you to easily transform your existing single product workspace into a monitorable workspace now while you could do this manually we have created a generator to do that and help you with it so you can just run NX generate convert to monoree Pro and what this will do now is convert this existing workspace into a monitorable workspace as you can see now we have an app apps folder which has still our antennas in it it has our main application which has been transferred into this subfolder here and we still have our libraries that live inside there all the rest of the application Behavior remains exactly the same so we can still go ahead and say MPX NX build the only difference now is that we need to provide it the name of the application because we could potentially have multiple of them and clearly you can now also add a second application so we can just go here and run a generator application so we choose here the application from the NX angular package my second app and then we choose different options as we have done before like whether we want to have Standalone whether we want to have routing and then we just generate our second application into our workspace and having a monitorable workspace we could now easily import the libraries that are still exported here via the TS config based Json file into our second application as well so some of these libraries might actually be shareable or might just need little retouching or refactoring to be made shareable between multiple applications and not just a single one while other libraries might still remain for just a single application which is totally fine and from here we have even more advanced feature capabilities for instance to add modiferation because one thing that we did here is like having our application and split up our libraries and we can make those libraries individually buildable such that we also benefit from NX caching or we could have modiferation help us split up even our application build itself into smaller pieces so that we have like a small section of our application which is just for the orders part those just for the products part and so on in the description you will find a video that goes step by step into using an existing angular application and leveraging modiferation to split it up but the process basically is again leveraging some of the generators so I can go here and say NX generate and then write modifiation and then choose here the setup modification for our second application for my second app I can choose here duplication then fine tune a couple of different things if I want to so this will be our host you could even have the routing configuration set up for you and once you hit generate it will now add a module Federation configuration into our existing angular application so you can see here the different setup about the name and there are no remotes just yet the webpack config that is needed notice the exact configuration here for webpack is in the annex angular package but you can obviously take this and further customize it to your needs and there is the corresponding production one as well and as a second step we could now go ahead and generate remotes so we could here say remote call this products remote we can choose the host application which in this case my second application and then generate this new remote so you now see we get a product remote similar to the other applications you also get an end-trend test for it so we could test this specific remote individually and also our my second application here got updated by referencing property this remote which then gets read by the corresponding configuration to set it up and wire it up properly so you can see how these generators can help you get up to speed really easily and then you can dig in and actually configure and tailor it to your own needs much more so all these features are here to make you more productive but sometimes you even need to further customize it to your organizational situation because maybe you have a specific way of how you set up your anger app or angular libraries so you might want to customize that even more now if you go to the annex docs there is an entire section about extending NX for your own needs and there is actually a big Community behind that creates such plugins that allow allow you to integrate some of the tooling out there in third-party tools into NX workspaces to make it working with them even more pleasant but you could actually go ahead and create your own local plugin meaning applying it just lives in your NX workspace to automate a specific part of it like creating a new library in a particular way so check out the link in the description for a video that walks you step by step through creating such a plugin to automate the generation of new packages in an Linux workspace now we have seen a ton of different features that NX adds on top of the angular CLI without even speaking about speed and CI so one of the goals that anger Sila also had is integrate bazel into angular applications with the main purpose of speeding up your angular compilation but also as your workspace grows and your angular applications got bigger to speed up your CI now Basel is an excellent system and it's the open source variant of the Google internal Blaze tool which helps manage their gigantic monorepo however on the other hand basil is really configuration heavy and it's really hard to actually adjust specifically for node.js based tooling now NX tries to aim for a similar thing but in a more ergonomic way so we have already seen the NX caching that takes place so if you open up the NX Json at the root of your workspace there will be a section about caching and here you can see the cachable operations that have been defined that you could potentially adjust based on what targets you have or add even further ones and what this means is for instance that if we run multiple tasks in our workspace let's say we want to run the tests and the Lin targets for all of our projects and X will first of all paralyze them in the most efficient way but at the same time what this also means is that if we rerun for instance all these commands it will only take 170 milliseconds and this is thanks to NX computation caching mechanism so what this does is basically have a different set of inputs obviously the source code environment variables and some other configuration files and then every time you run a task on your project or multiple projects it will compute a hash and store the results locally both the console log output but also potentially artifacts that are being produced for instance for build it will store the JavaScript artifacts now this cash just lists locally in our node modes folder by default so if you go in here in the cache you will see an NX cache and if we remove this cache and rerun the operation again you will see it is not being cached but rather recomputed now obviously on CI you want to have a persistent cache such that in between PR runs if some other person or some other PR has already computed that same result rpr would be sped up speed up by just copying over that cache into our own CI run and there will be much much faster now you can do this via NX Cloud to connect you just run NX connect and this will now ask you whether you want to enable distributed caching with RNs Cloud on CI and so once you enable this and X is going to install the NX Cloud package and it also flips our runner here in the NX Json to use the NX Cloud Runner if we now rerun the same computation for instance it will be computed the first time around because we changed some configuration in this case our Cloud Runner but in this case if I remove again the logs locally from our cache and rerun the computation again it is still super fast because it got pulled down from the remote cache of NX cloud in this case you can even open up NS Cloud directly to get an insight into the run to open up the different locks that have been produced by these runs that are searchable and filterable for instance based on failures that might have happened which is extremely useful if you have a lot of different products that run as part of the same CI run so you don't have to go through clutter CI logs and filter out faders that might have happened in some linting or testing process you can also claim your NS Cloud workspace to get more insights into run statistics like how much cash do you actually save as a whole per week per day across the different runs now aside from the distributed caching you can also get the ability to distribute tasks across multiple machines so for instance if we go to our workspace we can generate a new CI setup for for instance GitHub in this case there are other options available as well and what this does is generate a new API configuration for GitHub actions that is able to use an NX Cloud Runner and distribute tasks in this case here on multiple agents so since NX has this notion of the graph behind the scenes is able to do such distribution across machines in the most optimal way because it knows how the different tasks are being related and that allows it to distribute these tasks on machines such that no task is blocking another one it can also do this using historical data as well so if there's long running tasks it will make sure those get on a separate machine such that they don't block further tasks to be scattered on that machine with over gold based at the entire running time of the CI is as short as possible and you don't have agents for instance that are waiting because other agents take long having taken on long-running tasks on their machine alright we made it through so I hope I could give you enough detail to be able to evaluate an X for your next angle project and also understand what the differences are but also very similarities are so as we have seen in this very beginning of the video the NXT line angry CLR really similar also because the nxcli has grown out of an angular CLI extension basically to become its own CLI ultimately and so that's where you see some of the similarities still such as the structure of the project Json compared to the angularjson and the generators and schematics and executors and Builders they are very similar Concepts so for an angular developer it's really easy to transition also if you start from a standalone workspace or a single project NX workspace the setup is really similar to what angular CLI provides with the difference that the nxcli already gives you some of the entrant testing and linting and also pretty configuration built in versus the angular CLI opting for an approach where you have to install it once you need it we've also seen additional generators that are present there in the nxcli that you don't have right now in the angular CLI unless you use third-party installation third-party schematics and then we have seen how NX is really made for growing as your workspace grows with the ability to create a structure look of local libraries to modernize your code base but also with the ability to actually then transition to a monitor if you really need to have a monitor at some point so it gives you a lot of this freedom to grow with your workspace as you add more team members as your application becomes bigger so there's hardly a roadblock where at some point point you cannot grow anymore because the tooling is stopping you and that's exactly the goal after NX team overall there's more than 25 people working on NX fully focused on making you more productive with various Technologies and that scaling doesn't end on the actual code base but as we have seen also in CI by a mechanism such as remote caching Distributing tasks across different machines and there's actually much much more coming so hope this kind of convinced you to look into an X try it out let me know in the comments if you have further questions or for areas that you want to explore make sure you check out the description to Links of other videos that could go more into depth of some of the concepts that we have just touched briefly during this overview video today alright folks thanks for watching and I'll see you in the next one

Channel: Nx - Smart Monorepos - Fast CI

Views: 6,008

Keywords:

Id: bwPkz4MrPDI

Length: 43min 2sec (2582 seconds)

Published: Thu Sep 14 2023