DEV Community: Nwachukwu Chibuike

Backends For Frontends — My Take

Nwachukwu Chibuike — Wed, 07 Jun 2023 14:48:19 +0000

Backends For Frontends — My Take

What do you get when you have a lot of Microservices to fetch data from before displaying a result — Multiple network calls; add the need to display results based on the requesting client and it becomes a dilemma.

Solution? Backends For Frontends(BFF)

In this article, we would get to know about what the Backends For Frontends pattern is about, why it came about, the problems it seeks to solve when to use it, and its rewards. Let's get right into it!

Monolith vs Microservices Architecture

Initially, applications were built using the Monolith architecture approach. Here all application components are bundled and deployed as a single unit.

One single source code contains the application and handles everything and is hosted on a server, clients connect to this server and get results.

This single application contains the APIs, UI, Data Access Layers, CronJobs, etc all in one. This brought some advantages:

Quick deployment: Simple and faster deployment
Easier testing: Since the whole source code resides in one place, it makes it easier to debug and carry out automated tests.
Faster Development: Since there are fewer moving parts, all efforts are focused on a single source code.

However, this approach came with some headaches, because all the technology and services were locked into one single large project and deployed, and software engineering teams, had to deal with issues like:

Poor Fault Tolerance: Once the application goes down, all components are affected.
Technology lockdown: Application built with a single language, even when some parts of the application would have faired better been programmed using another language.
Maintenance: Difficult to maintain as there are a lot of tightly coupled parts, a minor update in a component could lead to a breaking change in another component.
Scalability: The need to scale the whole application which increases the cost when only a particular section of the application requires scaling.

Then came Microservice, where each of the services is broken down into separate services that have a well-defined domain. Clients connect to these microservices, fetch information, and display. This solves the issues experienced in Monolith.

This brought great advantages like:

Agile Development,
Improved Scalability,
Technological Flexibility,
Improved Fault Tolerance

However as can be seen from the image above, the client now connects to multiple servers to get the information it requires. This adds additional work for the clients as it has to make multiple calls to get the data it needs to display a result, as well as do more data manipulation and formatting on its end to suit what it needs.

This is where Backends For Frontends pattern comes in handy.

What is Backends For Frontends Pattern?

It is a layer that sits between the Backend(Microservices) and the client, it acts as an aggregator and an additional layer of abstraction.

Every client be it mobile, desktop, IoT devices, and wearables would have a separate BFF that communicates with the different microservices, filters out unwanted data, and formats the response in a way needed by the client.

The diagram below gotten from Sam Newman's webpage shows a great visual about this pattern in use. He emphasizes the need for having one BFF per user experience.

This improves the performance of the overall application as it reduces network calls the client needs to make before it gets the data it needs.

Advantages of using Backends For Frontends

Reduces network calls from the client side: The Client doesn't need to communicate to multiple endpoints/microservices to get all the data it needs to display. This data aggregating task is now handed over to the BFFs server.
Fewer client data manipulation: Each client BFF handles data fetching, manipulation, and aggregation as needed for the client. This removes the need from the client end to perform this data manipulation to display a unique view to the user.
Security: An additional layer can also act as a filter removing some fields which exist in each microservice endpoint response that may not be needed for a particular client. This further improves the security of the overall architecture.
Separation of concerns: There is a saying that “Backends tend to live longer than Frontends” hence we shouldn't introduce frontend requirements directly into the backend. This makes it easier for maintenance.
Removes the need to update client response when a new API version is released to a microservice: Since the BFFs act as a layer of abstraction, updates to the underlying API(Microservices) endpoint won't require a change on the client end, as the BFF acts as the source for the client and not the API directly. Hence BFF maintains the endpoints response format it provides to the client while it does the update internally on how it communicates with the Microservices due to the newly released API versions.

Challenges of using Backends For Frontends

With all the good intentions this pattern has, it introduces some concerns which are:

Security: One point of attack, since the client only communicates with the BFF, makes it an easier target and once down the client won't be able to fetch the results it needs.
Increase in network latency: Due to the multiple network hops made before a request is sent back to the client, there is some network latency introduced.
Additional Code maintenance: It introduces an additional piece of code that has to be developed, maintained, deployed, and monitored.

When to use the Backends For Frontends Pattern

The deciding factor here is the client. The moment you need to provide unique functionality for a particular client say a mobile UI, Web App, or third party, then it is strongly advised to consider using BFFs for each client.

That is when the interface between different clients varies significantly, a BFF is your best option.

Difference between Backends For Frontends and API Gateway

I added this section because as I learned about the BFF pattern I found some overlap with the API gateway.

“A standard API gateway handles requests from all the clients interacting with the system, while a BFF only handles a specific client.”

Conclusion

The Backends For Frontends is a natural evolution of Microservices Architecture, it’s a pattern created with the clients in mind and also the user's experience.

I look forward to seeing this pattern used more within the tech ecosystem and can't wait to see what you build with it!

Deploy a Node.Js Cloud Native Application to Amazon EKS

Nwachukwu Chibuike — Sun, 21 May 2023 10:30:59 +0000

In this article, I show how to deploy a Cloud Native Node.js application to Amazon EKS via the AWS CLI. Amazon Elastic Container Registry(ECR) is used to store the built docker images.

Prerequisites

To better follow along with this article, you would need the following:

Node.js 12 or above
NPM
AWS CLI configured on your local machine
An AWS account
Docker installed on your local machine
Knowledge of Kubernetes

Amazon EKS

Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service to run Kubernetes in the AWS cloud and on-premises data centers. As an AWS-managed service, it makes it easy to use Kubernetes on AWS without needing to install and operate the Kubernetes control plane.

We would make use of EKS to deploy the cloud-native app we use in this article.

Setting up the Project

Here we set up the project, dockerize it and run it locally to make sure everything works as expected.

Basic Node.js project

We would proceed to clone an already existing application found here. It spins up an express server that serves some dummy content.

