Microservices Using ASP.NET Core

Microservices

The term microservices portrays a software development style that has grown from contemporary trends to set up practices that are meant to increase the speed and efficiency of developing and managing software solutions at scale. Microservices is more about applying a certain number of principles and architectural patterns as architecture. Each microservice lives independently, but on the other hand, also all rely on each other. All microservices in a project get deployed in production at their own pace, on-premise on the cloud, independently, living side by side.

Microservices Architecture

The following picture from Microsoft Docs shows the microservices architecture style.

 

There are various components in a microservices architecture apart from microservices themselves.

Management. Maintains the nodes for the service.

Identity Provider. Manages the identity information and provides authentication services within a distributed network.

Service Discovery. Keeps track of services and service addresses and endpoints.

API Gateway. Serves as client’s entry point. Single point of contact from the client which in turn returns responses from underlying microservices and sometimes an aggregated response from multiple underlying microservices.

CDN. A content delivery network to serve static resources for e.g. pages and web content in a distributed network

Static Content The static resources like pages and web content

Microservices are deployed independently with their own database per service so the underlying microservices look as shown in the following picture.

 

Monolithic vs Microservices Architecture

Monolithic applications are more of a single complete package having all the related needed components and services encapsulated in one package.

Following is the diagrammatic representation of monolithic architecture being package completely or being service based.

 

Microservice is an approach to create small services each running in their own space and can communicate via messaging. These are independent services directly calling their own database.

Following is the diagrammatic representation of microservices architecture.

 

In monolithic architecture, the database remains the same for all the functionalities even if an approach of service-oriented architecture is followed, whereas in microservices each service will have its own database.

Docker Containers and Docker installation

Containers like Dockers and others slice the operating system resources, for e.g. the network stack, processes namespace, file system hierarchy and the storage stack. Dockers are more like virtualizing the operating system. Learn more about dockers here. Open this URL and click on Download from Docker hub. Once downloaded, login to the Docker and follow instructions to install Docker for Windows.

Microservice using ASP.NET Core

This section will demonstrate how to create a Product microservice using ASP.NET Core step by step with the help of pictures. The service would be built using ASP.NET Core 2.1 and Visual Studio 2017. Asp.NET Core comes integrated with VS 2017. This service will have its own DBcontext and database with the isolated repository so that the service could be deployed independently.

 

Creating an ASP.NET Core Application Solution

1. Open the Visual Studio and add a new project.
   
   

2. Choose the application as ASP.NET Core Web Application and give it a meaningful name.
   
   

3. Next, choose API as the type of the project and make sure that “Enable Docker Support” option is selected with OS type as Linux.
   
   

4. The solution will look as shown below.
   
   

Adding Models

1. Add a new folder named “Model” to the project.
   
   

2. In the Models folder, add a class named Product.
   
   

3. Add a few properties like Id, Name, Description, Price to the product class. The product should also be of some kind and for that, a category model is defined and a CategoryId property is added to the product model.
   
   

4. Similarly, add Category model.
   
   

Enabling EF Core

Though .NET Core API project has inbuilt support for EF Core and all the related dependencies are downloaded at the time of project creation and compilation that could be found under SDK section in the project as shown below.

 

Microsoft.EntityFrameworkCore.SqlServer (2.1.1) should be the package inside the downloaded SDK’s. If it is not present, it could be explicitly added to the project via Nuget Packages.

Adding EF Core DbContext

A database context is needed so that the models could interact with the database.

1. Add a new folder named DBContexts to the project.
   
   

