Using Node.js

The beauty of good server side service is that no action will be taken without validation. If a validation fails, an error will be returned to the client. Also checks all the sub processes or task types, checks what data is needed and only sends the task through to the task registry if and when validation is received. This is all speedy and happens without the client knowing what is going on behind the scenes. It’s computer science at its best.

How do Service Sub Processes work?

A number of service sub processes will start dynamically, as needed. Node.js. will communicate in computer language, receiving the activations of logs, tasks, errors or exit codes. It will restart or disconnect or activate on action. Node.js can use fewer resources by controlling how many instances are working at the same time.

See the below diagram.

Resource: https://thebittheories.com/rails-vs-nodejs-the-comparison-feba9081251f

How does Node.js provide scalability while remaining fail proof?

It is easy to do this. Take a look below where a new instance was created and immediately logged the information. Through the error, the Master Process (router) received the errors and checked them to see if they were sub process disconnections. The task is then marked to try again and to the sub process is restarted.

Complicated? Not at all. It is easy to set up, easy to code, easy to manage.

What is the Task Registry?

This is the storage are for all the tasks and all the data. It is an NoSQL database which means it fits an incredible amount of data and has a huge storage space. It is efficient and comfortable with all the storage and is fail-safe. When we say fail-safe (more so than just in-memory storage) remember that everything has a date and time and of course updates must be done as needed.

What are the Service Instances?

These are the centers where the jobs or tasks are actually done or activated. The service instances check the task registry for the incoming jobs, and this happens so quickly it is almost ongoing – every N seconds the tasks are checked. When a new task comes in, the Master Process is notified by means of a ‘unique task’ identifier. It is then marked as ‘in progress’ and is an important part of why everything is fail-safe.

All the tasks that come in are pre-defined. They are shared between the router or Master Process, the task registry and the service instances. It is a modular design, a group of modules, that allow tasks to be added or removed. It is therefore fluid.