Tips. Target architecture

[00:00 - 00:06] This lesson may be a surprise for you. I won't convince you to switch from one architecture to another because it's better or stamping.

[00:07 - 00:17] We are not going to describe the advantages or disadvantages of architectures. Every project is different and the architecture that works on my project might not suit you.

[00:18 - 00:30] What's more, every project that I worked on had a different approach and a bit different architecture. Knowledge about the context, customer, team needs is the key to successful code organization.

[00:31 - 00:58] In this lesson, we'll focus on edX features that will help you organize your applications and libraries in the way that suits almost all possible architectures. The common problem is that no matter which architecture you're using, almost all of them have some rules and you need to enforce them. For example, in domain-driven design, you want to isolate the domain so your components will use only methods exposed by API services.

[00:59 - 01:32] These rules are often related to code decomposition. You just want to be sure that some classes will not import other classes because it will create huge mess. In case of edX, we can make sure that programmers will not be able to import libraries that shouldn't be used in other libraries. For example, you don't want to allow your developers to import parts of applications in other applications. It makes applications depend on each other and it's not a good idea. So edX gives you something called tax.

[01:33 - 02:48] You can tag your libraries and then use these tags to create rules. For example , you can create tags like type app or type library. So you can say that this project is an app, this project is in a library. You can even add more tags like library UI or library API to say this project will contain only UI logic, this project will contain API logic and so on. So maybe let's create some code and I will show you in practice how it looks like. On the screen at the moment, you see all the comments I use to generate a new application. So my application contains one application and three libraries, users UI, users API and users HTTP. And in my design, I'm going to create a few decks. So first of all, type app for applications, type leap for libraries and then library specific stacks, leap UI for UI components, leap API for API services and leap HTTP for HTTP layer of my application. So in my design, apps can depend only on libraries. Libraries can depend on other libraries. UI libraries can be used in applications.

[02:49 - 03:09] API libraries can be used in UI libraries or applications and HTTP libraries can be used in UI component libraries and API libraries. So as you can see, we have some rules to fall. Let generate the code and I will show you how to configure an X to respect these rules.

[03:10 - 04:03] All right, as you can see, I have my application generated, I have my app and three libraries, every single app and library contain project.json file. And let's start with apps app project.json file. As you can see in seventh line, you have a right of text and we can specify tags we want. So for my app, I'm going to use only one tag, type app. Then let 's switch to users UI. And once again, let's open project.json, we have tags. And I'm going to add to decks, type library and library UI. Next one is users API. Let's open project.json and let 's specify type library and library API. And the last one is users HTTP. Let's add tag leap HTTP.

[04:04 - 05:12] All right, so we have our attacks configured, but how to use them. So let's configure which tags can be used by another tax. And to do this, we need to open as linked RC that JSON file as linked configuration. And as you can see, we have a role called NX slash and force module boundaries. And you can use this as the role to model your architecture. As you can see, we have our deck constraints here. So let's configure the first rule that apps can depend only on libraries. To do this, I'm setting an object with source tag type app. And it only depends on leaps with tags, type library. So all the project that have type app can depend only on type leap. And if you're going to have a dependency between one project with type app to another project with type app tag, it will throw an as linked error. The next rule that we want to specify is that libraries can depend on other libraries. And it will be similar to the role we have at the moment.

[05:13 - 05:43] So source tag type library, and it can depend only on other type library. And with that simple trick, we say that libraries cannot depend on other apps. All right, so now let 's add rules for our library specific decks. So for our library UI library API and library HTTP. As you can remember, our library UI can depend only on library HTTP library API and other library UI .

[05:44 - 08:51] Then library API can depend only on library HTTP or other library API. And the last one, library HTTP can depend only on other library HTTP. So let's add it. And as you can see, I decided to ban some external imports. I don't want to let my team to use angular common HTTP in projects stacked with library UI. So you cannot work around my rules. You cannot just inject angular common HTTP and use HTTP layer in UI components. As you can imagine, you can model almost every architecture you like. You can have various number of tags. You can have categories of tags as I have, I have my type. So project type tags, I have my library tags . You can treat whatever you want. And it's going to work. Only thing you need to do later is to configure the rules that your team needs to follow. Okay, so let's test it. Let's say we want to break some rules and we want to import library UI object to library HTTP project. And as you can see, in my library UI here, I have a component user's UI component. Let's import it to our users HTTP component. And let's check the result. So in my users HTTP component, I'm going to import users UI component. And as you can see, we have that red wave under our import. And it's basically saying that I cannot use this import. To show you more details, I'm going to execute linked comment in the common line. All right, as you can see, I used comment yarn and X run many with target linked for all projects. So I basically run all linked comments in the whole monorepo. And we have an error in users HTTP library with message, a project tag with lib HTTP can only depend on leaps tagged with lib HTTP. So our rules work. What's more, please remember that you can control external libraries. So we can ban some libraries from some parts of our application. For example, I banned HTTP, Angela, common HTTP in live UI tech projects. Of course, you can create some exceptions, because we always have some exceptions. To create an exception, you can use add a keyword like this. And then set which external libraries are allowed in which tagged project. So I can allow to use Angela, come on HTTP in lips UI if I want. Tags at first might look like something stupid simple and unnecessary. In fact, this feature in cooperation with as linked is a powerful tool that makes code organization a lot easier, no matter which architecture you're using. In the The next few lessons will try to summarize everything that you have learned.