# Clone this repository
$ git clone https://github.com/kkohtaka/webapp-nodejs.git
# Go into the repository
$ cd webapp-nodejs

Containerizing the project

To containerize the project, we would make use of Docker. First, we create a Dockerfile for the application.

In the root folder, create a file named Dockerfile and add the following content within it:

FROM node:14
WORKDIR /app
COPY package.json ./
RUN npm install 
COPY . .
EXPOSE 3000
CMD ["npm", "start"]

Next, create a .dockerignore file:

node_modules

To build the docker image for the application run the following command

docker build -t demo/webapp-nodejs .

To verify the image is built well, spin up a container to test by running the built docker image:

docker run -p 3000:3000 demo/webapp-nodejs

This command above enables us to test the application in a local browser by visiting http://localhost:3000. The image below confirms it works as expected.

Pushing image to Amazon Elastic Container Registry(ECR)

In other to make the built docker image publicly available, we need to push it to a central repo. We would make use of Amazon ECR to store the image.

First, create the Amazon ECR registry where we would store the image. Run the command below to do that

aws ecr-public create-repository --repository-name webapp-nodejs-repo --region us-east-1

The command connects to AWS using the default AWS profile we have configured and creates the repository. It outputs a JSON-like response containing the details of the newly created repository:

Next, authenticate our local machine docker client to the Amazon ECR registry. This gives access to the registry for up to 12hrs, read more about this here

aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws

Proceed to tag the local docker image with the ECR Registry.

Replace REPO_URI with Repository URI gotten from ECR when the registry was created. In my case it is: public.ecr.aws/d5d5p5r5/webapp-nodejs-repo

docker tag demo/webapp-nodejs:latest <REPO_URI>:latest

Finally, push the image to the ECR repository:

docker push <REPO_URI>

Note: We can also configure the Default region name using aws configure for the default profile to be us-east-1 instead of having to include it in every command.

Provisioning an EKS Cluster

Now that the image has been deployed to ECR, creating an EKS cluster where the app would be deployed is the next thing to do.

We make use of the eksctl CLI to create the cluster in EKS, eksctl which is a simple command-line tool for creating and managing Kubernetes clusters on Amazon EKS.

First, we need to install this CLI to be able to use it, head over to this page to learn how to install it based on your device. After, run the command below to confirm if you have it all set up.

eksctl version

If you get a version shown, then all is well, else go back to the referenced page to identify any step you may have missed.

Now we have configured eksctl, we now provision our first cluster(creating the cluster in the us-east-2 region):

eksctl create cluster --name webapp-nodejs-cluster --region us-east-2

Finally, configure kubectl to enable it to connect to the EKS cluster by updating the kubectl config (update-kubeconfig) with the cluster endpoint.

aws eks update-kubeconfig --name webapp-nodejs-cluster --region us-east-2

Deploying to EKS Cluster

At this stage, we have an image in ECR and an empty EKS Cluster running, the last step is to run the application within this EKS Cluster.

To deploy the application, create a Deployment.yml file containing the deployment details. The deployment creates a Pod, where the application runs in a single container using the Docker image.

Replace the image “public.ecr.aws/d5d5p5r5/webapp-nodejs-repo” with your ECR URI:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-nodejs
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp-nodejs
  template:
    metadata:
      labels:
        app: webapp-nodejs
    spec:
      containers:
      - name: webapp-nodejs
        image: public.ecr.aws/d5d5p5r5/webapp-nodejs-repo:latest
        ports:
          - containerPort: 3000

Next, apply the deployment to create it:

kubectl apply -f Deployment.yml

To verify if it works, run the command below:

kubectl get deployments

We now need to expose the pods running within the cluster to the outside world to be accessible. To do this we need to create a Service with the type of Load Balancer to expose the port the application is listening to.

kubectl expose deployment webapp-nodejs --port=80 --target-port=3000 --type=LoadBalancer

To verify if it works, run the command below:

kubectl get services

Testing

Finally, to confirm everything works as expected, copy the exposed **EXTERNAL-IP **address shown in the previous command and visit a browser:

Great! it works as expected!

Conclusion

In this article, you learned how to Dockerize a Node.js application, push the built image to Amazon Elastic Container Registry (ECR), created an Amazon Elastic Kubernetes Service (EKS) cluster, deployed the application within the cluster, and finally exposed the deployment so we could test it.

Amazon EKS makes it easy and super fast to deploy cloud native applications, try using it for your next deployment!

Serverless Facial Recognition Voting Application Using AWS Services

Nwachukwu Chibuike — Wed, 03 May 2023 12:18:39 +0000

Recently I watched the recorded video of the Serverlesspresso team talk at 2022 Reinvent on the AWS Events Youtube Page. I got inspired and decided to take a cue from that video and other lessons from 2022 Reinvent and build an open-source project.

The result? FacePolls, a Serverless Facial Recognition Voting Application built entirely using AWS services, adheres to established best practices and uses the Event-Driven pattern.

This article describes how I built this project from scratch, the patterns I used and why, my key takeaways and learnings, and finally a call to action to build event-driven and serverless systems.

Let’s get right into it!

Prerequisite

Node.js 16
NPM
An AWS account
AWS CLI configured on your local machine with an AWS profile, would be used for deploying the backend section of the application, which was built using the Serverless Framework
Serverless installed globally, would be used to run the serverless deploy command

Deployment

First, you would need to clone the repo found here(Feel free to leave a star or fork it).


    # Clone this repository
    git clone https://github.com/chyke007/facial-vote.git

    # Go into the repository
    cd facial-vote

Frontend Application & Admin Frontend Application

Now inside the project folder, we can easily run both apps as they are built using Next.js. To run it locally, you would need to install the packages used, as well as create a .env file from the .env.example sample file provided, then provide the right values.



    # Copy environment variable
    $ cp facial-vote-admin/.env.example .env && cp facial-vote-frontend/.env.example facial-vote-frontend/.env

