Macess  Hulk

Macess Hulk

1568945698

Learn about Angular Libraries and Microservices

We live in a Microservices world, and this world is here to stay. Back-end developers need to dive into Domain Driven Design, write stateless, resilient, highly available services, keep data synchronized through Change Data Capture, handle network failure, deal with authentication, authorization, JWT... and expose a beautiful Hypermedia API so the front-end developers can add a great user interface to it.

Good! But what about the front-end?

Let's say we have several microservices, several teams, several APIs and, therefore, several user-interfaces. How can you create an integrated and consistent user interface so your users don't actually see that there are as many user-interfaces as there are Microservices? In this post, I'm implementing the Client-side UI composition design pattern using Angular Libraries.

Let's say we have a CD BookStore application that allows customers to buy CDs and Books online, as well as administrators to check the inventory. We also have some complex ISBN number generator to deal with. If we model this application into Microservices, we might end up splitting it into 3 separate microservices:

  • Store: Deals with displaying information on CDs and books, allows users to buy them.
  • Inventory: Allows administrators to check the availability of an item in the warehouse and buy new items if needed.
  • Generator: Generates ISBN numbers each time a new book is created.

We end up with two roles (user and admin) interacting with these 3 APIs through a single user interface:

So far, so good. But remember that these three microservices are developed by three different teams and therefore, have three different user interfaces. On one hand, we have three different UIs, and on the other hand, we want our users to navigate into what they see as a single and integrated application. There are several ways of doing it, and the one way I'm describing here is called the Client-side UI composition design pattern:

Problem: How to implement a UI screen or page that displays data from multiple services?

Solution: Each team develops a client-side UI component, such an Angular component, that implements the region of the page/screen for their service. A UI team is responsible for implementing the page skeletons that build pages/screens by composing multiple, service-specific UI components.

The idea is to aggregate, on the client side, our three user interfaces into a single one and end up with something that looks like this:

Aggregating several UIs into a single one works better if they use compatible technologies of course. In this example, I am using Angular and only Angular to create the 3 user-interfaces and the page skeleton.

One novelty with Angular CLI 6 is the ability to easily create libraries. Coming back to our architecture, we could say the page skeleton is the Angular application (the CDBookStore application), and then, each microservice user-interface is a library (Store, Inventory, Generator).

In terms of Angular CLI commands, this is what we have:

# Main app called CDBookStore
$ ng new cdbookstore --directory cdbookstore --routing true

The 3 libraries for our 3 microservices UI

$ ng generate library store --prefix str
$ ng generate library inventory --prefix inv
$ ng generate library generator --prefix gen

Once you’ve executed these commands, you will get the following directory structure:

  • src/app/ is the good old Angular structure. In this directory, we will have the page skeleton of the CDBookStore application. As you will see, this skeleton page is only a sidebar to navigate from one Microservice UI to another one
  • projects/ is the directory where all the libraries end up
  • projects/generator: the UI for the Generator microservice
  • projects/inventory: the UI for the Inventory microservice
  • projects/store: the UI for the Store microservice

The skeleton page is there to aggregate all the other components. Basically, it’s only a sidebar menu (allowing us to navigate from one Microservice UI to another one) and a <router-outlet>. It is where you could have login/logout and other user preferences. It looks like this:

In terms of code, despite using Bootstrap, there is nothing special. What’s interesting is the way the routes are defined. The AppRoutingModule only defines the routes of the main application (here, the Home and the About menus).

const routes: Routes = [
 {path: ‘’, component: HomeComponent},
 {path: ‘home’, component: HomeComponent},
 {path: ‘about’, component: AboutComponent},

];
@NgModule({
 imports: [RouterModule.forRoot(routes)],
 exports: [RouterModule]
})
export class AppRoutingModule { }

In the HTML side of the side menu bar, we can find the navigation directive and the router:

