node.js loops, tests, and architecture

Michael Scoggins
4 min readSep 14, 2020

Can you explain the purpose of each type of HTTP Request when using a RESTful web service?

Create: this is the POST method, and allows users to add to an API
Read: this is your GET method, and allows users to simply “read” data
Update: this is your PUT method, and allows users to update info
Delete: this is your DELETE method, and allows users to delete info (or oftentimes pseudo-delete since rarely do websites/apps actually forego free user information, and it’s possible the user wants to reactivate their account)

What’s a test pyramid? How can you implement it when talking about HTTP APIs?

automated testing is resource- and time-consuming. the test pyramid is a model by which UI tests are implemented. its shape (a pyramid) implies that you want a strong base upon which each “stack” is balanced. a test pyramid is comprised of unit tests, integration tests, and service tests. there is also acceptance testing, but that is mostly just manual UX testing done after the product is virtually complete. this composition changes a little depending on the situation, but these are close enough. in the following visual, Unit refers to unit and integration tests, Service refers to full-product testing, and UI refers to end-to-end tests which simulate the entire user experience. the general idea is that you want to have mostly unit tests, some integration tests, few service tests, and even fewer end-to-end — or UI— tests. unit tests run fast and are cheap, end-to-end tests are slow and expensive.

https://martinfowler.com/bliki/TestPyramid.html

unit testing comes down to the smallest units (go figure) of a program, which are generally the grassroots functions which comprise each feature, or story. the unit test is itself a function that tests the logical conclusion of several other functions whose jobs are to reach said logical conclusion (read the sentence one more time, i promise it makes sense😇).

integration testing is the testing of each feature (story) in the context of your program plus other features, and also on different platforms and in different environments. if you finish a few stories, you would integrate them one by one into your working codebase, making sure none of the new features breaks anything — and if they do, then you already have your problem isolated.

service testing is testing all of your integrated features as a cohesive system.

UI and acceptance testing is the tip of the pyramid where testing is done to ensure the product is ready for end-users. every feature is tested, from the bottom-up. this gets very complicated, very quickly. don’t believe me? per Wikipedia:

Unlike a CLI (command line interface) system, a GUI may have additional operations that need to be tested. A relatively small program such as Microsoft WordPad has 325 possible GUI operations.[1] In a large program, the number of operations can easily be an order of magnitude larger.

the bit about an order of magnitude larger means it would be 325x325 times larger.

What is the “demultiplexer”? What’s the difference between “blocking” and ‘non-blocking’ functions?

in node.js, the demultiplexer (which i’ll return to in a minute) is a mechanism within the Reactor Pattern model which node.js is built on. the Reactor Pattern describes how node.js is able to avoid “blocking” from I/O operations and efficiently handle concurrency.

blocking functions are functions that require subsequent lines of code to wait for it to finish whatever it’s doing. in the context of I/O operations, these include reading/streaming a file, fetching data from an API… basically anything using the network or hard disk of its host machine and which could potentially fail, and in turn hang your code permanently.

non-blocking functions, in contrast, are functions which use callback functions to allow operations to run asynchronously, so that all page elements can load well before any I/O operations have to finish fetching or writing data.

the demultiplexer’s job in all of this is to….

…actually i should first define a multiplexer… a multiplexer is a mechanism which takes in multiple inputs and converts them to a single output.

so a demultiplexer, in node.js, converts such I/O operations into multiple outputs, which then line up inside the event queue. the next stop is the main hub of node/js concurrency — the event loop, where they are treated like just another function, and finally executed.

https://www.geeksforgeeks.org/what-is-reactor-pattern-in-node-js/

What are the main security implementations within NodeJS?

i hate to do this, but here’s a really great resource which thoroughly answers this question. and here is a more “security by design principles” guide to implementing security.

i do not have the time or expertise to answer this question in any satisfactory way other than to say use error handling, and be safe out there, guys.

Explain the “path” module in NodeJS.

the path module in node.js is a build-in module which provides a way of working with directories and file paths. all you have to do is include this line at the top of your .js file:

const path = require('path')

it has the following native methods:

https://www.w3schools.com/nodejs/ref_path.asp

i have not personally utilized this module, but there you go! for another great resource with probably the most lucid explanations you’ll find on the web, try the official node.js docs.

--

--

Michael Scoggins

graduate of Austin Coding Academy. looking for a full-stack (MERN... with a flexible M) web dev position.