Dependency graph - what is it?

[00:00 - 00:21] When you decompose your application into libraries, NX is tracking your dependencies, which means that NX knows exactly which libraries will be used to build your apps. It's crucial because as you remember, NX is building only necessary parts of your application, so if something has not changed, NX will not build it from the scratch.

[00:22 - 00:27] So to know it, NX has to track dependencies. And as I said, it's a crucial part of NX.

[00:28 - 00:35] So let's consider a simple monorepo. We have one app called app, and we have three libraries.

[00:36 - 00:42] We have forms library, buttons library, and inputs library. And our forms library depends on inputs library.

[00:43 - 00:52] And the whole app depends on forms library and buttons library. And if you imagine these connections, it looks like a graph, right?

[00:53 - 01:04] Under the hood, NX is building the dependency graph of your monorepo. Unfortunately for us, if we want to check how our application is built, we don't need to draw graph by hand.

[01:05 - 01:14] NX has a building command to print the graph, so we can check how our application looks like. Let's call yarn, run, NX, graph.

[01:15 - 01:25] And basically that's it. After a second, you can access localhost 4211/projects to check how your graph looks like.

[01:26 - 01:36] Let me switch to the browser. So not only we will have a graph, we have a whole application to manipulate it, to hide some parts that are not interesting at the moment.

[01:37 - 01:43] By default, graph is empty. We have to click on libraries, on the applications that are important for us.

[01:44 - 01:51] So for now, let's click on show all projects. And this is how our conference monorepo application looks like.

[01:52 - 02:05] So we have our room front-end application, with end-to-end tests here. We can check all the libraries that are connected to our room front-end application, we have our admin front-end application, and of course back-end.

[02:06 - 02:12] All of them with end-to-end tests. And for example, I can check, okay, so meetings is depending on DTOs.

[02:13 - 02:19] Or for example, room list is depending on cart and room background. This is very handy, right?

[02:20 - 02:24] So let's say that I want to hide some things that are not important at the moment. For example, end-to-end tests.

[02:25 - 02:33] I can scroll to e2e projects, and then click on the i icon to hide them. All right, so this is quite clean.

[02:34 - 02:39] Let's say that I want to hide live projects here. And it looks right now pretty clean.

[02:40 - 02:54] So our application is not too big, and it's quite easy to track all these dependencies. When you have bigger applications, you probably want to hide more things, just to make everything easy to read, easy to print, and so on.

[02:55 - 03:01] You have some additional features. For example, you can filter the graph using this filter input.

[03:02 - 03:10] Let's say I want to find rooms, and we have only one library that is called rooms. You can group by folder.

[03:11 - 03:17] As you can see, it prints the topology of your code. You can check where the code is in the file system.

[03:18 - 03:21] For example, shed components here. In shed folder.

[03:22 - 03:36] So, annex graph is not only an excellent addition to the whole annex ecosystem, but it should help you with your and your team developer experience. For example, when you onboard a new person, you can show them that graphs.

[03:37 - 03:42] You can show how to use them. They can group by the folder to check where the code is.

[03:43 - 03:55] It's way easier to explain how your application works when you have this kind of graph. The second reason why graph is good for developer experience is documentation.

[03:56 - 04:10] You can easily download using this download button, your graph, and then save it in your wiki page, in your docs, whatever you use. What's more, you can do this from time to time to check how your app is expanding.

[04:11 - 04:21] You can check which parts are growing to big, which parts are not balanced, and so on. What's more, you can even try to use this as a planning tool.

[04:22 - 04:28] You can draw additional graph parts. For example, you have a new feature and you want to put it somewhere.

[04:29 - 04:37] You can draw it and then check, "Okay, so that's how it will look like after my change." Then you can use these plans to compare them.

[04:38 - 04:44] You can find the best solution using just the graph. As you can imagine, there are so many potential usages of annex graph.

[04:45 - 05:04] And the best way to get know them is to experience with them. So I want to encourage you after this lesson to run yarn, run annex graph on our real life example application or any other annex report that you can find on a GitHub and check how it looks like and learn from that.

[05:05 - 05:19] In the next lesson, we'll learn about importance of keeping dependencies in order and then about affected comments and how to use graphs in comments. Because graph is not only a cool visualization of your dependencies.

[05:20 - 05:24] You can use it to write scripts and optimize your work on CI.