Node.js 8 the Right Way

Wrapping Up

We covered a lot of ground in this chapter, so let’s review.

Using ØMQ with Node.js gave us an opportunity to install and use a module from npm that included native addon code. This provided a basis for learning about three fundamental microservice messaging patterns: publish/subscribe, push/pull, and request/reply.

To overcome the lockstep nature of ØMQ’s request/reply implementation, we learned how to parallelize requests using a dealer/router pair. This gave us a chance to use JavaScript’s rest parameter syntax to capture variadic function arguments.

You also learned how to fork Node.js processes to create a cluster of cooperating processes. This introduced new challenges like the first-joiner problem and the limited-resource problem.

The following bonus tasks ask you to modify and create new Node.js and ØMQ programs using what you learned from the chapter.

Error Handling

The zmq-filer-rep.js program we created uses fs.readFile to serve up file contents. However, it doesn’t handle error cases at all.

What should the program do in the case of an error?
How would you change the JSON object structure of messages to support sending an error to the requester?

Later in this same program, we listen for the Unix signal SIGINT to detect the user’s Ctrl-C in the terminal.

What happens if the program ends in some other way, like SIGTERM (the termination signal)?
What happens if there’s an unhandled Node.js exception, and how should we deal with it? Hint: you can listen for the uncaughtException event on the process object.

Robustness

In Building a Cluster, we created a Node.js cluster that spins up a pool of worker processes. In the master process, we listened for online events and logged a message when the workers came up. But we didn’t specify what should happen when a worker process ends.

What happens when you kill a worker process from the command line? Hint: use kill [pid] from the command line, where [pid] is the worker’s process ID.
How would you change the zmq-filer-rep-cluster.js program to fork a new worker whenever one dies?

Bidirectional Messaging

For this project, you’ll need to use ØMQ PUSH/PULL sockets and the Node.js clustering techniques you learned in this chapter.

Your clustered program will spin up a pool of workers and distribute 30 jobs between them. Although this seems like a lot to do, the whole program should be fewer than 100 lines of code.

Create a Node.js program that uses the cluster and zmq modules and does the following:

The master process should

Create a PUSH socket and bind it to an IPC endpoint—this socket will be for sending jobs to the workers.
Create a PULL socket and bind to a different IPC endpoint—this socket will receive messages from workers.
Keep a count of ready workers.

Listen for messages on the PULL socket, and
- if the message is a ready message, increment the ready counter, or
- if the message is a result message, output it to the console.

Spin up the worker processes.
When the ready counter reaches 3, send 30 job messages out through the PUSH socket.

Each worker process should

Create a PULL socket and connect it to the master’s PUSH endpoint.
Create a PUSH socket and connect it to the master’s PULL endpoint.
Listen for job messages on the PULL socket, and respond by sending a result message out on the PUSH socket.
Send a ready message out on the PUSH socket.

Make sure your result messages include at least the process ID of the worker. This way you can inspect the console output and confirm that the workload is being balanced among the worker processes.

If you get completely stuck, consult the working example available in the downloadable code that accompanies this book. You can do it. Good luck!