Forem: Abdulhafeez Abdulraheem

A dance with Merkle Trees

Abdulhafeez Abdulraheem — Tue, 21 May 2024 11:29:16 +0000

In my recent exploration into the web3 and blockchain world, I have frequently encountered the concept of Merkle trees, or hash trees. They provide a way to quickly and efficiently verify data since a hashed value remains constant. Additionally, Merkle trees offer a secure method for transferring large amounts of data between different nodes in a blockchain network.

What the Heck Are Merkle Trees?

At the base level, a Merkle tree is still a tree data structure, which is a hierarchical structure where each node has a left and right property that points to the next node in the tree structure. Each node also contains a value, which is a hash in this case.

The basic structure in Go is:

type MerkleTree struct {
    Root       *Node
    LeafHashes [][]byte
}

type Node struct {
    Left  *Node
    Right *Node
    Hash  []byte
}

A Simple Implementation of Merkle Trees in Golang

// merkle.go
package main

import (
    "crypto/sha256"
    "encoding/hex"
    "fmt"
)

type MerkleTree struct {
    Root       *Node
    LeafHashes [][]byte
}

type Node struct {
    Left  *Node
    Right *Node
    Hash  []byte
}

func hashData(data []byte) []byte {
    hash := sha256.Sum256(data)
    return hash[:]
}

func concatenateAndHash(left, right []byte) []byte {
    concatenated := append(left, right...)
    return hashData(concatenated)
}

func NewMerkleTree(data [][]byte) *MerkleTree {
    var nodes []Node

    // Create leaf nodes
    for _, datum := range data {
        hash := hashData(datum)
        nodes = append(nodes, Node{Hash: hash})
    }

    // Build the tree
    for len(nodes) > 1 {
        var newLevel []Node
        for i := 0; i < len(nodes); i += 2 {
            if i+1 == len(nodes) {
                // Odd number of nodes, duplicate the last node
                nodes = append(nodes, nodes[i])
            }
            left, right := nodes[i], nodes[i+1]
            newHash := concatenateAndHash(left.Hash, right.Hash)
            newLevel = append(newLevel, Node{Left: &left, Right: &right, Hash: newHash})
        }
        nodes = newLevel
    }

    tree := MerkleTree{Root: &nodes[0]}
    return &tree
}

Since a Merkle tree is a tree structure, we build the tree from the root node for each level. In a Merkle tree, each leaf node is a hash of a block of data, and each non-leaf node is a hash of its two child nodes.

We define the structures for the nodes and the Merkle tree. Each node has pointers to its left and right children and a hash value. The Merkle tree holds the root node and the leaf hashes.

type MerkleTree struct {
    Root       *Node
    LeafHashes [][]byte
}

type Node struct {
    Left  *Node
    Right *Node
    Hash  []byte
}

We also create the hash functions to hash the data to be embedded in the tree.

func hashData(data []byte) []byte {
    hash := sha256.Sum256(data)
    return hash[:]
}

func concatenateAndHash(left, right []byte) []byte {
    concatenated := append(left, right...)
    return hashData(concatenated)
}

To build a Merkle tree, we start by creating leaf nodes, each representing a hashed value of the input data. We then iteratively construct the tree by pairing up these nodes at each level, concatenating their hashes, and hashing the result to form the parent nodes. This process continues, forming new levels of parent nodes until only one node remains. If there is an odd number of nodes at any level, the last node is duplicated to ensure every node has a pair. The final remaining node becomes the root of the Merkle tree.

func NewMerkleTree(data [][]byte) *MerkleTree {
    var nodes []Node

    // Create leaf nodes
    for _, datum := range data {
        hash := hashData(datum)
        nodes = append(nodes, Node{Hash: hash})
    }

    // Build the tree
    for len(nodes) > 1 {
        var newLevel []Node
        for i := 0; i < len(nodes); i += 2 {
            if i+1 == len(nodes) {
                // Odd number of nodes, duplicate the last node
                nodes = append(nodes, nodes[i])
            }
            left, right := nodes[i], nodes[i+1]
            newHash := concatenateAndHash(left.Hash, right.Hash)
            newLevel = append(newLevel, Node{Left: &left, Right: &right, Hash: newHash})
        }
        nodes = newLevel
    }

    tree := MerkleTree{Root: &nodes[0]}
    return &tree
}

