TypeScript Microservices

Build, deploy, and secure Microservices using TypeScript combined with Node.js

Parth Ghiya

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788836852
• Edition: 1
• Topic: Informatica
• Subtopic: Programmazione in JavaScript

Build robust microservice-based applications that are distributed, fault tolerant, and always availableAbout This Book• Learn to build message-driven services for effective communication• Design microservices API using Reactive programming design patterns• Deploy, scale and monitor microservices for consistent high performanceWho This Book Is ForThis book is for JavaScript developers seeking to utilize their Node.js and Typescript skills to build microservices and move away from the monolithic architecture. Prior knowledge of TypeScript and Node.js is assumed.What You Will Learn• Get acquainted with the fundamentals behind microservices.• Explore the behavioral changes needed for moving from monolithic to microservices.• Dive into reactive programming, Typescript and Node.js to learn its fundamentals in microservices• Understand and design a service gateway and service registry for your microservices.• Maintain the state of microservice and handle dependencies.• Perfect your microservice with unit testing and Integration testing• Develop a microservice, secure it, deploy it, and then scale itIn DetailIn the last few years or so, microservices have achieved the rock star status and right now are one of the most tangible solutions in enterprises to make quick, effective, and scalable applications. The apparent rise of Typescript and long evolution from ES5 to ES6 has seen lots of big companies move to ES6 stack. If you want to learn how to leverage the power of microservices to build robust architecture using reactive programming and Typescript in Node.js, then this book is for you.Typescript Microservices is an end-to-end guide that shows you the implementation of microservices from scratch; right from starting the project to hardening and securing your services. We will begin with a brief introduction to microservices before learning to break your monolith applications into microservices. From here, you will learn reactive programming patterns and how to build APIs for microservices. The next set of topics will take you through the microservice architecture with TypeScript and communication between services. Further, you will learn to test and deploy your TypeScript microservices using the latest tools and implement continuous integration. Finally, you will learn to secure and harden your microservice.By the end of the book, you will be able to build production-ready, scalable, and maintainable microservices using Node.js and Typescript.Style and approachThis book will be a step by step easy to follow guide with focused examples for building microservices with Typescript.

Beginning Your Microservice Journey

Microservices are one of the most tangible solutions in an enterprise to make quick, effective, and scalable applications. However, if they are not properly designed or understood, incorrect implementations and interpretations can lead to disastrous or irrecoverable failures. This chapter will begin our microservices journey by getting our hands dirty and diving deep into practical implementations.

The chapter will start with a description of shopping microservices, which we are going to develop throughout our journey. We will learn how to slice and dice a system into a connected set of microservices. We will design the overall architecture of our shopping cart microservices, define separation layers, add cache levels, and more.

This chapter will cover the following topics:

• Overview of shopping cart microservices
• Architecture design of shopping cart microservices
• Implementation plan for shopping cart microservices
• Schema design and database selection
• Microservice predevelopment aspects
• Developing some microservices for the shopping cart
• Microservice design best practices

Overview of shopping cart microservices

The most important aspect while working on a new system is its design. A poor initial design is always a leading cause of more challenges ahead. Rather than moaning later, solving errors, or applying patches to cover up a poor design, it is always wise not to rush through the design process, spend enough time, and have a flexible fool-proof design. This can only be achieved by understanding the requirements clearly. In this section, we will give a brief overview of shopping cart microservices; the problem we need to solve via microservices; and an overview of the business process, functional view, and deployment and design views.

Business process overview

The use case for our scenario is pretty straightforward. The following process diagram shows the end-to-end shopping process that we need to convert to microservices. The user adds an item to the cart, the inventory is updated, the user pays for the item, and then is able to check out. There are several validations involved, based on business rules. For example, if the user's payment fails, then they should not be able to check out; if the inventory is not available, then the item should not be added to the cart and so on. Take a look at the following diagram:

Business process overview

Functional view

Each business capability and its sub-capabilities are shown in a row, which essentially constitutes the shopping cart microservices. Some sub-capabilities are involved in more than one business capability and hence we need to manage some cross-cutting concerns. For example, an inventory service is used both as a separate process and when a person checks out a product. The following diagram shows the functional view of the shopping cart microservices:

Functional view

The diagram combines the business capabilities into one picture. For example, the inventory service states there are two sub-functions—add product details and add product quantity and inventory items. That summarizes the inventory service's objectives. Creating a functional view for our system gives us a clear understanding of all the business processes and related things involved in them.

Deployment view

