Speed up with Nx computation Caching

Instructor: [0:00] While you might use Nx on small repositories as well in small project, because interior benefit a lot from the whole generators that basically generate the applications libraries for you that gives you automated and trend tests with Cypress and a lot of other stuff.

[0:17] Nx shines when it comes to scale your monorepo to the masses. Right now if you look at our dependency graph, we have few nodes in there, but it's still not very huge.

[0:29] Now, as you can imagine, we cannot build all of this every time we are on CIO, every time want to merge in some small change into our main repository. As we have seen, there is something that is called yarn nx affected commands, so we can do something like effective test with respect to a base, which is usually master, but it could be any other branch or comment.

[0:53] Nx automatically computes what has been touched and only executes the tests or build or whatever you're currently doing against those changes.

[1:02] That allows you to cut off a lot of this entire graph here, but Nx has even more on top of that. What Nx has is a so-called computation cache. Let me explain, if I execute nx affected --all, this is just the means to run basically the test for all of our projects.

[1:20] Now, obviously, that's not something you want to do, especially in a large monary, but because this could take hours. Now, in our specific situation, it's pretty fast, it's around 10 seconds. You can see it run through all of the projects.

[1:34] Now, what happens is if I re-execute the same command, you can see it's immediate, like it took not even a second, and it still outputs off the content we have seen before. You see all the tests that pass and get a complete report from Jest.

[1:51] The only thing that's different is that you can see now here at the very bottom there's a note saying that Nx read the output from a cache, instead of running all of the six projects. This is the so-called cache that locally analyzed your project, hashes the files, and if nothing changed, actually just replaces the output it has garnered from the previous run.

[2:11] For instance, if we go to our store detail game component here and we make a small change, let's again say a local console log statement here, we rerun again. You can see here Nx read our cache instead of running the command for four out of six projects.

[2:33] In the actual process it had to re-execute, because they have dependencies between each other and since we changed the library, also the application had to be tested again.

[2:41] Now, this local output cache exists in the node modules folder. For instance, if I do an rm -rf node_modules.cache, I actually delete the cache that exists locally, and if I rerun the project again you'll see that it runs through all of them.

[3:04] There's also an option called skip Nx cache, which will allow you to skip the cache for whatever reason. Now, while this cache is just locally, you're the only one to benefit. Here, you could also opt in to the commercial plug-in, which is nx.app to basically have that cache shared among your team members.

[3:23] Now, by default, every project gets five hours for free. If I go, for instance, on the nx.json file, you can see that here we have this task runner, but if you opt into Nx Cloud, you get a different task runner, which is basically this one here.

[3:37] In this case, even if I run the project again, you see now it re-computes and runs all of the projects. If I remove the cache again, locally I have no cache, this could be a situation wherein some of my coworkers post on repository remotely and runs it for the first time, it will still benefit from the cache.

[3:59] As you can see, it immediately outputs. You can see there's an order note at the very bottom is that Nx Cloud got the result from the Cloud storage, not from the local cache. Once that has been retrieved, it will just use the local cache again and not do any kind of unnecessary cause to the Cloud.

[4:15] In our specific example, I have used a test target. The interesting part here is that we could really use any of these targets here. We could actually also use the affected link or run all of the builds of our entire workspace, and we would only build those that haven't been built already.