A Much Broader Use of Merkle Trees

I came across a post on how ApiToolKit by Anthony Alaribe uses Merkle Trees to detect API breaking changes, which majorly inspired this article. Thus, I wrote a simple simulator in Go on how that might have been implemented.

To simulate using Merkle trees to detect breaking changes in an API, we'll create a small Go program. This program will simulate the /get-coins and /buy-coins API requests, hash their responses, and store them in a Merkle tree. We'll then compare the hashes to detect changes.

// main.go
package main

import (
    "encoding/hex"
    "encoding/json"
    "fmt"
)

type ApiResponse struct {
    Endpoint string
    Data     []byte
}

func getCoins() ApiResponse {
    coins := []string{"BITCOIN", "SOLANA"}
    data, _ := json.Marshal(coins)
    return ApiResponse{Endpoint: "/get-coins", Data: data}
}

func buyCoins(successful bool) ApiResponse {
    if successful {
        status := map[string]int{"status": 100}
        data, _ := json.Marshal(status)
        return ApiResponse{Endpoint: "/buy-coins", Data: data}
    } else {
        status := map[string]int{"status": 101}
        data, _ := json.Marshal(status)
        return ApiResponse{Endpoint: "/buy-coins", Data: data}
    }
}

func detectBreakingChange(oldTree, newTree *MerkleTree) bool {
    return hex.EncodeToString(oldTree.Root.Hash) != hex.EncodeToString(newTree.Root.Hash)
}

func main() {
    // Simulate initial API calls
    initialGetCoinsResponse := getCoins()
    initialBuyCoinsResponse := buyCoins(true)

    // Hash initial responses and build Merkle tree
    initialData := [][]byte{initialGetCoinsResponse.Data, initialBuyCoinsResponse.Data}
    initialTree := NewMerkleTree(initialData)
    fmt.Println("Initial Merkle Tree:")
    printTree(initialTree.Root, 0)

    // Simulate subsequent API calls
    newGetCoinsResponse := getCoins()

    // Can switch to true to check if correct
    newBuyCoinsResponse := buyCoins(false)

    // Hash new responses and build new Merkle tree
    newData := [][]byte{newGetCoinsResponse.Data, newBuyCoinsResponse.Data}
    newTree := NewMerkleTree(newData)
    fmt.Println("\nNew Merkle Tree:")
    printTree(newTree.Root, 0)

    // Detect breaking changes
    if detectBreakingChange(initialTree, newTree) {
        fmt.Println("\nBreaking changes detected!")
    } else {
        fmt.Println("\nNo breaking changes detected.")
    }
}

The above implementation demonstrates how you can easily detect breaking changes in an API using Merkle trees. Merkle trees provide an efficient way to ensure data integrity because the hashed value of the same data remains unchanged. This approach is superior to comparing JSON objects directly, as it avoids the complexity of traversing each key and value to verify that the shape and structure are consistent. Instead, by simply comparing the root hashes of the Merkle trees, we can quickly detect any changes in the API responses, ensuring a reliable and secure method for monitoring API integrity. This implementation, inspired by the approach used by ApiToolKit by Anthony Alaribe, highlights the practical application of Merkle trees.

Building REST API's with Rust, Actix Web and MongoDB

Abdulhafeez Abdulraheem — Tue, 22 Mar 2022 18:15:31 +0000

Building REST API's with Actix web and Rust

Introduction

The Rust programming language has been gaining momentum as the most loved programming on the StackOverflow survey for five years, According to Wikipedia it is a multi-paradigm, general-purpose programming language aimed at speed and safety, with a focus on concurrency safety, As a result of this, it used and supported by top tech companies such as Microsoft.

Actix Web is a fast and performant web micro framework used to build restful APIs, In this article, we will explore the actix web framework along with the rust programming language by writing a simple crud API that would demonstrate each of the common HTTP verbs such as POST, GET, PATCH, DELETE.

Building a REST API

In this article, we will build a simple rest API that showcases each of the HTTP verbs mentioned and implements CRUD. Here are some of the endpoints we would be creating