2. Add a new class named ProductContext which includes the DbSet properties for Products and Categories. OnModelCreating is a method via which the master data could be seeded to the database. So, add the OnModelCreating method and add some sample categories that will be added to the database initially into the category table when the database is created.
   
   
   
   ProductContext code
   
   1. using Microsoft.EntityFrameworkCore;  
   2. using ProductMicroservice.Models;  
   3.   
   4. namespace ProductMicroservice.DBContexts  
   5. {  
   6.   public class ProductContext : DbContext  
   7.   {  
   8.     public ProductContext(DbContextOptions<ProductContext> options) : base(options)  
   9.     {  
   10.     }  
   11.     public DbSet<Product> Products { get; set; }  
   12.     public DbSet<Category> Categories { get; set; }  
   13.   
   14.     protected override void OnModelCreating(ModelBuilder modelBuilder)  
   15.     {  
   16.       modelBuilder.Entity<Category>().HasData(  
   17.           new Category  
   18.           {  
   19.             Id = 1,  
   20.             Name = "Electronics",  
   21.             Description = "Electronic Items",  
   22.           },  
   23.           new Category  
   24.           {  
   25.             Id = 2,  
   26.             Name = "Clothes",  
   27.             Description = "Dresses",  
   28.           },  
   29.           new Category  
   30.           {  
   31.             Id = 3,  
   32.             Name = "Grocery",  
   33.             Description = "Grocery Items",  
   34.           }  
   35.       );  
   36.     }  
   37.   
   38.   }  
   39. }  

3. Add a connection string in the appsettings.json file.
   
   

Open the Startup.cs file to add the SQL server db provider for EF Core. Add the code services.AddDbContext<ProductContext>(o => o.UseSqlServer(Configuration.GetConnectionString("ProductDB"))); under ConfigureServices method. Note that in the GetConnectionString method the name of the key of the connection string is passed that was added in appsettings file.

 

Adding Repository

Repository works as a micro component of microservice that encapsulates the data access layer and helps in data persistence and testability as well.

1. Add a new folder named Repository in the project and add an Interface name IProductRepository in that folder. Add the methods in the interface that performs CRUD operations for Product microservice.
   
   

2. Add a new concrete class named ProductRepository in the same Repository folder that implements IProductRepository. All these methods need:
   
   

3. Add the implementation for the methods via accessing context methods.
   
   ProductRepository.cs
   
   1. using Microsoft.EntityFrameworkCore;  
   2. using ProductMicroservice.DBContexts;  
   3. using ProductMicroservice.Models;  
   4. using System;  
   5. using System.Collections.Generic;  
   6. using System.Linq;  
   7.   
   8. namespace ProductMicroservice.Repository  
   9. {  
   10.   public class ProductRepository: IProductRepository  
   11.   {  
   12.     private readonly ProductContext _dbContext;  
   13.   
   14.     public ProductRepository(ProductContext dbContext)  
   15.     {  
   16.       _dbContext = dbContext;  
   17.     }  
   18.     public void DeleteProduct(int productId)  
   19.     {  
   20.       var product = _dbContext.Products.Find(productId);  
   21.       _dbContext.Products.Remove(product);  
   22.       Save();  
   23.     }  
   24.   
   25.     public Product GetProductByID(int productId)  
   26.     {  
   27.       return _dbContext.Products.Find(productId);  
   28.     }  
   29.   
   30.     public IEnumerable<Product> GetProducts()  
   31.     {  
   32.       return _dbContext.Products.ToList();  
   33.     }  
   34.   
   35.     public void InsertProduct(Product product)  
   36.     {  
   37.       _dbContext.Add(product);  
   38.       Save();    }  
   39.   
   40.     public void Save()  
   41.     {  
   42.       _dbContext.SaveChanges();  
   43.     }  
   44.   
   45.     public void UpdateProduct(Product product)  
   46.     {  
   47.       _dbContext.Entry(product).State = EntityState.Modified;  
   48.       Save();  
   49.     }  
   50.   }  
   51. }  

4. Open the Startup class in the project and add the code as services.AddTransient<IProductRepository, ProductRepository>(); inside ConfigureServices method so that the repository’s dependency is resolved at a run time when needed.
   
   

Adding Controller

The microservice should have an endpoint for which a controller is needed which exposes the HTTP methods to the client as endpoints of the service methods.

1. Right click on the Controllers folder and add a new Controller as shown below.
   
   

2. Select the option “API Controller with read/write actions” to add the controller.
   
   

3. Give the name of the controller as ProductController.
   
   

4. A ProductController class will be added in the Controllers folder with default read/write actions that will be replaced later with product read/write actions and HTTP methods are created acting as an endpoint of the service.
   
   