<ul class=“list-unstyled components”>
<li>
<a [routerLink]=“[‘/home’]”>
<i class=“fas fa-home”></i>
Home
</a>
<a [routerLink]=“[‘/str’]”>
<i class=“fas fa-store”></i>
Store
</a>
<a [routerLink]=“[‘/inv’]”>
<i class=“fas fa-chart-bar”></i>
Inventory
</a>
<a [routerLink]=“[‘/gen’]”>
<i class=“fas fa-cogs”></i>
Generator
</a>
</li>
</ul>
<!-- Page Content -->
<div id=“content”>
<router-outlet></router-outlet>
</div>

As you can see in the code above, the routerLink directive is used to navigate to the main app components as well as libraries components. The trick here is that /home is defined in the routing module, but not /str, /inv or /gen. These routes are defined in the libraries themselves.

Now when we click on Store, Inventory or Generator, we want the router to navigate to the library’s components

Notice the parent/child relationship between routers. In the image above, the red router-outlet is the parent and belongs to the main app. The green router-outlet is the child and belongs to the library. Notice that in the store-routing.module.ts we use str has the main path, and all the other paths are children (using the children keyword):

const routes: Routes = [
{
path: ‘str’, component: StoreComponent, children: [
{path: ‘’, component: HomeComponent},
{path: ‘home’, component: HomeComponent},
{path: ‘book-list’, component: BookListComponent},
{path: ‘book-detail’, component: BookDetailComponent},
]
},
];

@NgModule({
imports: [RouterModule.forRoot(routes)],
exports: [RouterModule]
})
export class StoreRoutingModule {
}

The beauty of having a parent/child router relationship is that you can benefit from “feature” navigation. This means that if you navigate to /home or /about you stay in the main application, but if you navigate to /str, /str/home, /str/book-list or /str/book-detail, you navigate to the Store library. You can even do lazy loading on a per feature based (only load the Store library if needed).

The Store library has a navigation bar at the top, therefore, it needs the routerLink directive. Notice that we only need to use the child path [routerLink]=“[‘book-list’]” without having to specify /str (no need to [routerLink]=“[‘/str/book-list’]”):

<nav>
<div class=“collapse navbar-collapse”>
<ul class=“navbar-nav mr-auto”>
<li class=“nav-item dropdown”>
<a class=“nav-link dropdown-toggle”>Items</a>
<div class=“dropdown-menu” aria-labelledby=“navbarDropdownMenuLink”>
<a class=“dropdown-item” [routerLink]=“[‘book-list’]”>Books</a>
<a class=“dropdown-item” [routerLink]=“[‘cd-list’]”>CDs</a>
<a class=“dropdown-item” [routerLink]=“[‘dvd-list’]”>DVDs</a>
</div>
</li>
</ul>
</div>
</nav>
<!-- Page Content -->
<div id=“content”>
<router-outlet></router-outlet>
</div>

The Client-side UI composition design pattern has some pros and cons. If you already have existing user-interfaces per microservices, and if each one is using totally different technologies (Angular vs React vs Vue.JS vs …) or different framework versions (Bootstrap 2 vs Bootstrap 4), then aggregating them might be tricky and you might have to rewrite bits and pieces to have them compatible.

But this can actually be beneficial. If you don’t have extended teams with hundreds of developers, you might end up being the one moving from one team to another one and will be happy to find (more or less) the same technologies. This is defined in the Chassis pattern. And for your end users, the application will have the same look and feel (on mobile phones, laptops, desktops, tablets), which gives a sense of integration.

With the way Angular Libraries are structured, having a mono repo is much easier. Of course, each library can have their own life cycle and be independent, but at the end of the day, it makes it easier to have them on the same repo. I don’t know if you love MonoRepos or not, but some do.

We’ve been architecting and developing Microservices for several decades now (yes, it used to be called distributed systems, or distributed services), so we roughly know how to make them work on the back-end. Now, the challenge is to be able to have a user interface which communicates with several Microservices, developed by different teams, and at the same time feels consistent and integrated for the end-user. You might not always have this need (see how Amazon has totally different UIs for its services), but if you do, then the Client-side UI composition design pattern is a good alternative.