GET /todos - returns a list of todo items

POST /todos - create a new todo item

GET /todos/{id} - returns one todo

PATCH /todos/{id} - updates todo item details

DELETE /todos/{id} - delete todo item

Getting Started

Firstly, we need to have rust installed, you can follow the instructions here, Once installed we would initialize an empty project using cargo, Cargo is rust's package manager, similar to npm for Node.js or pip for Python. To create an empty project we run the following command

cargon init --bin crudapi

This command would create a Cargo. toml\ file and a src folder. Open the Cargo.toml\ file and edit it to add the packages needed. The file should look like this:

[package]
name = "crudapi"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

After adding the packages the file should look like this:

    [package]
    name = "crudapi"
    version = "0.1.0"
    edition = "2021"

    # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

    [dependencies]
    actix-web = "2.0"
    actix-rt = "1.1.1"
    bson = "1.0.0"
    chrono = "0.4.11"
    futures = "0.3.5"
    MongoDB = "1.0.0"
    rustc-serialize = "0.3.24"
    serde = { version = "1.0", features = ["derive"] }

Open the main.rs\ file that cargo creates, and import the actix web dependency to use in the file like so

    use actix_web::{App, HttpServer};

We will create five routes in our application to handle the endpoints described. To keep our code well organised, we will put them in a different module called controllers and declare it in main.rs.

In the main.rs we proceed to create a simple server in our main function which is the entry point of our application

  // imports

 #[actix_rt::main]
    async fn main() -> std::io::Result<()> {
        std::env::set_var("RUST_LOG", "actix_web=debug");


        HttpServer::new(move || {
            App::new()
                .route("/todos", web::get().to(controllers::get_todos))
                .route("/todos", web::post().to(controllers::create_todo))
                .route("/todos/{id}", web::get().to(controllers::fetch_one))
                .route("/todos/{id}", web::patch().to(controllers::update_todo))
                .route("/todos/{id}", web::delete().to(controllers::delete_todo))
        })
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
  }

The main function is the entry point for the application which returns a Result type. In the main function, we use the attribute #[actix_rt::main] to ensure it’s executed with the actix runtime and proceed to create a new HttpServer instance and also add an App instance to it, add a few routes that point to our controllers\ module which would handle the logic for each route and serve it on port 8080.

We proceed to create the controllers\ module by creating a simple file inside the src\ folder that contains main.rs file. Inside the controllers\ module, create functions that each route points to like so;

    // src/controllers.rs
    use actix_web::Responder;

    pub async fn get_todos() -> impl Responder {
      format!("fetch all todos");
    }

    pub async fn create_todo() ->  impl Responder {
      format!("Creating a new todo item");
    }

    pub async fn fetch_one() -> impl Responder {
      format!("Fetch one todo item");
    }

    pub async fn update_todo() -> impl Responder {
      format!("Update a todo item");
    }

    pub async fn delete_todo() -> impl Responder {
      format!("Delete a todo item");
    }

These are the handlers for each route we have specified above, they are each asynchronous functions that return a Responder\ trait provided by actix-web\. For now, they return a string, later we would modify each function to implement some logic interacting with a database.

Let’s proceed to run the project:

cargo run

Finished dev [unoptimized + debuginfo] target(s) in 0.53s
Running `target/debug/crudapi`

We can test each endpoint with curl\, in another terminal.

curl 127.0.0.1:8080/todos
//@returns: fetch all todos

Connect MongoDB Database

We would use the official MongoDB rust crate to allow us to store information in a local database. We initiate the connection in the main function to ensure connection when our server starts running and include it in the app state to be able to pass it into our controllers.

Firstly we import the modules needed in the main.rs

// src/main.rs

use MongoDB::{options::ClientOptions, Client};
use std::sync::*;

Then proceed to modify the main\ function to look like this:

 // src/main.rs