5. ValuesController can be deleted as it is not needed.
   
   

6. Add implementation to the methods by calling the repository methods as shown below. The basic implementation is shown here for the sake of understanding the concept. The methods could be attribute routed and could be decorated with more annotations as per need.
   
   ProductController.cs
   
   1. using Microsoft.AspNetCore.Mvc;  
   2. using ProductMicroservice.Models;  
   3. using ProductMicroservice.Repository;  
   4. using System;  
   5. using System.Collections.Generic;  
   6. using System.Transactions;  
   7.   
   8. namespace ProductMicroservice.Controllers  
   9. {  
   10.   [Route("api/[controller]")]  
   11.   [ApiController]  
   12.   public class ProductController : ControllerBase  
   13.   {  
   14.   
   15.     private readonly IProductRepository _productRepository;  
   16.   
   17.     public ProductController(IProductRepository productRepository)  
   18.     {  
   19.       _productRepository = productRepository;  
   20.     }  
   21.       
   22.     [HttpGet]  
   23.     public IActionResult Get()  
   24.     {  
   25.       var products = _productRepository.GetProducts();  
   26.       return new OkObjectResult(products);  
   27.     }  
   28.   
   29.     [HttpGet("{id}", Name = "Get")]  
   30.     public IActionResult Get(int id)  
   31.     {  
   32.       var product = _productRepository.GetProductByID(id);  
   33.       return new OkObjectResult(product);  
   34.     }  
   35.   
   36.     [HttpPost]  
   37.     public IActionResult Post([FromBody] Product product)  
   38.     {  
   39.       using (var scope = new TransactionScope())  
   40.       {  
   41.         _productRepository.InsertProduct(product);  
   42.         scope.Complete();  
   43.         return CreatedAtAction(nameof(Get), new { id = product.Id }, product);  
   44.       }  
   45.     }  
   46.   
   47.     [HttpPut]  
   48.     public IActionResult Put([FromBody] Product product)  
   49.     {  
   50.       if (product != null)  
   51.       {  
   52.         using (var scope = new TransactionScope())  
   53.         {  
   54.           _productRepository.UpdateProduct(product);  
   55.           scope.Complete();  
   56.           return new OkResult();  
   57.         }  
   58.       }  
   59.       return new NoContentResult();  
   60.     }  
   61.   
   62.     [HttpDelete("{id}")]  
   63.     public IActionResult Delete(int id)  
   64.     {  
   65.       _productRepository.DeleteProduct(id);  
   66.       return new OkResult();  
   67.     }  
   68.   }  
   69. }  

Entity Framework Core Migrations

Migrations allow us to provide code to change the database from one version to another.

1. Open Package Manager Console.
   
   

2. To enable the migration, type the command, Add-Migration and give that a meaningful name for e.g. InitialCreate and press enter.
   
   

3. Once the command is executed, if we look at our solution now, we see there's a new Migrations folder. And it contains two files. One, a snapshot of our current context model. Feel free to check the files. The files are very much self-explanatory.
   
   

4. To ensure that migrations are applied to the database there's another command for that. It's called the update-database If executed, the migrations will be applied to the current database.
   
   

5. Check the SQL Server Management Studio to verify if the database got created.
   
   

6. When data of the Categories table is viewed the default master data of three categories is shown.
   
   

Run the Product Microservice

The service could be run via IIS Express i.e. Visual Studio default or via Docker container as well.

Via IIS Express

Choose IIS Express in the Visual Studio as shown below and press F5 or click that IIS Express button itself.

 

The application will be up once the browser page is launched. Since it has nothing to show, it will be blank, but the service could be tested via any API testing client. Here Postman is used to testing the service endpoints. Keep it opened and application running.

 

Install Postman if it is not on the machine and launch it.

 

POST

To test the POST method; i.e. create a new resource, select the method as POST in postman and provide the endpoint, i.e. https://localhost:44312/api/product and in the Body section, add a JSON similar to having properties of Product model as shown below and click on Send.

 

The response is returned with the Id of the product as well.

 

The “Post” method of the controller is responsible to create a resource in the database and send the response.