The requirement for deployment is pretty straightforward. Based on demand, we need to add new services to support various business capabilities on the fly. Say, for example, right now the payment medium is PayPal, but it may happen in the future that we also need to support some local payment options, such as bank wallets. At that time, we should easily be able to add new microservices without disrupting the entire ecosystem. The following diagram shows the deployment view. Right now, there are two nodes (one master and one slave), but based on demand, the number of nodes may increase or decrease based on the business capabilities, a spike in traffic, and other requirements:

Deployment view

In this section, we got a brief overview of our shopping cart microservice system. We understood its functional, business process, and deployment views. In the next section, we will see the architecture design of the shopping cart microservices.

Architecture design of our system

In this section, we will look at the architectural aspects involved in distributed microservices. We will look at our overall architecture diagram, which we are going to make throughout the book, and look at aspects such as separating concerns, how to apply reactive patterns, and the microservice efficiency model. So, let's get started.

Now that we know our business requirements, let's design our architecture. Based on our knowledge of microservices and other concepts from Chapter 1, Debunking Microservices, we have the final overall diagram, as shown here:

Microservice architecture

We will study components such as API Gateway, service registry, and discovery in much more detail in later chapters. Here, they are just mentioned as part of the overall view.

Let's understand the key components in the preceding diagram to get a better idea of our architecture.

Different microservices

If we understood our business requirements correctly, we will come up with the following business capabilities:

• Product catalog
• Price catalog
• Discounts
• Invoice
• Payment
• Inventory

Based on our business capabilities and single responsibility, we divided our microservices briefly into various smaller applications. In our design, we ensured that each business capability is implemented by a single microservice and we don't overload a microservice with more than one microservice. We briefly divided our entire system into various microservices, such as a shopping cart microservice, products microservice, payment microservice, consumer microservice, cache microservice, price calculations and suggestions microservice, and so on. The overall granular flow can be seen in the preceding diagram. Another important thing to notice is that each microservice has its separate data store. Different business capabilities have different needs. For example, when a person checks out a product, if the transaction failed, then all transactions such as adding a product to a customer's purchase item, deducting quantity from a product inventory, and so on should be rolled back. In this case, we need relational databases that can handle transactions, whereas in the case of products, our metadata constantly changes. Some products may have more features than other products. In such cases, having a fixed relational schema is not wise and we can go for NoSQL data stores.

At the time of writing this book, MongoDB 4.0 had not yet been introduced. It provides the following transactional plus NoSQL benefits in one.

Cache microservice

The next component that we are going to see is centralized cache storage. This microservice directly interacts with all microservices and we may use this service to cache our responses when needed. Often it may happen that a service goes down, and we may still preserve the application by showing cached data (things such as product information and metadata rarely change; we may cache them for a certain interval of time, thus preventing an extra database hop). Having a cache increases the performance and availability of the system, which ultimately leads to cost optimization. It provides a blazing fast user experience. As microservices are constantly moving, often they may not be reached. In such cases, it is always advantageous to have a cached response when reaching out to availability zones fails.

Service registry and discovery

At the start of the diagram, we included the service registry. This is a dynamic database maintained on the startup and shutdown events of all microservices. Services subscribe to the registry and listen for updates to know whether the service has gone down or not. The entire process is done through the service registry and discovery. The registrator updates the registry whenever a service goes down or goes up. This registry is cached on all clients who subscribe to the registry, so whenever a service needs to be interacted with, an address is fetched from this registry. We will look in detail at this process in Chapter 6, Service Registry and Discovery.

Registrator

The next component that we are going to look at, which is available alongside the cache, is the Registrator (http://gliderlabs.github.io/registrator/latest/). The Registrator is a third-party service registration tool that basically watches for startup and shutdown events of microservices and, based on the output of those events, dynamically updates the centralized service registry. Different services can then directly communicate with the registry to get updated locations of services. The Registrator ensures that registration and deregistration code is not duplicated across systems. We will look at this in more detail in Chapter 6, Service Registry and Discovery, where we integrate the Registrator with the consul.

Logger

One of the important aspects of any application is the logs. Analyzing any problem becomes very easy when appropriate logs are used. Hence, here we have a centralized logger microservice that is based on the famous Elastic framework. Logstash watches for log files and transforms them into appropriate JSON before pushing to Elasticsearch. We can visualize the logs through the Kibana dashboard. Each microservice will have its unique UUID or some log pattern configured. We will look at this in much more detail in Chapter 9, Deployment, Logging, and Monitoring.

Gateway

This is the most important part and the starting point of our microservices. It is the central point where we will handle cross-cutting concerns, such as authentication, authorization, transformation, and so on. W...