#[actix_rt::main]
async fn main() -> std::io::Result<()> {
        std::env::set_var("RUST_LOG", "actix_web=debug");
        let mut client_options = ClientOptions::parse("MongoDB://127.0.0.1:27017/todolist").await.unwrap();
        client_options.app_name = Some("Todolist".to_string());
        let client = web::Data::new(Mutex::new(Client::with_options(client_options).unwrap()));

        HttpServer::new(move || {
            App::new()
                .app_data(client.clone())
                .route("/todos", web::get().to(controllers::get_todos))
                .route("/todos", web::post().to(controllers::create_todo))
                .route("/todos/{id}", web::get().to(controllers::fetch_one))
                .route("/todos/{id}", web::patch().to(controllers::update_todo))
                .route("/todos/{id}", web::delete().to(controllers::delete_todo))
        })
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
    }

The above code creates a MongoDB client that is wrapped in a Mutex for thread safety which is then passed into the app state to be used by our controllers.

Creating a todo list API

Now that the database connection is ready and in our app state, we proceed to modify our create_todo function in our controller to create a new document in the database, firstly you import the modules needed and model the type of data coming as a payload, this can be easily done with structs like so:

    // src/controllers.rs
    use actix_web::{web, HttpResponse, Responder};
    use MongoDB::{options::FindOptions, Client};
    use bson::{ doc, oid };
    use std::sync::*;
    use futures::stream::StreamExt;
    use serde::{Deserialize, Serialize};

    #[derive(Deserialize, Serialize)]
    pub struct Todo {
        pub content: String,
        pub is_done: bool,
    }
    #[derive(Serialize)]
    struct Response {
        message: String,
    }

    const MONGO_DB: &'static str = "crudapidb";
    const MONGOCOLLECTION: &'static str = "todo";

We imported the needed modules, and created two structs Todo\ and Response\ and two const variables, The Todo\ struct is responsible for how model data would be inputted into the database, and The Response\ handles how response messages would be sent back on an endpoint. The MONGO\_DB\ and MONGOCOLLECTION\ holds the constant strings of our database\ name and collection\ name.

Now we are ready to create the function that creates a new item in the database

    // src/controllers.rs
    // imports
    // structs
    // constants

    pub async fn create_todo(data: web::Data<Mutex<Client>>, todo: web::Json<Todo>) ->  impl Responder {
      let todos_collection = data.lock().unwrap().database(MONGO_DB).collection(MONGOCOLLECTION);
      match todos_collection.insert_one(doc! {"content": &todo.content, "is_done": &todo.is_done}, None).await {
        Ok(db_result) => {
            if let Some(new_id) = db_result.inserted_id.as_object_id() {
                println!("New document inserted with id {}", new_id);   
            }
            let response = Response {
              message: "Successful".to_string(),
            };
            return HttpResponse::Created().json(response);
        }
        Err(err) =>
        {
            println!("Failed! {}", err);
            return HttpResponse::InternalServerError().finish()
        }
    }
  }

This function takes the app state data and the payload todoapp state, firstly we get the todo collection from MongoDB client in our app state, then we dynamically create a new document using the insert_one function and add the todo payload which returns a Result which we use the match operator to see if it’s was successful or an error was returned. If it is successful we return a created status code 201\ and success message, else return a 500 internal server error.

Fetching todo list

Using a get request we can pull out data from our database. According to the routes implemented above, we create two functions to respond to fetching all the todo items in the database and fetching only one from using its id. we modify the controllers.rs\ like so:

  // src/controllers.rs

    pub async fn get_todos(data: web::Data<Mutex<Client>>) -> impl Responder {
      let todos_collection = data.lock().unwrap().database(MONGO_DB).collection(MONGOCOLLECTION);
      let filter = doc! {};
      let find_options = FindOptions::builder().sort(doc! { "_id": -1}).build();
      let mut cursor = todos_collection.find(filter, find_options).await.unwrap();
      let mut results = Vec::new();
      while let Some(result) = cursor.next().await {
          match result {
              Ok(document) => {
                  results.push(document);
              }
              _ => {
                  return HttpResponse::InternalServerError().finish();
              }
          }
      }
      HttpResponse::Ok().json(results)
    }

    pub async fn fetch_one(data: web::Data<Mutex<Client>>, todo_id: web::Path<String>) -> impl Responder {
      let todos_collection = data.lock().unwrap().database(MONGO_DB).collection(MONGOCOLLECTION);

      let filter = doc! {"_id": oid::ObjectId::with_string(&todo_id.to_string()).unwrap() };
      let obj = todos_collection.find_one(filter, None).await.unwrap();
      return HttpResponse::Ok().json(obj);
    }

