The order manager is a microservice that processes the orders that the customer places through the UI. As you probably remember, we are not going to create a sophisticated single-page application with a modern visual framework, as it is out of the scope of this book, but we are going to provide the JSON interface in order to be able to build the front end later.
Order manager introduces an interesting problem: this microservice needs access to the information about products, such as name, price, availability, and so on. However, it is stored in the product manager microservice, so how do we do that?
Well, the answer for this question might look simple, but requires a bit of thinking.
Our microservice will need to do the following three things:
- Recover orders
- Create orders
- Delete existing orders
When recovering an order, the option is going to be simple. Recover the order by the primary key. We could extend it to recover orders by different criteria, such as price, date, and so on, but we are going to keep it simple as we want to focus on microservices.
When deleting existing orders, the option is also clear: use the ID to delete orders. Again, we could choose a more advanced deletion criteria, but we want to keep it simple.
The problem arises when we are trying to create orders. Creating an order in our small microservice architecture means sending an e-mail to the customer, specifying that we are processing their order, along with the details of the order, as follows:
- Number of products
- Price per product
- Total price
- Order ID (in case the customer needs to troubleshoot problems with the order)
How do we recover the product details?
If you see our diagram shown in the Micromerce – the big picture section of this chapter, order manager will only be called from the UI, which will be responsible to recover the product name, its price, and so on. We could adopt the following two strategies here:
- Order manager calls product manager and gets the details
- UI calls product manager and delegates the data to the order manager
Both options are totally valid, but in this case, we are going for the second: UI will gather the information needed to generate an order and it will only call the order manager when all the data required is available.
Now to answer the question: why?
A simple reason: failure tolerance. Let's take a look at the following sequence diagram of the two options:
The diagram for the second option is shown as follows:
In the first view, there is a big difference: the depth of the call; whereas in the first example, we have two levels of depth (UI calls the order manager, which calls the product manager). In the second example, we have only one level of depth. There are a few immediate effects in our architecture, as follows:
- When something goes wrong, if we only have one level of depth, we don't need to check in too many places.
- We are more resilient. If something goes wrong, it is the UI of the microservice that notices it, returning the appropriate HTTP code, in this case, without having to translate the errors that occurred a few levels above the client-facing microservice.
- It is easier to deploy and test. Not much easier, but we don't need to juggle around, we can see straight away if the product manager is reached from the UI, instead of having to go through the order manager.
The fact that we are using this architecture instead of the two-level depth does not mean that it isn't appropriate for another situation: the network topology is something that you need to plan ahead if you are creating a microservices-oriented architecture, as it is one of the hardest aspects to change.
In some cases, if we want to be extremely flexible, we can use a messaging queue with publisher/subscriber technology where our microservices can subscribe to different types of messages and emit others to be consumed by a different service, but it could complicate the infrastructure that we need to put in place to avoid single point of failures.
Let's take a look at the code for the order manager:
var plugin = function(options) {
var seneca = this;
seneca.add({area: "orders", action: "fetch"}, function(args, done) {
var orders = this.make("orders");
orders.list$({id: args.id}, done);
});
seneca.add({area: "orders", action: "delete"}, function(args, done) {
var orders = this.make("orders");
orders.remove$({id: args.id}, function(err) {
done(err, null);
});
});
}
module.exports = plugin;As you can see, there is nothing complicated about the code. The only interesting point is the missing code from the create action.
Until now, we have assumed that all our microservices run in the same machine, but that is far from ideal. In the real world, microservices are distributed and we need to use some sort of transport protocol to carry the message from one service to another.
Seneca, as well as nearForm, the company behind Seneca, has sorted this problem for us and the open source community around it.
As a modular system, Seneca has embedded the concept of plugin. By default, Seneca comes with a bundled plugin to use TCP as the protocol, but it is not hard to create a new transport plugin.
Note
While writing this book, I created one by myself: https://github.com/dgonzalez/seneca-nservicebus-transport/
With this plugin, we could route the Seneca messages through NServiceBus (a .NET-based Enterprise Bus), changing the configuration of our client and server.
Let's see how to configure Seneca to point to a different machine:
var senecaEmailer = require("seneca")().client({host: "192.168.0.2", port: 8080});By default, Seneca will use the default plugin for transport, which as we've seen in Chapter 2, Microservices in Node.js – Seneca and PM2 Alternatives, is tcp, and we have specified it to point to the 192.168.0.2 host on the 8080 port.
As simple as that, from now on, when we execute an act command on senecaEmailer, the transport will send the message across to the e-mailer and receives the response.
Let's see the rest of the code:
seneca.add({area: "orders", action: "create"}, function(args, done) {
var products = args.products;
var total = 0.0;
products.forEach(function(product){
total += product.price;
});
var orders = this.make("orders");
orders.total = total;
orders.customer_email = args.email;
orders.customer_name = args.name;
orders.save$(function(err, order) {
var pattern = {
area: "email",
action: "send",
template: "new_order",
to: args.email,
toName: args.name,
vars: {
// ... vars for rendering the template including the products ...
}
}
senecaEmailer.act(pattern, done);
});
});As you can see, we are receiving a list of products with all the data needed and passing them to the e-mailer to render the e-mail.
If we change the host where the e-mailer lives, the only change that we need to do here is the configuration of the senecaEmailer variable.
Even if we change the nature of the channel (we could potentially even write a plugin to send the data over Twitter, for example), the plugin should look after the particularities of it and be transparent for the application.
In the example from the preceding section, we built a microservice that calls another microservice in order to resolve the call that it receives. However, the following points need to be kept in mind:
- What happens if the e-mailer is down?
- What happens if the configuration is wrong and the e-mailer is not working on the correct port?
We could be throwing what ifs for few pages.
Humans are imperfect and so are the things that they build, and software is not an exception. Humans are also bad at recognizing the potential problems in logical flows, and software tends to be a complex system.
In other languages, playing with exceptions is almost something normal, but in JavaScript, exceptions are a big deal:
- If an exception bubbles out in a web app in Java, it kills the current stack of calls and Tomcat (or the container that you use) returns an error to the client
- If an exception bubbles out in a Node.js app, the application is killed as we only have one thread executing the app
As you can see, pretty much every single callback in Node.js has a first parameter that is an error.
When talking about microservices, this error is especially important. You want to be resilient. The fact that an e-mail has failed sending does not mean that the order cannot be processed, but the e-mail could be manually sent later by someone reprocessing the data. This is what we call eventual consistency; we factor into our system the fact that at some point our system is going to crash.
In this case, if there is a problem sending the e-mail, but we could store the order in the database, the calling code, in this case the UI, should have enough information to decide whether the customer gets a fatal message or just a warning:
Your order is ready to be processed, however it might take us two days to send you the e-mail with the order details. Thanks for your patience.
Usually, the fact that our application will keep working even if we cannot complete a request, it is usually more business than technical decision. This is an important detail, as when building microservices, Conway's law is pushing us, the technical people, to model the existing business process and partial success maps perfectly to the human nature. If you can't complete a task, create a reminder in Evernote (or a similar tool) and come back to it once the blocker is resolved.
This reads much better than the following:
Something happened about something, but we can't tell you more (which is what my mind reads sometimes when I get a general failure in some websites).
We call this way of handling errors system degradation: it might not be 100% functional, but it will still work even though its few features are not available, instead of a general failure.
If you think for a second, how many times a web service call has rolled back a full transaction in your big corporate system only because it couldn't reach a third-party service that might not even be important?
In this section, we built a microservice that uses another microservice to resolve a request from a customer: order manager uses e-mailer to complete the request. We have also talked about resilience and how important it is in our architecture in order to provide the best service.