If you want to give it a try, download the code, install and run it (there is only the front-end, no back-end APIs). I hope this tutorial will surely help and you if you liked this tutorial, please consider sharing it with others, thanks for reading!

This post was originally published here

#angular #angular-js #microservices #web-development #devops

What is GEEK

Buddha Community

Learn about Angular Libraries and Microservices
Roberta  Ward

Roberta Ward

1595344320

Wondering how to upgrade your skills in the pandemic? Here's a simple way you can do it.

Corona Virus Pandemic has brought the world to a standstill.

Countries are on a major lockdown. Schools, colleges, theatres, gym, clubs, and all other public places are shut down, the country’s economy is suffering, human health is on stake, people are losing their jobs and nobody knows how worse it can get.

Since most of the places are on lockdown, and you are working from home or have enough time to nourish your skills, then you should use this time wisely! We always complain that we want some ‘time’ to learn and upgrade our knowledge but don’t get it due to our ‘busy schedules’. So, now is the time to make a ‘list of skills’ and learn and upgrade your skills at home!

And for the technology-loving people like us, Knoldus Techhub has already helped us a lot in doing it in a short span of time!

If you are still not aware of it, don’t worry as Georgia Byng has well said,

“No time is better than the present”

– Georgia Byng, a British children’s writer, illustrator, actress and film producer.

No matter if you are a developer (be it front-end or back-end) or a data scientisttester, or a DevOps person, or, a learner who has a keen interest in technology, Knoldus Techhub has brought it all for you under one common roof.

From technologies like Scala, spark, elastic-search to angular, go, machine learning, it has a total of 20 technologies with some recently added ones i.e. DAML, test automation, snowflake, and ionic.

How to upgrade your skills?

Every technology in Tech-hub has n number of templates. Once you click on any specific technology you’ll be able to see all the templates of that technology. Since these templates are downloadable, you need to provide your email to get the template downloadable link in your mail.

These templates helps you learn the practical implementation of a topic with so much of ease. Using these templates you can learn and kick-start your development in no time.

Apart from your learning, there are some out of the box templates, that can help provide the solution to your business problem that has all the basic dependencies/ implementations already plugged in. Tech hub names these templates as xlr8rs (pronounced as accelerators).

xlr8rs make your development real fast by just adding your core business logic to the template.

If you are looking for a template that’s not available, you can also request a template may be for learning or requesting for a solution to your business problem and tech-hub will connect with you to provide you the solution. Isn’t this helpful 🙂

Confused with which technology to start with?

To keep you updated, the Knoldus tech hub provides you with the information on the most trending technology and the most downloaded templates at present. This you’ll be informed and learn the one that’s most trending.

Since we believe:

“There’s always a scope of improvement“

If you still feel like it isn’t helping you in learning and development, you can provide your feedback in the feedback section in the bottom right corner of the website.

#ai #akka #akka-http #akka-streams #amazon ec2 #angular 6 #angular 9 #angular material #apache flink #apache kafka #apache spark #api testing #artificial intelligence #aws #aws services #big data and fast data #blockchain #css #daml #devops #elasticsearch #flink #functional programming #future #grpc #html #hybrid application development #ionic framework #java #java11 #kubernetes #lagom #microservices #ml # ai and data engineering #mlflow #mlops #mobile development #mongodb #non-blocking #nosql #play #play 2.4.x #play framework #python #react #reactive application #reactive architecture #reactive programming #rust #scala #scalatest #slick #software #spark #spring boot #sql #streaming #tech blogs #testing #user interface (ui) #web #web application #web designing #angular #coronavirus #daml #development #devops #elasticsearch #golang #ionic #java #kafka #knoldus #lagom #learn #machine learning #ml #pandemic #play framework #scala #skills #snowflake #spark streaming #techhub #technology #test automation #time management #upgrade

Christa  Stehr

Christa Stehr

1598940617

Install Angular - Angular Environment Setup Process

