Microservices in node js

1)What is microservices?
Microservices are an architectural approach based on building an application as a collection of small services.
2)Microservices architecture-Compared to its predecessor, the monolithic architecture, microservices are hands down more beneficial. You don’t need to stuff all software components and services in one big container and pack them tightly. With microservices, you can build an app with:

greater flexibility,
high scalability,
continuous development,
systematic data organization,
time optimization, and
reliability.

Building JavaScript applications on microservices help you focus on developing monofunctional modules with clearly defined operations and precise interfaces. The application development process becomes more agile, and the challenges of continuous testing are mitigated.
3)Key benefits of Node.js

Single-threaded: With event looping, the server uses a non-blocking mechanism to respond.
Super-fast: Codes are executed quickly on the V8 JavaScript Engine
Event-driven: ‘Events of Node.js’ is a notification system that enables the application server to capture the response of the previous API call.
Buffer-less: There is no buffering as data is simply released in chunks.
Asynchronous: The non-blocking, non-synchronous Node.js libraries move to the next API and do not await the return data of the previous API.
Highly-scalable: Servers can handle as many requests as coming their way
Licensed: The program is authorized under a software license.
4)The service registry
The service registry is a database populated with information on how to dispatch requests to microservice instances. Interactions between the registry and other components can be divided into two groups, each with two subgroups:

Interactions between microservices and the registry (registration)
Self-registration
Third-party registration
Interactions between clients and the registry (discovery)
Client-side discovery
Server-side discovery
Registration

Most microservice-based architectures are in constant evolution. Services go up and down as development teams split, improve, deprecate and do their work. Whenever a service endpoint changes, the registry needs to know about the change. This is what registration is all about: who publishes or updates the information on how to reach each service.

Self-registration forces microservices to interact with the registry by themselves. When a service goes up, it notifies the registry. The same thing happens when the service goes down. Whatever additional data is required by the registry must be provided by the service itself. If you have been following this series, you know that microservices are all about dealing with a single concern, so self-registration might seem like an anti-pattern. However, for simple architectures, self-registration might be the right choice.

-Third-party registration - is normally used in the industry. In this case, there is a process or service that manages all other services. This process polls or checks in some way which microservice instances are running and it automatically updates the service registry. Additional data might be provided in the form of per-service config files (or policy), which the registration process uses to update the database. Third-party registration is commonplace in architectures that use tools such as Apache ZooKeeper or Netflix Eureka and other service managers.

-Discovery-
As you can imagine, discovery is the counterpart to registration from the point of view of clients. When a client wants to access a service, it must find out where the service is located (and other relevant information to perform the request).
Client-side discovery forces clients to query a discovery service before performing the actual requests. As happens with self-registration, this requires clients to deal with additional concerns other than their main objective. The discovery service may or may not be located behind the API gateway. If it is not located behind the gateway, balancing, authentication and other cross-cutting concerns may need to be re-implemented for the discovery service. Additionally, each client needs to know the fixed endpoint (or endpoints) to contact the discovery service. These are all disadvantages. The one big advantage is not having to code the necessary logic in the gateway system. Study this carefully when picking your discovery method.
Server-side discovery makes the API gateway handle the discovery of the right endpoint (or endpoints) for a request. This is normally used in bigger architectures. As all requests are directly sent to the gateway, all the benefits discussed in relation to it apply. The gateway may also implement discovery caching, so that many requests may have lower latencies. The logic behind cache invalidation is specific to an implementation.

"Server-side discovery makes the API gateway handle the discovery of the right endpoint for a request."

A registration library
Here is the main logic of our library:

module.exports.register = function(service, callback) {    
    if(!validateService(service)) {
        callback(new Error("Invalid service"));
    }

    findExisting(service.name, function(err, found) {
        if(found) {
            callback(new Error("Existing service"));
            return;
        }

        var dbService = new Service({
            name: service.name,
            url: service.url,
            endpoints: service.endpoints,
            authorizedRoles: service.authorizedRoles
        });

        dbService.save(function(err) {
            callback(err);
        });
    });
}

module.exports.unregister = function(name, callback) {
    findExisting(name, function(err, found) {
        if(!found) {
            callback(new Error("Service not found"));
            return;
        }

        found.remove(function(err) {
            callback(err);
        });
    });
}