You should get the necessary values once the backend application is deployed, to get the necessary endpoints.



    # Run Frontend (run from folder root)
    $ cd facial-vote-frontend && npm i && npm run dev

    # Run Admin (run from folder root)
    $ cd facial-vote-admin && npm i && npm run dev

You could also deploy it to AWS Amplify, by connecting your fork of the repo, providing the necessary environment variables, and deploying the application.

Other providers like Vercel can also be used to quickly deploy the frontend and admin section.

Backend Application

Contains the backend/serverless part of the application built using the Serverless Framework. Simply create the .env file with the right values and deploy the app to your AWS account:


    # Copy environment variable
    $ cp facial-vote-backend/.env.example facial-vote-backend/.env 

    # Deploy backend (run from folder root)
    $ npm i serverless -g
    $ cd facial-vote-backend && serverless deploy

    # Remove backend resources (run from folder root)
    $ cd facial-vote-backend && sls remove

AWS Services used

AWS Amplify: Used in the frontend to manage users authentication and acts as a point of contact between the frontend and AWS services like S3, IoT, and Cognito
Amazon Cognito: Handled Authentication and management of users.
Amazon EventBridge: Acted as a link between services. Choreographed the movement of events between some AWS services.
Amazon Rekognition: Used to index, detect faces in the picture, and compare faces when users try voting, it was the heart of the facial voting feature.
AWS Lambda: Lambda function used to run server codes and application logic.
Amazon SES: Used to send OTP codes during the user account retrieval step.
AWS IoT: For real-time communication between the server and the frontend application.
AWS Step Functions: Acted as the orchestrator and brain of the application business logic.
Amazon DynamoDB: Used as the Database service owning to its Schemaless/Nosql design, Serverless nature, fast and highly scalable nature.
Amazon S3: Was used as storage for the uploaded faces.
Amazon API Gateway: Used for API management and endpoint creation.
AWS CloudFormation: Used to provision resources used by Serverless Framework and the application in general.
AWS STS: Used to generate temporal credentials.

Other Technology used

Next.js: Used to build the frontend application
Serverless Framework: Choose this over the AWS SAM, as I am more familiar with it, and seems easier to use.

How it works

The following below details how the application works, it is broken into 4 sections, which are:

A. Face Index Flow