Angular is a TypeScript based framework that works in synchronization with HTML, CSS, and JavaScript. To work with angular, domain knowledge of these 3 is required.

  1. Installing Node.js and npm
  2. Installing Angular CLI
  3. Creating workspace
  4. Deploying your First App

In this article, you will get to know about the Angular Environment setup process. After reading this article, you will be able to install, setup, create, and launch your own application in Angular. So let’s start!!!

Angular environment setup

Install Angular in Easy Steps

For Installing Angular on your Machine, there are 2 prerequisites:

  • Node.js
  • npm Package Manager
Node.js

First you need to have Node.js installed as Angular require current, active LTS or maintenance LTS version of Node.js

Download and Install Node.js version suitable for your machine’s operating system.

Npm Package Manager

Angular, Angular CLI and Angular applications are dependent on npm packages. By installing Node.js, you have automatically installed the npm Package manager which will be the base for installing angular in your system. To check the presence of npm client and Angular version check of npm client, run this command:

  1. npm -v

Installing Angular CLI

  • Open Terminal/Command Prompt
  • To install Angular CLI, run the below command:
  1. npm install -g @angular/cli

installing angular CLI

· After executing the command, Angular CLI will get installed within some time. You can check it using the following command

  1. ng --version

Workspace Creation

Now as your Angular CLI is installed, you need to create a workspace to work upon your application. Methods for it are:

  • Using CLI
  • Using Visual Studio Code
1. Using CLI

To create a workspace:

  • Navigate to the desired directory where you want to create your workspace using cd command in the Terminal/Command prompt
  • Then in the directory write this command on your terminal and provide the name of the app which you want to create. In my case I have mentioned DataFlair:
  1. Ng new YourAppName

create angular workspace

  • After running this command, it will prompt you to select from various options about the CSS and other functionalities.

angular CSS options

  • To leave everything to default, simply press the Enter or the Return key.

angular setup

#angular tutorials #angular cli install #angular environment setup #angular version check #download angular #install angular #install angular cli

Macess  Hulk

Macess Hulk

1568945698

Learn about Angular Libraries and Microservices

We live in a Microservices world, and this world is here to stay. Back-end developers need to dive into Domain Driven Design, write stateless, resilient, highly available services, keep data synchronized through Change Data Capture, handle network failure, deal with authentication, authorization, JWT... and expose a beautiful Hypermedia API so the front-end developers can add a great user interface to it.

Good! But what about the front-end?

Let's say we have several microservices, several teams, several APIs and, therefore, several user-interfaces. How can you create an integrated and consistent user interface so your users don't actually see that there are as many user-interfaces as there are Microservices? In this post, I'm implementing the Client-side UI composition design pattern using Angular Libraries.

Let's say we have a CD BookStore application that allows customers to buy CDs and Books online, as well as administrators to check the inventory. We also have some complex ISBN number generator to deal with. If we model this application into Microservices, we might end up splitting it into 3 separate microservices:

  • Store: Deals with displaying information on CDs and books, allows users to buy them.
  • Inventory: Allows administrators to check the availability of an item in the warehouse and buy new items if needed.
  • Generator: Generates ISBN numbers each time a new book is created.

We end up with two roles (user and admin) interacting with these 3 APIs through a single user interface:

So far, so good. But remember that these three microservices are developed by three different teams and therefore, have three different user interfaces. On one hand, we have three different UIs, and on the other hand, we want our users to navigate into what they see as a single and integrated application. There are several ways of doing it, and the one way I'm describing here is called the Client-side UI composition design pattern:

Problem: How to implement a UI screen or page that displays data from multiple services?

Solution: Each team develops a client-side UI component, such an Angular component, that implements the region of the page/screen for their service. A UI team is responsible for implementing the page skeletons that build pages/screens by composing multiple, service-specific UI components.

The idea is to aggregate, on the client side, our three user interfaces into a single one and end up with something that looks like this:

Aggregating several UIs into a single one works better if they use compatible technologies of course. In this example, I am using Angular and only Angular to create the 3 user-interfaces and the page skeleton.