The get_todos function returns all the items in the database using the find function we pass in a filter and find_options which sorts the results from newest to oldest, then proceed to iterate the results using the cursor returned by the find function, populating the result vector with incoming documents before returning them in json format.

The fetch_one function returns a single todo item from the database, the id is passed from the route into the function as a web::Path. The filter is passed into the find_one function to filter out the item based on the id and it is returned as a response.

Updating an item in the todo list

The patch request would be responsible for updating an item in the database.

  // src/controllers.rs
    pub async fn update_todo(data: web::Data<Mutex<Client>>, todo_id: web::Path<String>, todo: web::Json<Todo>) -> impl Responder {
        let todos_collection = data.lock().unwrap().database(MONGO_DB).collection(MONGOCOLLECTION);
        let filter = doc! {"_id": oid::ObjectId::with_string(&todo_id.to_string()).unwrap() };
        let data = doc! { "$set": { "content": &todo.content, "is_done": &todo.is_done } };
        todos_collection.update_one(filter, data, None).await.unwrap();

        let response = Response {
            message: "Updated Successfully".to_string(),
          };
        return HttpResponse::Ok().json(response);
  }

The update_todo accepts the appstate and todo_id as the id passed from the route and the update payload, it filters the document using the id passed and proceeds to update the document in the database and returns a successful message.

Deleting an item in the todo list

Our final controller deletes an item corresponding to the ID passed to the route.

// src/controllers.rs

pub async fn delete_todo(data: web::Data<Mutex<Client>>, todo_id: web::Path<String>) -> impl Responder {
        let todos_collection = data.lock().unwrap().database(MONGO_DB).collection(MONGOCOLLECTION);
        let filter = doc! {"_id": oid::ObjectId::with_string(&todo_id.to_string()).unwrap() };

        todos_collection.delete_one(filter, None).await.unwrap();
        return HttpResponse::NoContent();
}

The delete_one function filters by id provided in the route and deletes the document from the database, the proceeds to return a 204\ status code.

Testing the server

We've successfully built a simple todolist API, now to make client requests. Using cURL we can easily test each of the routes in the application.

First, we run the application using the following command

cargo run

Once the server is running open another terminal to test each endpoint.

POST 127.0.0.1:8080/todos : create an item in the todo list

$ curl -H "Content-Type: application/json" -XPOST 127.0.0.1:8080/todos -d '{"content": "Read one paragraph of a book", "is_done": false}'

This sends a POST request to our /todo endpoint and inserts the payload and associated details into our database. As a response, we receive a success message:

{"message":"Successful"}

GET 127.0.0.1:8080/todos :Fetch all items

$ curl -H "Content-Type: application/json" -XGET 127.0.0.1:8080/todos

This returns all the items on our todo list and we get a response like:

[{"_id":{"$oid":"620d1e64fad81254efb04383"},"content":"Read one paragraph of a book","is_done":false}]

GET 127.0.0.1:8080/todos/{id} : Fetch one item

$ curl -H "Content-Type: application/json" -XGET 127.0.0.1:8080/todos/620d1e64fad81254efb04383

This returns a todo item based on the ID passed into the route and you should get a response like so:

{"_id":{"$oid":"620d1e64fad81254efb04383"},"content":"Read one paragraph of a book","is_done":false}

PATCH 127.0.0.1:8080/todos/{id} : Update one item

$ curl -H "Content-Type: application/json" -XPATCH 127.0.0.1:8080/todos/620d1e64fad81254efb04383 -d '{"content":"Read one paragraph of a book", "is_done": true }'

This updates the document in the database with the payload sent to it, you should get a success message

{"message":"Updated Successfully"}

DELETE 127.0.0.1:8080/todos/{id} : Delete one item

$ curl -H "Content-Type: application/json" -XDELETE 127.0.0.1:8080/todos/620d1e64fad81254efb04383

This removes the item from our database as an empty response without a message because we are returning a 204 status code.

Conclusion

