Procedure for creating Node JS add ons

Below is how to setup the boiler plate code

mkdir test-addon
cd test-addon
git init
npm init

Now install the dependencies

npm install node-gyp --save-dev
npm install node-addon-api

node-gyp is the toolchain to compile the addons.
node-addon-api is a helper project as described earlier that will make writing C++ addons easier.


Couple of files that are important during the process are:

1. Bindings.gyp
2. package.json

Below is a sample content for this

Binding.gyp

{
    "targets": [{
        "target_name": "testaddon",
        "cflags!": [ "-fno-exceptions" ],
        "cflags_cc!": [ "-fno-exceptions" ],
        "sources": [
            "cppsrc/main.cpp"
        ],
        'include_dirs': [
            "<!@(node -p \"require('node-addon-api').include\")"
        ],
        'libraries': [],
        'dependencies': [
            "<!(node -p \"require('node-addon-api').gyp\")"
        ],
        'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ]
    }]
}

package.json

{
  "name": "test-addon",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "gypfile": true,
  "scripts": {
    "build": "node-gyp rebuild",
    "clean": "node-gyp clean"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "node-gyp": "^3.7.0"
  },
  "dependencies": {
    "node-addon-api": "^1.3.0"
  }
}


Just to note, gypfile:true should be present here

Now having these files set up, compilation of the modules can be done in the below steps

npm run build

This will generate the testaddon.node file in the release folder


The add on can be used like this below

const testAddon = require('./build/Release/testaddon.node');
console.log('addon',testAddon);
module.exports = testAddon;


binding.gyp file contains all the files that need to be compiled and all the include files / libraries that the project will be using. If you notice we have added cppsrc/main.cpp file as our source file.


References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

C++ Node files Looking into details and adding a method

Below is some description of main.cpp file

1. #include includes the napi header file so that we can access all the helper macros, classes and functions.
2. NODE_API_MODULE is a macro that accepts modulename and registerfunction as parameters.
3. In our case registerfunction is InitAll and it takes two parameters which are passed by N-API. First parameter env is the context that needs to be passed on to most N-API function and exports is the object used to set the exported functions and classes via N-API.


/**
* This code defines the entry-point for the Node addon, it tells Node where to go
* once the library has been loaded into active memory. The first argument must
* match the "target" in our *binding.gyp*. Using NODE_GYP_MODULE_NAME ensures
* that the argument will be correct, as long as the module is built with
* node-gyp (which is the usual way of building modules). The second argument
* points to the function to invoke. The function must not be namespaced.
*/
NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init)


Now to add a method to the C++ function using N-API

std::string hello(){
  return "Hello World";
}

To export this to javascript side, we have to do quite lot of work!

We need to have a header file and a cpp file containing implementations

Below given is hellosample.h

#include
namespace hellosample {
  std::string hello();
  Napi::String HelloWrapped(const Napi::CallbackInfo& info);
  Napi::Object Init(Napi::Env env, Napi::Object exports);
}


#include "hellosample.h"
std::string hellosample::hello(){
  return "Hello World";
}
Napi::String hellosample::HelloWrapped(const Napi::CallbackInfo& info)
{
  Napi::Env env = info.Env();
  Napi::String returnValue = Napi::String::New(env, hellosample::hello());

  return returnValue;
}
Napi::Object hellosample::Init(Napi::Env env, Napi::Object exports)
{
  exports.Set(
"hello", Napi::Function::New(env, hellosample::HelloWrapped)
  );

  return exports;
}


For every function in C++ we want to export we will basically create a NAPI wrapped function (HelloWrapped in this example) and add it to the exports object using Init.
Every wrapped function that needs to be exported to JS should have input params/return value from the Napi namespace.

Every wrapped function takes in CallbackInfo as the input parameter. This contains things like the context and the input parameters that needs to be passed to the function.
Initfunction is used to just set the export key as hello with corresponding wrapped function HelloWrapped .


OK, having defined these extra files, we need to tell the node gyp that we have added these files.This includes making changes to the binding.gyp, main.cpp, index.js files
Below is how to do that


In the gyp file, in the sources array, add the new file that is to be compiled. The new gyp file will be like this below

"sources": [
-            "cppsrc/main.cpp"
+            "cppsrc/main.cpp",
+            "cppsrc/Samples/functionexample.cpp"
         ],


main.cpp will be like this below

 #include
+#include "Samples/functionexample.h"

 Napi::Object InitAll(Napi::Env env, Napi::Object exports) {
-  return exports;
+  return functionexample::Init(env, exports);
 }

index.js can be like below

 const testAddon = require('./build/Release/testaddon.node');
 console.log('addon',testAddon);
+console.log(testAddon.hello());
 module.exports = testAddon;


References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

What is Node JS add-on?