The line return CreatedAtAction(nameof(Get), new { id=product.Id }, product); returns the location of the created resource that could be checked in Location attribute in the response under Headers tab.

 

Perform a select query on the product table and an added row is shown for the newly created product.

 

Create one more product in a similar way.

 

GET

Perform a GET request now with the same address and two records are shown as a JSON result response.

 

DELETE

Perform the delete request by selecting DELETE as the verb and appending id as 1 (if the product with id 1 needs to be deleted) and press Send.

 

In the database, one record with Id 1 gets deleted.

 

PUT

PUT verb is responsible for updating the resource. Select PUT verb, provide the API address and in the Body section, provide details of which product needs to be updated in JSON format. For example, update the product with Id 2 and update its name, description, and price from Samsung to iPhone specific. Press Send.

 

Check the database to see the updated product.

 

Via Docker Containers

Running the service could be done via docker commands to be run in docker command prompt and using visual studio as well. Since we added the docker support, it is easy to run the service in docker container using visual studio.

1. Add container orchestrator support in the solution as shown below.
   
   

2. This will ask for the orchestrator. Select Docker Compose and press OK.
   
   
   
   Once added to the solution, the solution will look like shown below having docker-compose with dockerignore and docker-compose.yml and its override file.
   
   
   
   As soon as the solution is saved, it builds the project under the container and creates a docker image. All the commands execution can be seen in the output window when the solution is saved.

3. Open the command prompt in admin mode and navigate to the same folder where the project files are.
   
   

4. Run the command docker images to see all the created images. We see the ProductMicroserviceimage the latest one.
   
   

5. Now run the application with Docker as an option as shown below.
   
   

6. Now, run the command docker ps to see the running containers. It shows the container is running on 32773:80 port.
   
   

7. Since the container is in running state, it is good to test the service now running under the container. To test the service, replace ”values” with “product” in the address as shown below. Ideally, it should get the product details. But it gives exception as shown below.
   
   

8. Running the same thing under IIS Express works fine i.e. on port 44312. Replace “values” with the product to get the product details,
   
   

9. Since in IIS Express application runs fine and not in docker container, the error clearly shows that something is wrong with the SQL server that it does not understand our docker container or it is not running under docker container. In this scenario, the docker container is running as a separate machine inside the host computer. So, to connect to the SQL database in the host machine, remote connections to SQL needs to be enabled. We can fix this.
10. Open the SQL Server Configuration Manager. Now select Protocols for MSSQLSERVER and get the IPAll port number under TCP/IP section.
    
    
    
    
    
    
    
    

11. The connection string mentioned in the JSON file points to the data source as local which the docker container does not understand. It needs proper IP addresses with port and SQL authentication. So, provide the relevant details i.e. Data Source as Ip address, port number and SQL authentication details as shown below.
    
    

12. Now again run the application with Docker as an option like done earlier.
    
    
    
    This time the response is received.

13. Test the same in the Postman.
    
    

14. Test again with IIS Express URL.
    
    

This proves that the microservice is running on two endpoints and on two operating systems independently locally deployed.

Understanding Microservices Architecture

Traditional monolithic style application architecture coupled all their functionality tightly into one service. This caused high difficulty to deploy new features as it will take long downtimes which resulted in fewer opportunities to make updates to the application. Scaling such applications are expensive because we have to scale the whole application even though only a particular service gets much traffic.

The introduction of the cloud has brought a drastic change in the way we design, architect and deploy our applications. Helped in faster deployments, improving availability, ability to scale on demand and reduced the time to market. So here comes in the Microservices-based application, which is an architecture in which the goal is to create smaller isolated services that can deploy and scale independently of each other improving the agility.

Microservices Principles