One novelty with Angular CLI 6 is the ability to easily create libraries. Coming back to our architecture, we could say the page skeleton is the Angular application (the CDBookStore application), and then, each microservice user-interface is a library (Store, Inventory, Generator).

In terms of Angular CLI commands, this is what we have:

# Main app called CDBookStore
$ ng new cdbookstore --directory cdbookstore --routing true

The 3 libraries for our 3 microservices UI

$ ng generate library store --prefix str
$ ng generate library inventory --prefix inv
$ ng generate library generator --prefix gen

Once you’ve executed these commands, you will get the following directory structure:

  • src/app/ is the good old Angular structure. In this directory, we will have the page skeleton of the CDBookStore application. As you will see, this skeleton page is only a sidebar to navigate from one Microservice UI to another one
  • projects/ is the directory where all the libraries end up
  • projects/generator: the UI for the Generator microservice
  • projects/inventory: the UI for the Inventory microservice
  • projects/store: the UI for the Store microservice

The skeleton page is there to aggregate all the other components. Basically, it’s only a sidebar menu (allowing us to navigate from one Microservice UI to another one) and a <router-outlet>. It is where you could have login/logout and other user preferences. It looks like this:

In terms of code, despite using Bootstrap, there is nothing special. What’s interesting is the way the routes are defined. The AppRoutingModule only defines the routes of the main application (here, the Home and the About menus).

const routes: Routes = [
 {path: ‘’, component: HomeComponent},
 {path: ‘home’, component: HomeComponent},
 {path: ‘about’, component: AboutComponent},

];
@NgModule({
 imports: [RouterModule.forRoot(routes)],
 exports: [RouterModule]
})
export class AppRoutingModule { }

In the HTML side of the side menu bar, we can find the navigation directive and the router:

<ul class=“list-unstyled components”>
<li>
<a [routerLink]=“[‘/home’]”>
<i class=“fas fa-home”></i>
Home
</a>
<a [routerLink]=“[‘/str’]”>
<i class=“fas fa-store”></i>
Store
</a>
<a [routerLink]=“[‘/inv’]”>
<i class=“fas fa-chart-bar”></i>
Inventory
</a>
<a [routerLink]=“[‘/gen’]”>
<i class=“fas fa-cogs”></i>
Generator
</a>
</li>
</ul>
<!-- Page Content -->
<div id=“content”>
<router-outlet></router-outlet>
</div>

As you can see in the code above, the routerLink directive is used to navigate to the main app components as well as libraries components. The trick here is that /home is defined in the routing module, but not /str, /inv or /gen. These routes are defined in the libraries themselves.

Now when we click on Store, Inventory or Generator, we want the router to navigate to the library’s components

Notice the parent/child relationship between routers. In the image above, the red router-outlet is the parent and belongs to the main app. The green router-outlet is the child and belongs to the library. Notice that in the store-routing.module.ts we use str has the main path, and all the other paths are children (using the children keyword):

const routes: Routes = [
{
path: ‘str’, component: StoreComponent, children: [
{path: ‘’, component: HomeComponent},
{path: ‘home’, component: HomeComponent},
{path: ‘book-list’, component: BookListComponent},
{path: ‘book-detail’, component: BookDetailComponent},
]
},
];

@NgModule({
imports: [RouterModule.forRoot(routes)],
exports: [RouterModule]
})
export class StoreRoutingModule {
}

The beauty of having a parent/child router relationship is that you can benefit from “feature” navigation. This means that if you navigate to /home or /about you stay in the main application, but if you navigate to /str, /str/home, /str/book-list or /str/book-detail, you navigate to the Store library. You can even do lazy loading on a per feature based (only load the Store library if needed).

The Store library has a navigation bar at the top, therefore, it needs the routerLink directive. Notice that we only need to use the child path [routerLink]=“[‘book-list’]” without having to specify /str (no need to [routerLink]=“[‘/str/book-list’]”):