Frontend was created using Next.js and hosted on Amplify (and Vercel). New users enter their email to retrieve their account(Admin has created users by adding users' email to the Cognito user pool).
Once the email is found, a custom challenge for authentication is fired, it sends an OTP using SES to users' email to verify they own the email they are claiming. Once OTP is correct, a new step is shown to upload their face to attach it to their retrieved email.
The user then uploads their face photo, it goes to a private folder in S3, which has an EventBridge integration with a lambda function, this function gets the object details and initializes the Index Face Step function.
Each Step function task gets the object details and does its work, the first task makes sure it is a face that was uploaded using Rekognition, and the second task checks if a face exists already in Rekognition collection and prevents users from proceeding if a face is found, the third task indexes the face to Rekognition and the last saves the new Face entry record to DynamoDB.
AWS IoT is used to relay real-time feedback to the user on how each stage goes.

B. Face Recognition / Vote Flow

This flow was the most complex of the 4 I had to deal with. As I needed to make it as secure as possible while still maintaining speed and efficiency.

Users use the application to upload their faces image to a public folder in the S3 bucket.
The user is subscribed to the custom image name generated before uploading to S3.
EventBridge trigger watches that folder and calls the lambda function integrated. This function then initializes the CompareFace Step Function with the object details.
The Step Function tasks do the following: validate it's a face that was uploaded, check if the face is found in the Amazon Rekognition collection, and if it's found, it calls the next task.
It fetches the user's email and sends an OTP, this serves as a 2FA to prevent a user from using another registered user's face to vote. Then it calls the next task.
This task is a lambda function that generates a 15mins(configurable from .env) STS credential that has permission to invoke API Gateway and is sent back to the user using AWS IoT.
AWS IoT publishes the STS credentials, encrypted user id, and encrypted Otp to the custom image name topic user is already subscribed to. This way only a specific user gets the message, the user who uploaded the image.
The frontend application gets the message using Amplify and then fetches all categories that can be voted in. (This API endpoint is only secured with an API key, and not AWS IAM, as it isn't a private endpoint)
The user then proceeds to call the vote endpoint to add their vote, this endpoint is secured using API Key and AWS IAM. The generated STS credential is then signed and used to authenticate this request
The add/validate vote lambda function validates the vote details and then adds the vote to DynamoDB.
DynamoDB Stream is configured for the DynamoDB table, hence it sends this new vote to the stream.
A Lambda function is listening to the stream INSERT method for PK starting with VOTES and processes the vote details.
Then it uses AWS IoT to publish the processed result to the VOTE_ADDED topic, which users on the Live Result page are subscribed to so they see the vote coming in real time!

C. Live Result

From the frontend application, the user navigates to the live result page, which subscribes the user to a VOTE_ADDED topic which is published once a vote is added to DynamoDB.
Selects the category they want to see the result, and then the result they requested is shown.
Once a new vote is added to DynamoDB, it uses DynamoDB streams to stream the new record to a Lambda function.
This function(same as in B above) then processes the record and publishes the result using AWS IoT to the VOTE_ADDED topic the user already subscribed to.
AWS IoT relays this information to Amplify and this results in an update to the UI in real time without the need to refresh the page!

D. Admin Flow

Creates users and voting categories using the Next.js application
Currently only secured using API key, but should implement more security

Architecture

Took me around 4–5 days to come up with the architecture below, I factored in ease of use, security, cost, scalability, and efficiency as I designed it:

Face Index Flow

Face Recognition/Voting Flow

Live Result Flow

Admin Flow

Step Functions

DynamoDB Schema

Architecting the DynamoDB schema was another exciting part of this project. I used the Single-Table Design approach and learned this from a previous role I worked in, and also from Alex Debries' write-ups on it.

For further reading on this concept, I recommend reading Alex Debrie’s article where he wrote a detailed write-up on this, as well as AWS ReInvent 2020 talk he gave here.

You can also check out an article I wrote here about this architectural pattern here.

I made use of a composite primary key(Partition and Sort key) and the table had 1 Global Secondary Index.

PK: Partition Key, SK: Sort Key, GS1PK: Global Secondary Index Partition key, GS1SK: Global Secondary Index Sort key

Voting/ Vote Category

PK: VOTING#status

SK: voting_id#voting_name

Votes

PK: VOTES#voting_id

SK: face_id#candidate_id

Face Entry

PK: FACE_ENTRY#user_email

SK: face_id#uploaded_image_key

The Face Entry also has a GSI, which is stored when creating a new face entry:

GS1PK: FACE_ENTRY#face_id,

GS1SK: user_email#uploaded_image_key

Lessons learned

Cost: Throughout the 2 weeks I spent developing the application (Immediately deployed the app using serverless from day 1 and updated it as I made changes) and 2 days of testing the full process with some of my friends, I noticed the cost was still kept at a record low. The total during this period was a record low of 1.37 USD spent!
Debugging: Required a lot, and was helpful. Helped me catch a particular issue when the DynamoDB stream kept retrying as the Lambda function wasn't fully set up to process it, caught it on the 50th retry using Lumigo and Cloudwatch, had I not, it could have retired 10000 times, Yikes! Another helpful service here was Step Functions, as I could see input and output on each step and also replay the function with new or the same old parameters
**Permission issues: **An example is the lambda function that calls the Amazon Rekognition method to index, compare or save a face, it needed to have permission to access S3. I had a challenging time figuring this out as I thought that since it was Rekognition, it should have all permissions and not necessarily the Lambda function that calls it.

Why I choose this approach

Realtime updates: I needed real-time updates as key events occurred, like a user voting, other viewers on the live result page needed to see this new input reflect immediately without the need to reload their pages. AWS IoT, DynamoDB, DynamoDB streams, and Lambda were the best combinations I could think of, and they delivered!
Cost-Effective: Lambda, API Gateway, SES.
Service orchestration: Step Functions it was!
Serverless and Event-Driven: S3, EventBridge, DynamoDB, and AWS IoT were the key services here.
Reduced engineering effort: Amazon Rekognition, AWS IoT, Cognito, and Amplify really shone in this part.
Easier management: API Gateway, CloudFormation, and Cognito were the key services here.
Security: STS and Cognito were the key services here.

Conclusion

Embarking on this project was a great opportunity to implement lots of best practices I had learned from work and also from preparing and getting multiple AWS certificates.

Completing it makes me more confident of my AWS and cloud skills and I look forward to creating more of these as time permits.

I encourage you to consider using the event-driven and serverless architecture in your next project as it makes development seamless and efficient.

Happy building!

Build a WhatsApp Chatbot Voting Application Using NodeJs and Twilio

Nwachukwu Chibuike — Thu, 16 Mar 2023 14:07:32 +0000

Build a WhatsApp Chatbot Voting Application Using NodeJs and Twilio

With the rate of technological advancement taking place in this century, we are always finding new ways to automate our tasks and make our lives better. Chatbots help us reduce our dependence on our manual ways of communication and also challenges our preconceived way of implementing solutions.

What is a ChatBot?

In its mere definition, it is a software application used to conduct an online chat conversation via text or text-to-speech, in place of providing direct contact with a live human agent. It has been used in different contexts ranging from customer support, book tickets for movie/show, banking(UBA Leo) just to mention a few. Its use can only be limited by our creativity!

In this tutorial, we would be embarking on a creativity journey by building a voting WhatsApp Chatbot with NodeJs using the Twilio Platform.

After successfully following this tutorial, you would have learned how to:

respond to WhatsApp messages sent to your Twilio WhatsApp number
develop a Rest API based voting application
send free-form messages using the Twilio WhatsApp API

Prerequisites

To successfully follow through with this tutorial the following are required:

Basic knowledge of NodeJs
NodeJs and Npm installed on your machine
A WhatsApp enabled Twilio number
Twilio Account
An installation of ngrok

Setup and Installation

We would make use of Nodejs. Start by creating a directory, then cd into it and run this command

$ mkdir e-voting && cd e-voting

Then we initialize a node project by creating a package.json, the command allows the creation of the file without us entering prompt values. You can later change the values in this file.

$ npm init -y

Next, we proceed to install the packages we would be using

$ npm i express twilio

Express — We use to set up our server

Twilio — The Twilio Library we would use to send messages

Now that we have our environment set up, let's proceed to our Twilio sandbox to set things up.

Setting up the WhatsApp Sandbox

In other to give our chatbot access to the messages from WhatsApp, Twilio provides a very robust WhatsApp API that allows us to both send and receive WhatsApp messages right from within our application.

However before we can start sending and receiving messages using the Twilio WhatsApp API in production, we must first get a WhatsApp Approved Twilio Number which will act as our WhatsApp number for sending and receiving messages. For this tutorial we would not involve ourselves in that process, we would rather leverage on a safe sandbox Twilio provides for development and testing purposes.

To begin using the Twilio WhatsApp Sandbox, we proceed to the WhatsApp section on the Twilio dashboard and send a message to the sandbox number provided; usually, +14155238886 with the provided code, which is in the format join-{unique word}:

You should receive a response similar to the one below once you join. If you didn't check the process you followed to make sure you didn't miss any step.

Building the App

From the installation, we have only a package.json file in our project. We would then create a new file called index.js which would be used to set up our application server(with expressjs)

The above simply uses express to spin up a server and uses a route file which was imported on line 2. We would later send all request to our server on the /vote route which points to this external route file.

Next, we proceed to create a routes.js which would hold the logic

I know this file looks quite a lot but with some explanation, you would see it's not that complex. To make the explanation easier I would be explaining section by section.

The First Section spans from Line1–5 is where we install helpers files and methods into our application. At Line 3, we installed the Twilio official NodeJs module which we would use to send back our response. Line 4 we imported our helper response module(this would help format our various responses). Line 5, sees us introduce our utility module where we store our helper functions.

The Second Section spans from Line 7–25 is where we define our file variables and default values, like votes and candidates.

The Third Section spans from Line 27–43 and only consists of one function, showCandidates, we simply use this to show our list of candidates once requested by the user.

The Fourth Section spans from Line 46–136 and consists of four functions which are in charge of actually accepting and validating users vote and showing the result to the user. The first two functions are the actual voting while the last two are for showing results. Here is how it works:

a) castVote(): It begins the voting process and also takes users vote. Once a user chooses to vote and this method is called for the first time through Line 218, it creates a tracker for that particular user in the server through Line 82, after it has performed a check to ascertain that there are candidates to be voted for(Line 81).

It then returns a response with the list of candidates with their id to enable the user to know how to vote for their chosen candidate in their next chat, it also includes a way to cancel the voting process and remove the tracker from the user end by appending the unique value(0) which should be used by the user to opt-out of the voting process (Line 83 which calls list_of_candidate accepts showCandidates function as a parameter).

When the user responds next with a chat, we then check by converting the chat value to a Number and check its value, if it's a 0, we know the user wants to cancel the voting process(Line 203), we then cancel the process and send a response to the user that we have. If the user rather sends any other value we then call castVote with the required parameters(Line 207).

When castVote is called and passed these values we then go to line 75 where we make sure the user hasn't voted before, then we proceed to Line 76 to recheck that the user has indeed begun the process of voting and lastly we proceed to confirm that there are actually candidates to be voted for in Line 77. After this, we call addVote in Line 78 with the provided parameters.

b) addVote(): This function is charged with the actual reception of users vote. Firstly we check at Line 58 to make sure that the value supplied by the user actually is an id of a Candidate. We then proceed to add that users vote, remove them from the voting process and send back a successful response (Line 61-63).

