This section contains an extremely condensed explanation of the architecture of Angular applications. In the sections that follow, we will review most of the concepts in more detail.

At the highest level, Angular applications are composed of modules called NgModules. Each of these modules represents a separate compilation context for application components. Usually, Angular applications have one module per feature or per group of features; the decomposition is left to the discretion of the developers.

Modules are very useful for ensuring the clean structure of your applications and also to support lazy loading for certain features (among other benefits). By leveraging Angular's lazy loading support, you can avoid wasting the bandwidth of your users by loading specific modules only when they are actually going to be used.

Each module may be composed of different primitives that we will soon discover, such as components, directives, services, pipes (and more) as shown here:

In each and every Angular application, there is always at least a root module, usually called AppModule. The root module enables bootstrapping the application (that is, it serves as an entry point).

Components define and control parts of the user interface (that is, view fragments). Those parts can be as small or as large as you want. Of course, components can (and should!) reuse other components.

They make use of services, for example, to exchange data with remote sources. Services can do anything you fancy. For example, we'll see later on that the services we have created in our previous applications could easily be converted to Angular ones!

Angular components and services can be declared using simple classes (usually written in TypeScript) and annotated with Angular decorators, which are, in fact, TypeScript decorators! Those decorators define their type as well as metadata. For example, in Angular component classes, the @Component decorator is the one that makes the link between the class and the template, which defines the associated view.

Component templates make use of what we could call enhanced HTML. That is, standard HTML tags, custom ones, but also Angular-specific directives, bindings, and expressions. Through bindings and expressions, you can handle inputs and outputs, react to events, and render data provided by the component's controller.

Angular has built-in support for DI. When an application element requires access to some service, then Angular provides it automatically by means of an injector. Angular actually takes care of creating and managing instances of application components, services, and much more. Angular's DI system also relies on metadata defined through other Angular decorators.

Here's a small diagram, taken from the official Angular documentation, that illustrates all of this:

In the preceding diagram, you can see the following:

• A template and its component class can communicate through property bindings and event bindings.
• An injector handles the injection of dependencies into the component.
• Modules contain different elements (values, functions, services, components, and more).

Finally, since Angular supports the creation of SPAs, it also provides a router that can be used to navigate between different routes. When a route is accessed, the router adapts the view and renders the corresponding components. To use the router, you need to import Router NgModule.

There you go—this is Angular in a nutshell.

You can find the official architecture overview here: https://angular.io/guide/architecture.