We have been learning about how to build robust microservices-oriented software, and now it is time to put all the concepts to practice. In this chapter, we are going to build a microservices-oriented e-commerce using Seneca and some other frameworks that are going to allow us to write a software that will benefit from the particularities of the microservices.
It covers the following:
- Writing microservices
- Sizing microservices
- Creating APIs
- Integrating Seneca with Express
- Storing data using Seneca
In this chapter, we are going to write a full (nearly) simplistic e-commerce solution based on microservices. Full means full from the conceptual point of view, but for obvious reasons, it won't be full (as production ready) as it could take us a few books to handle all the possible flows.
We won't go deep in to the UI, as it is not related to the subject of this book. What we will do instead is a microservice that will aggregate all the other microservices, creating a frontend API to be consumed by a Single-Page Application (SPA), built with any of the modern JavaScript frameworks.
In this chapter, we are going to develop the following four microservices:
- Product Manager: This microservice will be responsible for adding, editing, and removing products from our database, as well as serving products to the customers. This microservice will be partially public for a potential admin site to add/remove products.
- Order Manager: This microservice will be responsible for managing the order and billing.
- Emailer: This microservice will be responsible for delivering e-mails to the customers.
- UI: This microservice will expose the feature from the other microservices to a potential SPA, but we will only build the JSON interface.
Building the four preceding microservices, we will develop the concepts discussed in the previous chapters so that, by the end of this chapter, we will be able to identify the most common pitfalls going forward. Keep in mind that the objective of this book is not converting you into a microservices or Node.js expert, but to give you the tools required to learn by yourself, as well as make you aware of the best design principles and the most common pitfalls.
Let's take a look at the deployment diagram:
This diagram shows how our company (the yellow square) hides some of our microservices from the real world and exposes some others to different networks, as follows:
- UI will be exposed to the Internet. Everybody will be able to hit this endpoint.
- Product Management will manage the products in our e-commerce. It will have the following two interfaces:
- A Seneca endpoint from where the UI will extract data
- A JSON API from where the office of our company will be able to create, update, and delete products
- Emailer will be our communication channel with our customers. We will use this microservice to explain the good points of Seneca, and we will also give an example of the eventual consistency and system degradation when a microservice fails.
- Order Manager: This microservice will let us handle the orders for our customers. With this microservice, we will discuss how to handle the fact that the data is local to each microservice, instead of being global to the system. You can't just go to the database to recover the product name or price, it needs to be recovered from other microservice.
Tip
As you can see, there is no user or staff management, but with these four microservices, we will be able to develop the core concepts of microservices architectures. Seneca comes with a very powerful data and transport plugin system that makes it easy to use Seneca with different data storages and transport systems.
For all our microservices, we are going to use MongoDB as the storage. Seneca comes with an out-of-the-box in-memory database plugin that allows you to start coding straightaway, but the storage is transient: it does not persist the data between calls.