c) showResult(): We use this function to show the result to users. Line 118–119 is simply used to validate and make sure that votes and candidates exist respectively. At line 121 we group all votes by the candidate. Then at Line 122, we format the response we get from Line 121 in such a way we can show the user the name of each candidate, the total votes they amassed and their percentage of votes. Also, we show a winner or draw where applicable(the formatResult function at Line 95 helps us with this formatting and result response.

d)formatResponse(): Like said above, found at Line 95, it simply gets the grouped votes by their candidates, then it returns the names of each candidate, their votes count and percentage of votes. It also checks for a draw or winner and returns this formatted result as its response.

The Fifth Section spans from Line 139–191 and consists of display and default message and a footer which we include for every response. showDefaultMessage() is used at the beginning to show a list of actions that can be performed. showHelp() **shows the help menu whenever it's called while the **footer includes an additional message to all response.

The Sixth and Last Section which spans from Line 191–243 is where we accept the post request made to the server, parse the body content, process the user input and send a response. Line 197 simply gives us the user phone number, this is the unique identifier for each user. We use the switch statements to get users response and call the corresponding function.

That's basically what this file does, it serves as the engine of our chatbot.

Next, let's add the utility.js file that would hold our helper files

We have just 4 methods here that basically help us to perform various manipulations of data.

We also include our responses.js file

Now that we are done with the coding section, your project structure should look something like this:

We then have a functional server, we would now proceed to create a webhook that would allow us to redirect requests.

Create a Webhook

This allows Twilio API to be able to send the request to our application endpoint. This is where ngrok.io.

If you don't have ngrok, proceed here to see how to get and set it up to run in your system. We are going to use the URL provided by ngrok as our webhook URL.

But before we do that we need to start our server, let's open a terminal at the root of our project and run:

node index.js

This would spin up our server and expose it to a port. In our case, that port is 4000.

Next, we open a different terminal and run

ngrok http 4000

You should then see this on your terminal, Ngrok doing its job!

