Leveraging Nx Caching in Software Development

[00:00 - 00:20] Let's start by creating the NX configuration file at the root level of our application. Now NX calculates the cache based on its inputs and outputs. As long as the inputs and outputs the same, it will be keeping the cache. I will paste a basic configuration here on the top.

[00:21 - 00:47] And what it does here is that we will be defining the cacheable operations. So for example, build and also we can add other cacheable operations like test and linked. But we don 't have the test and link so we'll be just using build here. Now let's run our build command. So the build ran in two seconds. Now the build is cached. Let's try and run that command again.

[00:48 - 01:14] This time the build ran fast. You can see it took 41 milliseconds. And it also says in next read the output from the cache instead of running the command for one out of one tasks. So an excuse that hash to check and invalidate caches. So every time we change something on your project, it will invalidate the cache and run the build again. Let's go and change something in our project.

[01:15 - 01:51] Let's run the command again. So in next identify that there has been a change. So it ran the build again and cache the output. Let's run this again. Now it's cached. Now you may not want some of the changes for certain file types that you make to affect your caching. For example, let's say you're running snapshot tests and you don't want to cache them. And you don't want to snapshot files to invalidate the cache. So in order to do that, we can add target defaults.

[01:52 - 02:18] With target defaults, you can define the targets that you want an extra listen to. We can explicitly specify that certain files we don't want to be addressed by an X.

[02:19 - 02:40] So we would give it a a glob file. Let's use snapshot test for this example.

[02:41 - 03:43] So here, build will ignore any snapshot files. Now if you want this same glob to be applied for other targets like lint or testing, we can create another section called name inputs. And that will be a name section where you can reuse the attribute name instead of writing the same glob again and again. So for example, if you wanted to add lint and you want lint to follow the same glob as build, if you're writing the same glob, we can specify a name inside the named input section.

[03:44 - 04:28] And here we can give it a name, something like no snapshot. And we can copy over the glob and then instead of this, we can replace that with no snapshots. And same goes here with for lint.

[04:29 - 05:16] And now we can also make sure that any dependent packages follow the same instruction by adding till the and no snapshots here. Share UI has been used by the front end app, so anything that's dependent on that will follow the same. So in this lesson, we learned about how Enix cache works by intelligently caching computation results. We also looked into bringing the caching capabilities into our app by configuring our mono repo to cache builds to save time.

[05:17 - 05:21] And that concludes the caching module. See you in the next one.