• Modelled around business domain : Microservices architecture lets us separate system capability into different domains. Each domain will focus on one thing and its associated logic and can easily migrate independently to the next version, and also scale independently according to requirement.
• Culture of Automation : As we are building, testing, deploying and monitoring each service separately and there is an increase in the number of deployment units compared to monolithic architecture we should follow the culture of automation by designing it for continues integration and continuous delivery.
• Hide implementation details : Microservices should be architected in such a way that it won’t expose the internal details; neither technical implementation nor the business rules that drive it. This will reduce the coupling and helps to do changes and improvement without affecting the overall architecture.
• Decentralization : In traditional monolithic implementations, the software is designed to use a single database with different tables where microservices is designed in such a way to manage its own database.
• Deploy Independently : To enjoy the complete benefits of the architecture, microservices should be independently deployable. If you are failing to do so, check for any coupling in the application and solve it.
• Failure Isolation : The impact of a failure is less in microservice architecture compares to monolithic type as it will only affect that particular services and its associated while other services can keep running. The associated services should handle such scenarios when dependent is unresponsive or slow.
• Highly Observable : The services should collect as much information to analyze what is happening within each of them like log events and stats.

Monolithic vs. SOA vs. Microservices

Monolithic architectures are the simplest form of architecture as it is having only one application layer that bundles together all the software components, and is hosted and delivered together. This type has been widely used by many small and mid-sized companies. The main challenge in this system is during scaling up as we need to duplicate the whole system including all the features of other machines which increases the cost. Also, the failure of one feature will affect the whole system making it unreliable.

Service Oriented Architecture (SOA) follows a coarse-grained structure where the features of an application are broken down into smaller components as services comprised of some tasks. This type of architecture allowed us to horizontally scale each service, and also more flexibility and performance at the cost of increasing the complexity of the architecture compared to the monolithic. Each service can be written in different languages and the communication between them can be done with the help of a middleware

Microservices has technically evolved out of SOA where those features are further broken down into tasks level services making it fine-grained architecture. While Service Oriented Architecture followed a centrally governed architecture where each component is controlled by a central middleware, in microservices it’s a decentralized governing system where components talk directly to each other and can be written in different programming languages and communicate without the help of any broker and are done with the help of REST API.

Microservices Architecture

An architectural style that structures an application as a collection of small self-contained processes, modelled around a business capability. They don’t share the data structure and will be communicating through APIs. While in a monolithic application all the components being in a single module, in microservices we can see all the components are divided into a separate module and communication happens with each other with the help of APIs. In Microservices Architecture the data is federated where each microservices is responsible for its own data model and data.

 Source:https://docs.microsoft.com

Being small in size, independent and loosely coupled each service can be developed and deployed independently by a small team as each service is having its own code base. Data and state persistence should be taken with each service as it lacks a separate data layer to handle it. The services only communicate with well-defined APIs hiding each service’s internal implementation from each other. Each service can use different technology stack, language, libraries or frameworks.

• Management : The Management take care of placement of services on nodes, checking for failures, rebalancing services across nodes in case of any failures.
• Service Discovery : Maintains a list of services and the nodes where each service are located, and also enables the service to look up to find the endpoint for a particular service.
• API Gateway : The entry point for clients where all the calls from the client will be taken, analyze it and forward to appropriate services. In case some calls needed from multiple services API Gateway will aggregate and will return the aggregated result.

Companies using Microservices

There are many companies using Microservices for their products and services and here is a list of few who shared their experiences.

• Comcast Cable
• Uber
• Netflix
• Amazon
• eBay
• Sound Cloud
• Karma
• Microsoft
• Groupon
• Hailo
• Gilt
• Zalando
• Lending Club
• AutoScout24

Advantages of Microservices

• Services can be written in different programming language and can be accessed by using any framework.
• Independently develop, deploy, redeploy, version and scale component services in seconds without compromising the integrity of an application
• Better fault isolation keeps other services to work even though on got failed.
• Zero downtime upgrades.
• Services can be of from different servers or even different datacenters.
• Interaction with other services in a well-defined protocol
• Monitor, capture, and report health diagnostics
• Reliable and self-healing
• Supports continuous integration and delivery
• Easy to transfer knowledge to the new team member
• Easy to integrate with third parties

Disadvantages of Microservices