Though not needed we could go to the Web Interface URL(http://127.0.0.1:4040) provided in the image to see requests as they are made to the endpoints:

Now update the webhook in Twilio to point to the exposed URL provided by Ngrok. This would redirect all messages from Twilio to our nodeJs server running locally on our system. Head over here and input the URL obtained from Ngrok and append it with /vote as this is our full endpoint. Then update the input field labelled “WHEN A MESSAGE COMES IN” with this value.

For our case, we would input http://9905d7076291.ngrok.io/vote

Testing

Now that we have set up our webhook, let’s test it out on WhatsApp. A Hi message responds with the default message we supplied in our code. We can see that working properly:

And when we send 3 to the bot, we get polling results back, it works!:

Demo

The Live demo can be found here. I went further to add more features to the project, the complete project with admin functionality and features can be found here.

Conclusion

A major reason why I love this voting application is that it allows me to partake in a voting process without having to leave my best messaging platform.

Technological advances have enabled us to live out our imaginations which we would have never thought possible in the previous century. I have just lived out one of mine! I can’t wait to see what you build!

How I Ace Technical Interviews — A Personal Guide

Nwachukwu Chibuike — Thu, 16 Mar 2023 14:04:34 +0000

How I Ace Technical Interviews — A Personal Guide

There is no single and accurate test for knowledge, however, every organization must prepare its own process to vet and hire talents. The outcome: A series of rigorous, specialized, and challenging set of tests that evaluate your coding skills, communication skills, problem-solving abilities, and your personality in general; *this process has come to be known as a** Technical Interview.***

Although this process( which entails both phone screening, online coding challenges, 1–1 coding interview) may seem challenging and scary, it's a lot easier when you know what to prepare for and how to go about it.

The interview is harder than the actual job!

What Is a Technical Interview?

It happens to be an assessment of candidates' abilities by taking them through a series of exam-like stages instead of a single and straightforward test. This involves one or all coding challenges, assignments, phone calls.

There is a common saying in software development that the interview is harder than the actual job. *How far this saying has traveled goes to tell us how demanding some interview processes are.*

The process is quite tasking and demanding for all levels of developers but happens to really affect the beginners due to:

their lack of adequate preparation.
their anxiety caused by a lack of experience.
their inadequate problem-solving skills.
their poor grasp of basic CS.

Now that we have gotten over the long definitions, let get to the fun part!

Over the last year, I have undergone a series of Technical Interviews, in both Local, International, and Outsourcing Platforms. Hence, I would be sharing my take on each stage I encountered, tips on scaling through each stage, things to avoid, things to take out from the process, and a general overview of it all.

Stages of the Interview Process

Yes! You have just received that mail from the recruiting team to inform you that your resume caught their attention and they would love to move ahead with you to the next stage: the Technical Interview stage. Thumbs Up!

At this point adrenaline shots within your body and you are filled with excitement and then when it subsides you come to face another reality, the fear of what to expect in this new stage. Well, welcome to the club!

Based on my experience these are the common stages the entire process takes:

Phone Call.
Assignment/Timed Coding Challenge.
1–1 Coding Challenge.

Phone Call Stage

This could take the shape of a phone call asking about your personality, a bit about your skill and expertise, experience, passion, and expectation.

The key thing to focus on here however is the ability to show our enthusiasm, passion for tech, communication skills, knowledge about the company, and work approach(do you love working in a team, open to remote).

The key takeaway from this stage is that at its end both parties would be better informed about each other, what the job entails, the skill set required, and experience levels.

Assignment/Timed Coding Challenge Stage

This stage could involve them sending a take-home assessment to be completed and submitted at a specific time or an invitation to a platform where a timed coding task would be assigned.

**Assignment(Take Home) — **This usually occurs to test one's knowledge level and ascertain if the skill listed in a resume is actually valid and if one possesses the skills needed in the organization. A specific language or framework could be required. From my experience, the key things to be done here is to get a proper understanding of the questions before attempting to write a single line of code(to see the catch), use best practice to stand out(proper structure, DRY approach, clean code), code documentation (include a README.md file), writing of tests!
**Timed Coding Challenge — **This usually occurs to test one’s CS fundamentals, ability to work under pressure(the timed environment on its own is pressure, lol). Before beginning, take time to understand the environment been used, the question’s edge cases, and what is required. On some occasions, a human interview may be at the other end to observe the process and make sure there are no irregularities.

1–1 Coding Challenge Stage

Here, we are expected to solve some challenges that may build on the previous stage or not at all. The interview may ask why certain choices were made in the previous stage, hence it's good practice to do all stages ourselves without external help!

A major mistake I have seen made by lots of developers is that they tend to not engage their interview adequately by not taking them through their thought process, asking questions for clarification. A friend of mine told me a story of his friend who was invited to a 30mins challenge and he spent more than half the time understanding the environment! He could simply have asked!

Speak boldly and precisely, ask questions about the task before even starting, engage and communicate with the interviewer throughout this stage as we walk them through how we intend to solve the challenge, be open to feedback.

Hence the key thing to focus on here is our collaborating skills, technical/coding skills, problem-solving skills. These are skills needed to be shown at this stage, keep that in mind!

General Tips

Do mock interviews.
Practice algorithm challenges on sites like Hackerrank, Codewars, Codility, and their likes.
Send out more applications so as to become more familiar with the process.
Study up on most CS fundamentals.
Study more on best practices in your domain.
Pick a language and be an expert in it!
Learn how to manage your time properly.
Practice how to stay calm and also how to communicate effectively.
Review your previous interviews(if any) and learn from them.
Believe in your abilities.

Things to avoid

These are common mistakes I and some other developers made and which came back to haunt us:

Not engaging the interviewer; they are humans too you know.
Not preparing adequately.
Not receiving feedback positively throughout the process.
Not thinking through before actually attempting to write codes.

Off you go!

With these tips, you are in a good shape to ace that technical interview and move on to the next stage.

The world awaits you!

How laziness saved my life

Nwachukwu Chibuike — Tue, 08 Dec 2020 23:29:48 +0000

A crash course on effective laziness.

I feel quite lazy to find the best intro to this piece, I’d just lazily get to the crux of the matter. The writing of this article even took a lazy approach from the title (which I got from a book I read five years ago and which best expresses my ideas), to the proofreading (which was done by my close friends), and down to the publication (lol) because I didn’t have much time and also because some were just beyond me.

I remember attending an executive orientation by someone I’d refer to as brother, since then his instructions about managing time and getting things done have remained with me. Amongst other things he taught that day, the power of delegation stood out for me. People need to learn to work as a unit to get stuff done and learn to delegate various tasks to others. If there is anything I learnt so far in my little experience in leadership, it is that you don’t need to do all the work, rather you need to just learn the art of delegation and watch people do the tasks while you coordinate, thereby boosting their self-confidence and also getting adequate rest for your body (since you are no machine). Anyone who has ever tried this approach, would find that it pays to be LAZY, because it gets the work done faster, saves energy and one could use the rest of the time to watch Iron man make that snap that sends the mighty Thanos packing.

It is sad that we rather find ourselves in a generation where people are made to believe that working independently at all times, is a show of self-will, strength or other abilities. This, however, is only a partial truth and leads to unhealthy competition as well as low productivity. Due to this mind-set, hidden deep within people, they tend to feel ashamed and insecure whenever the need arises to seek help and this leads most often to a failure of some sort. Those who eventually do, do it as a last resort, after trying multiple obviously wrong options which could prove detrimental to their health, career, finances, spirituality, family etc. Strong-willed people suffer from this too and sometimes they get the required results, but in the long run they tend to make mistakes; except if they are as Malika, the Warrior Queen; some even go to the extreme by (consciously or unconsciously) seeing everything as a competition.

I have learnt(and still learning) to stop competing with people but rather to learn from them and reduce the probability of failing and trying again when there is someone to guide. This underlying laziness has saved me strength for more important things.

It has been said of successful people, that they focus on the important things while leaving the trivial issues to others through delegation and teamwork. This can be referred to as being smart but I choose to call it effective Laziness-Laziness with a purpose. For instance, why would I take the struggle to understand a difficult topic when I have a friend that could explain it to me in minutes? Or why would I struggle to do something all over again when it has been done by someone else? Like it is said in programming, if the wheel is not broken don’t fix it!!!

As a programmer I love doing things from scratch, this enables me to learn the fundamental technology and this has helped me in my career so far. To be honest, I have also learnt the hard way that not everything needs to follow this approach, some need you to save the time and resources it takes to start from scratch and just use a tool already built by another lazy programmer (which must have been duly tested by the community) to get the work done faster, better and up to date with industry standards, never reinventing the wheel since it is not broken!!!.

Finally, everything depends on your ability to know when to be Lazy about issues.

Display Build Status and Test Coverage Badges for a Laravel Project

Nwachukwu Chibuike — Tue, 08 Dec 2020 17:32:04 +0000

In search for a new developer role, I found myself building various projects just to scale through multiple interviews. One in particular was a Laravel project that included a specific instruction to display both build status and code coverage report as badges in my readme.md file.

I searched for help online but couldn't find any that gave the full guide to solving this problem, most only provided solutions for build status while ignoring the code coverage aspect. I had to figure this out and time was running out.

This below is what I intended to achieve and I would be showing how I accomplished this

Setup repo with Travis CI and Coveralls

If you haven’t already, the first thing you need to do is to move over to Travis and login using your GitHub account. Once logged in hit the “Add New Repository” button to activate your repo. Repeat this procedure at Coveralls.io.

Configure PHPUnit and Coveralls

Luckily for us, Laravel comes shipped with PHPUnit. This tutorial assumes you have some tests written already. If not, it's as simple as checking out the Laravel docs for writing test.
We're also going to install Coveralls, which we'll use to host the coverage report by simply require it:

composer require php-coveralls/php-coveralls

Or by adding the following line to the require block of your composer.json file.

"php-coveralls/php-coveralls": "^1.1"

This would add it to our composer.json file as a dependency.

Create a .travis.yml and .coveralls.yml

We would now proceed to create a Travis configuration file(.travis.yml) at the root of our Laravel project to get Travis CI set up. Also we would be creating a .coveralls.yml which would be used to set up the path to our clover.xml

Here's what my .travis.yml looks like: I'm setting the language, the version of php, and telling it which additional script to run.

language: php
php:
  - 7.3
  - 7.4
os: linux

before_script:
  - rm -rf composer.lock
  - composer install
  - cp .env.example .env
script:
  - mkdir -p build/logs
  - vendor/bin/phpunit -c phpunit.xml
after_success:
  - travis_retry php vendor/bin/coveralls
  # or enable logging
  - travis_retry php vendor/bin/coveralls -v

Here's what my .coveralls.yml looks like: I'm assuming your phpunit.xml saves its clover.xml at the build/logs path.

coverage_clover: build/logs/clover.xml
json_path: build/logs/coveralls-upload.json
service_name: travis-ci

For the benefit of doubt, this is how my phpunit.xml and .env.example files looks like:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="vendor/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>

        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <logging>
      <log type="coverage-html" target="tests/coverage" showUncoveredFiles="true" />
      <log type="coverage-clover" target="build/logs/clover.xml"/>
   </logging>
    <php>
        <env name="APP_ENV" value="testing"/>
         <env name="DB_CONNECTION" value="sqlite"/>
        <env name="BCRYPT_ROUNDS" value="4"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="MAIL_DRIVER" value="array"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SESSION_DRIVER" value="array"/>
    </php>
</phpunit>

APP_NAME=Laravel
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=http://localhost

LOG_CHANNEL=stack

DB_CONNECTION=sqlite
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=:memory:
DB_USERNAME=homestead
DB_PASSWORD=secret

BROADCAST_DRIVER=log
CACHE_DRIVER=file
QUEUE_CONNECTION=sync
SESSION_DRIVER=file
SESSION_LIFETIME=120

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

MAIL_DRIVER=smtp
MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null

PUSHER_APP_ID=
PUSHER_APP_KEY=
PUSHER_APP_SECRET=
PUSHER_APP_CLUSTER=mt1

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

Deploy code and display badges

Here's the code for both of the badges I used in my readme.md file. Both Travis and Coveralls will supply embed links for these.

Travis CI Build Badge

[![Build Status](https://travis-ci.com/chyke007/credible.svg?branch=master)](https://travis-ci.com/chyke007/credible)

Coveralls Code Coverage Badge

[![Coverage Status](https://coveralls.io/repos/github/chyke007/credible/badge.svg?branch=master)](https://coveralls.io/github/chyke007/credible?branch=master)

Now once we push our code to GitHub with this setup it should send the build off to Travis, and Travis should send the coverage off to Coveralls.

That is all, in general it was an exciting adventure, hopefully this serves as a guide to someone, a guide I wish I had!

Build a surveillance system using Raspberry Pi, NodeJS and Pir sensor

Nwachukwu Chibuike — Tue, 08 Dec 2020 14:44:43 +0000

On February 2018 my interest in embedded systems began after reading couple of articles on the topic and discussing with some friends of mine that had an idea on it. That been the case nothing really caught my interest than when I saw that JavaScript, a language I was very familiar with, was also in the embedded space through NodeJs( Server side JavaScript).

In the article I would be showing you how I used the Raspberry Pi 3, NodeJs, Pir sensor to create a monitoring system. This system depends on the internet to send notifications and hence can be regarded as an IoT system.

Disclaimer: In this article I am assuming you have already set up the NodeJS environment in the raspberry pi and have everything installed and set up ready to run. If not please check out tutorials on setting up the Raspberry Pi 3 and NodeJs

Tools we would be needing

The following below are the tools, packages, services I used to carry out this project:

Raspberry Pi 3: The Raspberry Pi is a series of small single board computer developed in the United Kingdom by the Raspberry Pi Foundation to promote teaching of basic computer science schools and in developing countries. I used it here as our mini computer system.
Pir Motion Sensor: Pyroelectric (“Passive”) Infrared Sensors allows you to sense motion, almost always used to detect whether a human has moved in or out of the sensors range. I used it here to detect motion
Nodemailer: A node package for sending mails, I used it to send mails
onoff: A node package which has GPIO access and interrupt detection with Node.js, I used it here to interface with the Raspberry Pi GPIO pins.
RGB Led Light: Used as a signal system here to show when motion has been detected. It consist of three colors red, green and blue.
Breadboard: A breadboard is a solderless device for temporary prototype with electronics and test circuit designs. Most electronic components in electronic circuits can be interconnected by inserting their leads or terminals into the holes and then making connections through wires where appropriate. I used it here to connect some of my hardware.
Jumper wires(Female to male and Female to Female): These are electronic wires I used to connect my hardware's.

Work time

Time to get our hands dirty!

Setting up hardware to board

Setting up the RGB Led Light: Insert the three output legs of the RGB Led Light to the breadboard. Then insert the female-to-male jumper wire(male end) to the breadboard parallel to each leg of the RGB, attach the opposite ends of these jumper wire(female end) to any GPIO pins in the Pi you would want to use, in this article we would be using 2,4,17.
Setting up the PIR Sensor : The sensor should likely have three ends, one for power, one for ground and one for output . Depending on the one you purchase, see a guide online on how to connect it to the pi board. In this article we would be using the GPIO pin 27 for output.

Setting up the mailer module

First create a folder we would be working in and move into it, create a package.json file by running npm init and following the prompt, then install the node package by running this code:
```
  npm install nodemailer
```
This would add the nodemailer to the node modules directory as
one of our dependencies.

Create a new file called mailer.js and open it in any text editor of your choice, we would be writing the mailing function needed in this file.

  const nodemailer = require("nodemailer");

  const transporter = nodemailer.createTransport({

  service:"Gmail",

   auth:{

    user:"yourmail@yourmail.com",

    pass:"password"

   }

 });

 module.exports.sendEmail=function() {

 if(timerId)return;

 timerId=setTimeout(function() {

  clearTimeout(timerId);

  timerId=null;

  },10000);

  const mailOptions={

   from:"SMART SURVIELLANCE ",

   to:"yourmail@yourmail.com",

   subject:"[Pi Bot] Intruder Detected",
   html:
   "Mr/Mrs/Miss. Your name ,

   Someone is trying to steal your raspberry pi 3.

   At : "+
   Date()+

   " 
    Love,
    Pi Bot"

   };

   console.log("Sending an Email now..");

   transporter.sendMail(mailOptions,
     function(error,info) {

      if(error) {

        console.log(error);

      }else{

        console.log("Message sent: "+info.response);

      }

    });

   };

First and foremost we import the nodemailer package into our
code(line 1), then we add our credentials using the nodemailer
createTransport method(line 3–15).

We then initialize a variable that is used to delay the execution of mail sending until after 10 seconds of motion detection occurrence, so as to prevent multiple mails been sent when motion is detected at close intervals(line 21–27).

The next section simply uses a variable mailOptions to store the details of the mail to be sent(line 29–50), while the transporter.sendMail method proceeds to send the actual mail, we use a callback here to check if the message was sent or not and then show the corresponding message in the console(line 54–67).

The module is then exported using the in built NodeJs exports method as sendEmail

Making the system functional

Create an index.js file located in the same path as the mailer.js file created earlier. This file would be the default entry file for our NodeJs application. As usual I would be pasting the code and then proceed to explain

const Gpio = require("onoff").Gpio;
const LED1 = new Gpio(2, "out");
const LED2 = new Gpio(4, "out");
const LED3 = new Gpio(17, "out");
let state = 2;

const pir = new Gpio(27, "in", "both");

pir.watch(function(err, value) {
  if (err) exit();
  let blinkInterval = setInterval(blinkLED, 250);

  console.log("Intruder detected");
  console.log("Pi Bot deployed successfully!");
  console.log("Guarding the raspberry pi 3...");

  if (value == 1) require("./mailer").sendEmail();

  setTimeout(endBlink, 15000);

  function endBlink() {
    clearInterval(blinkInterval);
    LED1.writeSync(0);
    LED1.unexport();
    LED2.writeSync(0);
    LED2.unexport();
    LED3.writeSync(0);
    LED3.unexport();

    //included when we are working with sensors
    pir.unexport();
    process.exit();
  }
});

function blinkLED() {
  if (state == 2) {
    if (LED1.readSync() === 0) {
      LED1.writeSync(1);
    } else {
      LED1.writeSync(0);
      state = 4;
    }
  } else if (state == 4) {
    if (LED2.readSync() === 0) {
      LED2.writeSync(1);
    } else {
      LED2.writeSync(0);
      state = 6;
    }
  } else {
    if (LED3.readSync() === 0) {
      LED3.writeSync(1);
    } else {
      LED3.writeSync(0);
      state = 2;
    }
  }
}

Firstly we import the onoff package and then use the GPIO method(line 1). Then we assign the three output of the RGB light to three variables and also initialize a state variable that would be used to know the current color in the RGB Led Light been shown(line 2–5).

We also assign the Pir motion sensor on the Raspberry Pi pin 27 to a variable(line 7). After which we write a pir.watch function that watches for false positive from the Pir motion sensor(line 9). If there is an error we exit from executing the code, if not, meaning a valid motion was detected, we proceed to call a function that blinks the RGB light at 250 milliseconds interval(line 11). This function simply uses the state variable to know the color of the led light currently showing and then shows the next color at the next interval.

We also import the sendEmail module from our mailer.js file and call it (line 17), after which we stop the blinking light after 15 seconds, clean up the program and exit(line 19–34).

And wolla!, we have built a very easy yet effective monitoring system by just writing a few lines of code, that goes to show the immense power of NodeJS when combined with the elegance of the Raspberry Pi 3.

Conclusion

You can do all sorts of things with this setup . You can even receive an sms or have Twilio call you whenever the alarm is tripped off!

Let me know what did with this setup and this amazing chip in the comments!