<nav>
<div class=“collapse navbar-collapse”>
<ul class=“navbar-nav mr-auto”>
<li class=“nav-item dropdown”>
<a class=“nav-link dropdown-toggle”>Items</a>
<div class=“dropdown-menu” aria-labelledby=“navbarDropdownMenuLink”>
<a class=“dropdown-item” [routerLink]=“[‘book-list’]”>Books</a>
<a class=“dropdown-item” [routerLink]=“[‘cd-list’]”>CDs</a>
<a class=“dropdown-item” [routerLink]=“[‘dvd-list’]”>DVDs</a>
</div>
</li>
</ul>
</div>
</nav>
<!-- Page Content -->
<div id=“content”>
<router-outlet></router-outlet>
</div>

The Client-side UI composition design pattern has some pros and cons. If you already have existing user-interfaces per microservices, and if each one is using totally different technologies (Angular vs React vs Vue.JS vs …) or different framework versions (Bootstrap 2 vs Bootstrap 4), then aggregating them might be tricky and you might have to rewrite bits and pieces to have them compatible.

But this can actually be beneficial. If you don’t have extended teams with hundreds of developers, you might end up being the one moving from one team to another one and will be happy to find (more or less) the same technologies. This is defined in the Chassis pattern. And for your end users, the application will have the same look and feel (on mobile phones, laptops, desktops, tablets), which gives a sense of integration.

With the way Angular Libraries are structured, having a mono repo is much easier. Of course, each library can have their own life cycle and be independent, but at the end of the day, it makes it easier to have them on the same repo. I don’t know if you love MonoRepos or not, but some do.

We’ve been architecting and developing Microservices for several decades now (yes, it used to be called distributed systems, or distributed services), so we roughly know how to make them work on the back-end. Now, the challenge is to be able to have a user interface which communicates with several Microservices, developed by different teams, and at the same time feels consistent and integrated for the end-user. You might not always have this need (see how Amazon has totally different UIs for its services), but if you do, then the Client-side UI composition design pattern is a good alternative.

If you want to give it a try, download the code, install and run it (there is only the front-end, no back-end APIs). I hope this tutorial will surely help and you if you liked this tutorial, please consider sharing it with others, thanks for reading!

This post was originally published here

#angular #angular-js #microservices #web-development #devops

Roberta  Ward

Roberta Ward

1593184320

Basics of Angular: Part-1

What is Angular? What it does? How we implement it in a project? So, here are some basics of angular to let you learn more about angular.

Angular is a Typescript-based open-source front-end web application platform. The Angular Team at Google and a community of individuals and corporations lead it. Angular lets you extend HTML’s syntax to express your apps’ components clearly. The angular resolves challenges while developing a single page and cross-platform applications. So, here the meaning of the single-page applications in angular is that the index.html file serves the app. And, the index.html file links other files to it.

We build angular applications with basic concepts which are NgModules. It provides a compilation context for components. At the beginning of an angular project, the command-line interface provides a built-in component which is the root component. But, NgModule can add a number of additional components. These can be created through a template or loaded from a router. This is what a compilation context about.

What is a Component in Angular?

Components are key features in Angular. It controls a patch of the screen called a view. A couple of components that we create on our own helps to build a whole application. In the end, the root component or the app component holds our entire application. The component has its business logic that it does to support the view inside the class. The class interacts with the view through an API of properties and methods. All the components added by us in the application are not linked to the index.html. But, they link to the app.component.html through the selectors. A component can be a component and not only a typescript class by adding a decorator @Component. Then, for further access, a class can import it. The decorator contains some metadata like selector, template, and style. Here’s an example of how a component decorator looks like:

@Component({
    selector: 'app-root',
    templateUrl: 'app.component.html',
    styleUrls: ['app.component.scss']
})

Role of App Module

Modules are the package of functionalities of our app. It gives Angular the information about which features does my app has and what feature it uses. It is an empty Typescript class, but we transform it by adding a decorator @NgModule. So, we have four properties that we set up on the object pass to @NgModule. The four properties are declarations, imports, providers, and bootstrap. All the built-in new components add up to the declarations array in @NgModule.