• The additional complexity for implementation of an inter-process communication mechanism between services.
• Writing automated tests involving multiple services is challenging and It can be difficult to create consistent testing environments.
• Requires high level of automation to manage multiple instances of different types of services in production.
• Everyone has to manage eventual consistency as maintaining string consistency becomes extremely difficult.
• Managing multiple databases and their transactions are difficult.
• Inter-process calls are slow.
• Debugging will become difficult.
• Complexity in DevOps.
• Production monitoring cost is higher.
• Formal documentation overhead.
• Lack of governance.

What Is Microservices – Introduction To Microservice Architecture

Why Microservices?

Now, before I tell you about microservices, let’s see the architecture that prevailed before microservices i.e. the Monolithic Architecture.

In layman terms, you can say that its similar to a big container wherein all the software components of an application are assembled together and tightly packaged.

Listed down are the challenges of Monolithic Architecture:

Figure 1: What Is Microservices – Challenges of Monolithic Architecture

• • Inflexible – Monolithic applications cannot be built using different technologies 
  • Unreliable – Even if one feature of the system does not work, then the entire system does not work
  • Unscalable – Applications cannot be scaled easily since each time the application needs to be updated, the complete system has to be rebuilt
  • Blocks Continous Development – Many features of the applications cannot be built and deployed at the same time
  • Slow Development – Development in monolithic applications take lot of time to be built since each and every feature has to be built one after the other
  • Not Fit For Complex Applications – Features of complex applications have tightly coupled dependencies

The above challenges were the main reasons that led to the evolution of microservices. 

What Is Microservices?

Microservices, aka Microservice Architecture, is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

 Figure 2: What Is Microservices – Microservices Representation

In Microservice Architecture, each service is self-contained and implements a single business capability.

Differences Between Traditional Architecture and Microservices

Consider an E-commerce application as a use-case to understand the difference between both of them.

 Figure 3: What Is Microservices – Differences Between Monolithic Architecture and Microservices

The main difference we observe in the above diagram is that all the features initially were under a single instance sharing a single database. But then, with microservices, each feature was allotted a different microservice, handling their own data, and performing different functionalities. 

 Now, let us understand more about microservices by looking at its architecture. Refer the diagram below:

Microservice Architecture 

Figure 4: What Is Microservices – Microservice Architecture

• Different clients from different devices try to use different services like search, build, configure and other management capabilities
• All the services are separated based on their domains and functionalities and  are further allotted to individual microservices
• These microservices have their own load balancer and execution environment to execute their functionalities & at the same time captures data in their own databases
• All the microservices communicate with each other through a stateless server which is either REST or Message Bus
• Microservices know their path of communication with the help of Service Discovery and perform operational capabilities such as automation, monitoring
• Then all the functionalities performed by microservices are communicated to clients via API Gateway
• All the internal points are connected from the API Gateway. So, anybody who connects to the API Gateway automatically gets connected to the complete system

Now, let us learn more about microservices by looking at its features.

Microservices Features

Figure 5: What Is Microservices – Features Of Microservices

• Decoupling – Services within a system are largely decoupled. So the application as a whole can be easily built, altered, and scaled
• Componentization – Microservices are treated as independent components that can be easily replaced and upgraded
• Business Capabilities – Microservices are very simple and focus on a single capability 
• Autonomy – Developers and teams can work independently of each other, thus increasing speed
• Continous Delivery – Allows frequent releases of software, through systematic automation of software creation, testing, and approval 
• Responsibility – Microservices do not focus on applications as projects. Instead, they treat applications as products for which they are responsible 
• Decentralized Governance – The focus is on using the right tool for the right job. That means there is no standardized pattern or any technology pattern. Developers have the freedom to choose the best useful tools to solve their problems 
• Agility – Microservices support agile development. Any new feature can be quickly developed and discarded again

Advantages Of Microservices

Figure 6: What Is Microservices – Advantages Of Microservices

• Independent Development – All microservices can be easily developed based on their individual functionality
• Independent Deployment – Based on their services, they can be individually deployed in any application 
• Fault Isolation – Even if one service of the application does not work, the system still continues to function
• Mixed Technology Stack – Different languages and technologies can be used to build different services of the same application
• Granular Scaling –  Individual components can scale as per need, there is no need to scale all components together