In conclusion, this article has provided a comprehensive understanding of REST APIs, HTTP verbs, and status codes, along with practical guidance on building a REST API service in Rust, utilizing actix web and MongoDB. As you continue to evolve your application, consider enhancing its functionality by incorporating features such as logging, encryption, rate limiting, and more. These additions will not only enhance security but also contribute to the scalability and overall improvement of your application's performance.

Worker Threads in Node.js

Abdulhafeez Abdulraheem — Thu, 24 Dec 2020 16:07:59 +0000

Introduction

Workers threads in Node.js are a way to offload CPU intensive tasks away from the single-threaded process which Node gives you.

Firstly, we need to understand why you can't put a CPU intensive task in the main process of your Node.js instance. This is because Node.js is single-threaded and you only get one process out of the box, A process is a global object that has the information of what is being executed at the time.

I have but One Thread to give - Node.js

The decision to make Node.js single-threaded came from the decision of not changing the language design itself, Adding a multithread module to Javascript can change the way the language is written itself.

Node.js has one event loop, this is what gives Node it's asynchronous nature by offloading operations to the system's kernel and getting back results through the use of callbacks, promises and async/await, thus we don't have to worry about concurrency problems.

This can become an issue when you have a CPU intensive task to be executed. For example, performing synchronous tasks that takes a lot of time to be executed or has complex mathematical calculations that can block the thread while it's being executed, which means all other tasks to be executed at that time has to wait. If it was an API request any other HTTP request that comes in at that time would be blocked, which keeps the end-user waiting, A solution for this is the use of worker threads.

Working with Worker Threads

We would be using worker threads to calculate Fibonacci of numbers and also making use of Atomics and Shared Buffers to help us handle race conditions between our threads.

Check out this wonderful article about Shared buffers and Atomics here

We can easily use the worker thread module by importing it into our file.

const { Worker } = require('worker_threads');

Main Process

// main.js
const { Worker } = require("worker_threads");
const runFibonnaci = (nums) => {
    // get the length of the array
    let length = nums.length;

    // int32 buffer of each element in the array
    let size = Int32Array.BYTES_PER_ELEMENT * length;

    // Create buffer for the size ofthe input array
    let sharedBuffer = new SharedArrayBuffer(size);
    let sharedArray = new Int32Array(sharedBuffer);


    for(let i = 0; i < length; i++ ) {
        // store each value into the shareArray 
        Atomics.store(sharedArray, i, nums[i]);

        // Spin up a new worker thread
        let worker = new Worker('./worker.js');

       // Once calculation is done print out result
        worker.once('message', (message) => {
            console.log('Result received --- ', message);
        })

        // Send array data and index to worker thread.
        worker.postMessage({data: sharedArray, index: i});
    }
};

runFibonnaci([50, 20, 21, 24, 4 ]);

The rubFibonnaci function accepts an array of numbers to be calculated in the worker thread, The sharedBuffer variable is created using the SharedArrayBuffer class from the size variable which creates the size of the sharedArrayBuffer.

// get the length of the array
    let length = nums.length;

    // int32 buffer of each element in the array
    let size = Int32Array.BYTES_PER_ELEMENT * length;

    // Create buffer for the size ofthe input array
    let sharedBuffer = new SharedArrayBuffer(size);
    let sharedArray = new Int32Array(sharedBuffer);

The sharedArray variable is also created using the int32Array class to create an array of 32 bit signed integers. We are use Atomics to store our sharedArray so each worker thread can access the shareArray variable from a single memory instance, Atomics only works with SharedArrayBuffers and ArrayBuffers.

When memory is shared, multiple threads can read and write the same data in memory. Atomic operations make sure that predictable values are written and read, that operations are finished before the next operation starts and those operations are not interrupted. According to the MDN Docs

We proceed to loop through through the nums array passed into the runFibonnaci function, then store each value, using the Atomic.store static function.

for(let i = 0; i < length; i++ ) {
        // store each value into the shareArray 
        Atomics.store(sharedArray, i, nums[i]);

        // Spin up a new worker thread
        let worker = new Worker('./worker.js');

       // Once calculation is done print out result
        worker.once('message', (message) => {
            console.log('Result received --- ', message);
        })

        // Send array data and index to worker thread.
        worker.postMessage({data: sharedArray, index: i});
   }