Node.js Addons are dynamically-linked shared objects, written in C++, that can be loaded into Node.js using the require() function, and used just as if they were an ordinary Node.js module. They are used primarily to provide an interface between JavaScript running in Node.js and C/C++ libraries.

There can be many reasons to write nodejs addons:
1. You may want to access some native apis that is difficult using JS alone.
2. You may want to integrate a third party library written in C/C++ and use it directly in NodeJs.
3. You may want to rewrite some of the modules in C++ for performance reasons.


References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

What is N-API?

N-API (pronounced N as in the letter, followed by API) is an API for building native Addons. It is independent from the underlying JavaScript runtime (ex V8) and is maintained as part of Node.js itself. This API will be Application Binary Interface (ABI) stable across versions of Node.js. It is intended to insulate Addons from changes in the underlying JavaScript engine and allow modules compiled for one version to run on later versions of Node.js without recompilation.

In essence , N-API can be used to build NodeJS Addons using C or C++. And the addons built using this would not break across different implementations or versions of NodeJS.
N-API is a stable API as of Node v10 (latest stable release when writing this article). N-API was experimental in Node v8 and v9.

References:
https://medium.com/@atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f

CORS is enabled but still some requests are failing with CORS error

The issue was because some of the additional headers added when making the request.
When the server is configured to have below as allowed headers, anything else will
Likely get into the CORS issue again.


References:
https://stackoverflow.com/questions/7067966/why-doesnt-adding-cors-headers-to-an-options-route-allow-browsers-to-access-my

What is NW.js

NW.js is a framework for building desktop applications with HTML, CSS, and JavaScript. It was created by Roger Wang at Intel’s Open Source Technology Center in China, and worked by combining the Node.js programming framework with Chromium’s (then) browser engine - Webkit, hence the original name Node Webkit.

By combining Node.js with Chromium, Roger found a way to create applications that could not only load a local web site within an application window, but also could interact with the Operating System via a JavaScript API. This JavaScript API could control visual aspects like window dimensions, toolbar and menu items, as well as provide access to local files on the desktop. These are things that can’t be done with a hosted web site, or even a locally hosted web site. Below is an example of how an example application works.


In the example illustrated above, the application’s files resemble those of a simple web site. The index.html web page is like most other web pages that you’ve seen - there is some HTML code for the page’s content, a link tag for the CSS stylesheet, and a script tag for the JavaScript. At this stage it’s identical to a website, and if you were to open it in a web browser it would work the same as it would in NW.js. There is also a CSS stylesheet for styling the contents of the index.html file, and an app.js file for executing JavaScript, in this case calling a simple dialog box with the text “from NW.js” inside of it.

You’ll also notice a package.json file as well. This is the manifest file used by Node.js to load applications and libraries, and NW.js uses it to store configuration information about the desktop application. It is required by NW.js for the application to load.

The NW.js application is able to load an application with a given path of the folder where the files live. It looks for the package.json file, which points to the index.html file to load, and thus loads the web page into what looks like a web browser embedded inside of an application window. This is what you can expect to see:

The example application above could load inside of a web browser without any modifications, but where NW.js differs from a web browser is that where an app.js file could only interact with the index.html’s contents in the context of a web browser, NW.js allows the app.js file to interact with the Operating System through a custom JavaScript API, as well as through Node.js. This is unlike web frameworks where the front-end code and the back-end code traditionally exist and execute in separate places. The idea of front-end and back-end code existing and executing in the same place is the key concept to grasp here.


Interacting with the Operating System

NW.js provides a JavaScript API for interacting with the Operating System, so that you can do the following:
Control the size and behavior of the application’s window
Display a native toolbar on the application window, with menu items
Add context menus in the application window area on right-click
Add a tray application item in the Operating System’s tray menu
Access the Operating System clipboard; read the contents and even set the contents as well
Open file, folders and URLs on the computer using their default applications
Insert notifications via the Operating System’s notification system.


References:
https://dzone.com/articles/what-is-nwjs?fromrel=true

Redux Saga - what if need to run multiple tasks in parallel

The yield statement is great for representing asynchronous control flow in a linear style, but we also need to do things in parallel. We can't write:

// wrong, effects will be executed in sequence
const users = yield call(fetch, '/users')
const repos = yield call(fetch, '/repos')

Because the 2nd effect will not get executed until the first call resolves. Instead we have to write:

import { all, call } from 'redux-saga/effects'

// correct, effects will get executed in parallel
const [users, repos] = yield all([
  call(fetch, '/users'),
  call(fetch, '/repos')
])

When we yield an array of effects, the generator is blocked until all the effects are resolved or as soon as one is rejected (just like how Promise.all behaves).

To note, the call inside the array need not be covered in yield call.


References:
https://redux-saga.js.org/docs/advanced/RunningTasksInParallel.html