Best Practices To Design Microservices

In today’s world, complexity has managed to creep into products. Microservice architecture promises to keep teams scaling and function better.

The following are the best practices to design microservices:

Figure 7: What Is Microservices – Best Practices To Design Microservices 

Now, let us look at a use-case to get a better understanding of microservices.

Use-Case: Shopping Cart Application

Let’s take a classic use case of a shopping cart application.

When you open a shopping cart application, all you see is just a website. But, behind the scenes, the shopping cart application has a service for accepting payments, a service for customer services and so on. 

Assume that developers of this application have created it in a monolithic framework.Refer to the diagram below:

Figure 8: What Is Microservices – Monolithic Framework Of Shopping Cart Application

So, all the features are put together in a single code base and are under a single underlying database.

Now, let’s suppose that there is a new brand coming up in the market and developers want to put all the details of the upcoming brand in this application.

Then, they not only have to rework on the service for new labels, but they also have to reframe the complete system and deploy it accordingly.

To avoid such challenges developers of this application decided to shift their application from a monolithic architecture to microservices.Refer to the diagram below to understand the microservices architecture of shopping cart application

Figure 9: What Is Microservices – Microservice Architecture Of Shopping Cart Application

This means that developers don’t create a web microservice, a logic microservice, or a database microservice. Instead, they create separate microservices for search, recommendations, customer services and so on.

This type of architecture for the application not only helps the developers to overcome all the challenges faced with the previous architecture but also helps the shopping cart application to be built, deployed, and scale up easily.

Companies using Microservices

There is a long list of companies using Microservices to build applications, these are just to name a few: 

Notable Changes in Angular 9

1) Ivy applications: Previously, in applications, Hammer providers were included by default. With this commit, apps that want Hammer support must import HammerModule in their root module i.e.

 import {HAMMER_PROVIDERS} from './dom/events/hammer_gestures' 

2) ServiceWorker: Remove deprecated option versionedFiles from service worker asset group configuration in ngsw-config.json. 

3) Performance Improvements:

• Ivy: don’t store public input names in two places.
• Ivy: fix creation time micro-benchmarks.
• Ivy: Improve performance of transplanted views.
• Ivy: avoid native node retrieval from LView.
• Ivy: avoid repeated native node retrieval and patching.
• Ivy:avoid repeated tNode.initialInputs reads.
• Ivy:move local references into consts array.
• Ivy: R3TestBed – Do not process NgModuleDefs that have already been processed.

Bug Fixes

1) Common: update $locationShim to notify onChange listeners before emitting AngularJS events.

2) Compiler: return enableIvy true when using readConfiguration.

3) Ivy:

• Get name directly from nativeNode.
• Handle empty bindings in template type checker.
• In ngcc, handle inline exports in commonjs code.
• The ngcc should only index .d.ts exports within the package.
• The ngTemplateOutlet error when switching between null and template value.

4) language-service:

• Instantiate MetadataResolver once.
• Remove "context" used for module resolution. 

5) Ngcc:

• Handle deep imports that already have an extension.
• Ignore format properties that exit but are undefined.

Angular 9 Features

• Smaller bundles and better performance.
• Added undecorated classes migration schematic in the core.
• Support for TypeScript Diagnostics Format.
• The formControlName also accepts a number in the form.
• Internationalization support for Angular Ivy.
• Selector-less directives as base classes in View Engine in the compiler.
• Added support for selector-less directive as base classes in Ivy.
• Ivy compiler is now the default for ngc.
• Convert all ngtsc diagnostics to ts.Diagnostics.
• Bazel: support ts_library targets as entry-points for ng_package.
• Core: add dynamic queries schematic.
• Core: Mark TestBed.get as deprecated.
• Ivy: expose window.ng.getDebugNode helper and also support ng-add in localize package.
• Ivy: i18n —add syntax support for $localize metadata block.
• Ivy: i18n — reorganize entry-points for better reuse.
• Language-service: enable logging on TypeScriptHost.
• Language-service: provide diagnostic for invalid templateUrls.
• Language-service: provide diagnostics for invalid styleUrls.