We then spin up a new worker thread and send the sharedArray and the index into the worker thread. The worker.once('message') function is called once the worker thread has finished executing its task and returns a value, which we would see in the worker file below.

Worker Process

// worker.js
const { Worker, isMainThread, parentPort } = require('worker_threads');

// Listen for message from main thread
parentPort.once('message', (event) => {
    const sharedArray = event.data;
    const index = event.index;

    const arrValue = Atomics.load(sharedArray, index);
    const fibonaciValue = calculateFibonacci(arrValue);
    parentPort.postMessage(fibonaciValue);   

});


const calculateFibonacci = (num) => {
    var a = 1, b = 0, temp;

    while (num >= 0){
      temp = a;
      a = a + b;
      b = temp;
      num--;
    }

    return b;
}

The parentPort.once function is called once the worker is initialized and data is passed into it, it loads the sharedArray and index and stores it in a variable. the arrValue fetch the value from the sharedArray using the Atomics.load function, then calculates the Fibonacci of the value by calling the calculateFibonacci function, it then returns the value to the main process to be printed on the console.

You can run the code by running this command on the console

node main.js

.

// console 
Fibonacci received ---  20365011074
Fibonacci received ---  17711
Fibonacci received ---  75025
Fibonacci received ---  10946
Fibonacci received ---  5

Conclusion

Using worker threads can help your Node.js application by executing tasks that are CPU intensive in threads, worker threads don't magically make your application faster, but it can help in situations where some particular sets of instructions are blocking the single process and making other tasks fail.

Source code can be found here

Photo by K15 Photos on Unsplash

What is the difference between dot notation and this : [''] while using an object in javascript

Abdulhafeez Abdulraheem — Sat, 15 Aug 2020 19:06:03 +0000

Apparently for some weird reasons I have been getting a bug on a web app and replacing it from dot notation to [''] solved it.

Observe:

from:

item.price = quantity * normal_price;

to:

item['price'] = quantity * normal_price;

What they won't tell you about Lead Developer Roles!

Abdulhafeez Abdulraheem — Tue, 26 May 2020 17:20:45 +0000

Recently I got a fascinating job for a lead developer role for a startup. Being a software engineer all my life and living by the mantra - sleep, eat, code, code review, sleep, repeat and the most we have to do when interacting with other people is probably code review or when a new project is about to start or during daily standups to talk about what we would do for the day.

Never had I ever thought I would put on the hat of a lead so soon, and It comes with a lot of managerial responsibilities I wasn't ready for, Woah! First, you have to organize the team and mode of operation communicating with the project manager to see how we can deliver new features, then communicating with team members to see If they have any problems, create schedules, deadlines and ensure communications between the team members and other functional areas in the company.

Then the floods of meetings, Most people who come into this role feel its step in writing more mature code and leading people who code too, yes this assumption might be true but they just cover 10% of what the actual job is like, heck you might only get to squeeze out two hours of coding in a day and some days you have meetings for hours, scheduling, and when you finally want to code - psych! its time for code review.

How do you prepare for the role

Preparing for this sort of roles has nothing to do with knowing goroutines or understanding how to traverse a binary or properly setting up CI/CD with the cloud, heck the most technical thing you could do in a day is helping the front engineer properly validate input in a form(joking). Definitely the experience and knowledge is required for the role but that isn't always the case, here is a list of things we should be prepared for when filling such a role

Good Communication and Leadership skills:
Knowing how to communicate well can be a problem for programmers sometimes, which is actually a very bad trait because it creates a stereotype that programmers are introverted people which isn't the case most times, Communicating with other members is key to the role as it is necessary to understand how each piece of software being written would progress or regress the project or tasks at hand.
Good Listening Skills:
Being good at talking doesn't necessarily mean you are great at listening, your role is to translate business ideas into technical details, perfectly understanding what is required to make this happen requires great listening skills. Listening and considering the inputs from your team members as well is important to cover the gaps of things we could have likely missed.
Patience:
Understanding that you are dealing with different sets of people, teaching, motivating and mentoring different sets of people boils down to understanding each team members mentality. Some people are motivated by complexity while others are motivated by simplifying, seeing it through that each team member is giving their 100% is important and on days where they are under the weather you motivate them.