@NgModule({
declarations: [
  AppComponent,
],
imports: [
  BrowserModule,
  HttpClientModule,
  AppRoutingModule,
  FormsModule
],
bootstrap: [AppComponent]
})

What is Data Binding?

Data Binding is the communication between the Typescript code of the component and the template. So, we have different kinds of data binding given below:

  • When there is a requirement to output data from our Typescript code in the HTML template. String interpolation handles this purpose like {{data}} in HTML file. Property Binding is also used for this purpose like [property] = “data”.
  • When we want to trigger any event like clicking a button. Event Binding works while we react to user events like (event) = “expression”.
  • When we can react to user events and output something at the same time. Two-way Binding is used like [(ngModel)] = “data”.

image for understanding data binding

#angular #javascript #tech blogs #user interface (ui) #angular #angular fundamentals #angular tutorial #basics of angular

Juana  O'Keefe

Juana O'Keefe

1601515800

Going to a library with Angular

Hi! Today we are going to learn how to create a library in angular and import that in other angular applications.

Prerequisites

  • Basic knowledge of angular
  • Node and NPM set up in the system

First clear out the Common thoughts

What are Angular Libraries?

An angular library is a collection of components, services, directives, etc. that can be shared across different Angular projects. More precisely, in programming, the Library is a collection of precompiled routines that a program can use.

An Angular library cannot run on its own. It must be imported as a package in an angular application. It is a shareable code which provides Reusable functionality.

Why do we need a Library?

Many applications need to solve the same general problems, such as presenting a unified user interface, presenting data, and allowing data entry. We as developers can create general solutions for particular domains that can be adapted for re-use in different apps. These solutions can be used locally in your workspace, or you can publish them as npm packages to share with other projects or with other Angular developers across the globe.

Certain solutions are complex in nature and recreating them everywhere we need it, is heck of a job. That’s why its better to create such complex solutions as libraries to reuse with ease.

That’s why libraries are important and angular embraces this functionality. Look at some of the angular core libraries like RXJS that are imported as a library in angular and we know how important RXJS is in the angular world. Just imagine if we didn’t have the RXJS as a library but instead, we had some functions in some documentation, and in order to use it, we have to copy-paste those functions into every component and angular application we create. That would be troublesome and hard to maintain.

Behind the scenes: ng-packagr

Angular has a compiling component name packagr whose only job is to maintain the integrity between the angular apps that import angular libraries. We create angular libraries with the different angular core versions and these libraries are imported into different angular apps that may or may not be based on the latest angular version. Some apps may be based on the latest angular 10 but some apps might be based on version 4 or 5. So, how does a library created with version 10 can work with an app based on version 5. For this, angular has a pretty build tool that specific to libraries as it packages them into a certain format that’s compatible with any version of angular (not any, just the ones that are supported).

The tool name is ng-packagr which is used to compile and package a Typescript library to angular package format. This packagr makes sure that what we want to reuse in other angular apps must follow certain guidelines/rules.

These guidelines are Angular Package Format – a set of instructions that make sure whatever you are packaging will be able to integrate into other angular apps.

Current guideline – https://docs.google.com/document/d/1CZC2rcpxffTDfRDs6p1cfbmKNLA6x5O-NtkJglDaBVs/preview

Let’s code!!

Creating angular workspace without application

Hit this command in your terminal, opened up where you want to have the directory –

ng new <workspace-name> --create-application=false

Terminal execution of the command

This command creates a mono repo structure for angular workspace. Mono repo structure refers to a structure that not only contains one project but many. These structures are suitable for the applications that divided into several projects but are correlated to each other. For example, a UI whose navbar is a separate project, whose sidebar is a separate project, and further too. Each visual element dynamic element is separately handled in a different project with free choice of using any dev dependencies. These kinds of front-ends are also known as** micro front-ends.**

With mono repo, we will have the angular library and library consumer app in the same workspace.

Hit the below command, inside the created directory

ng generate library <library-name>

Library command output

#angular #web application #angular #angular-library #npm