Becoming a great lead developer isn't a nights work, It requires proven talent and experience and the ability to teach, motivate and mentor others, at the end of the day it all boils down to your soft skill and building good relationships with people.

Ionic 3 tips you might need in your native applications.

Abdulhafeez Abdulraheem — Fri, 02 Nov 2018 07:53:33 +0000

google image

Ionic is one of the most used cross-platform app development frameworks. With Ionic 4 beta out, you can now integrate ionic with your favorite front-end frameworks (Angular, React, Vue, etc).

Making your Ionic app look native and feel native is what ionic developers strive for, as an Ionic developer the following hacks/tips can improve the user experience of your app to look more native.

Using native transitions: Native transitions make your app feel native when transitioning between pages.

https://ionicframework.com/docs/native/native-page-transitions/

Showing notifications when downloading a file : Using ionic file transfer and showing notifications can be a daunting task. Use the following Cordova plugin which would use the android download manager and show a download notification.

https://github.com/vasani-arpit/cordova-plugin-downloadmanager

Displaying a loader when using the Ionic themeable browser plugin: At some point in our application, we might be required to use an in-app browser, just to make your app feel more native and not breaking the user experience at that point. A common problem is to display a loader while the webpage is being loaded otherwise it might be blank. Using the Loading controller wouldn’t work. A quick fix is to use the ionic native spinner dialog.

https://ionicframework.com/docs/native/spinner-dialog/

Using a custom status bar color : The status bar is the notification bar of your app. Changing the color to your app primary color or something similar would make your app feel more native.

https://ionicframework.com/docs/native/status-bar/

Using a custom a header color : The android multitask view allows you to change the header color. Using the ionic native plugin it improves the look and native feel of your app.

https://ionicframework.com/docs/native/header-color/

Conclusion

The above tips will improve the feel of your Ionic app and make it look more native, thereby giving your users a better app experience.

Reach out to me via switchdevelop1@gmail.com and give me a follow on twitter and github.

Sending Mails with Sendgrid and Node.js

Abdulhafeez Abdulraheem — Thu, 20 Sep 2018 20:09:27 +0000

Essentially in every web application, there's a need to send the user an email. In this article, I would love to show you how easy it is to setup Sendgrid and send emails easily to users. We will set up an easy module that will handle our mail sending.

Installing SendGrid

Firstly, we need the official package for sending emails. Run the following command :

npm install @sendgrid/mail

Now we have the Sendgrid node package for the sending emails in your node application.

To use this package you need an API key which you will get here after you must have created an account.

Configuring Sendgrid

In my application, I like to create the email sending module in a separate file in a utils folder and name it emails.js

// emails.js

const SGmail = require('@sendgrid/mail')

SGmail.setApikey('xxxxx-xxxxx') // Input Api key or add to environment config

I strongly advise you don’t hardcode your API key, use an environment variable instead, check out this awesome post to get started if you don’t know how to use config vars in node.js

Mail Sending

Let’s create a simple function to send the email

//emails.js

function newUserEmail(email, name){

const message = {

to : email, //email variable

from : { email : 'your email' , name: 'Name of user you want to send email as'},

message : `Hi there, ${name}`,

subject : "This is a test Email"

}

SGmail.send(message).then((sent) =\> {

// Awesome Logic to check if mail was sent

})

}

module.exports = {

newUserEmail
}

Let me explain each of the keys and values in the message object created above

⦁ to: The recipient’s email.

⦁ from: the from object contains the email key which would be used as the sender email and name which would be used as the sender name.

⦁ message: which is the content of your email. You can also use HTML tags, in which case the key wouldn’t be message, but html instead.

⦁ subject: The email subject.

Conclusion

I am sure you see how easy it is to send emails with Sendgrid. This can save a lot of development time and debugging time with minimal configurations. Now you can import the function anywhere in your code and send a mail, easy!

Reach out to me via swithdevelop1@gmail.com and give me a follow on twitter.

✉️ Subscribe to CodeBurst’s once-weekly Email Blast , 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.