Goal: The purpose of this project is to learn how to use the Amazon AWS cloud platform and to develop an AWS application that uses existing cloud services. Specifically, we will learn:

1. How to create VMs (EC2 instances) in the cloud.
2. How to use cloud storage (S3) in your applications.
3. How to communicate between VMs using a queue service (SQS).
4. How to program distributed applications in Java on Linux VMs in the cloud.
5. How to use a machine learning service (AWS Rekognition) in the cloud.

Description: We are building an image recognition pipeline in AWS, using two EC2 instances, S3, SQS, and Rekognition. The project is written in Java on Amazon Linux VMs. For the rest of the description, you should refer to the figure below:

We will create two EC2 instances (EC2-A and EC2-B as in the figure), with Amazon Linux AMI, that will work in parallel. Each instance will run a Java application. Instance EC2-A will read 10 images from an S3 bucket (since the S3 bucket was provided by my school I cannot share it in public, but feel free to create an S3 bucket and add 10 images) and performs object detection in the images.

When a car is detected using Rekognition, with confidence higher than 90%, the index of that image (e.g., 2.jpg) is stored in SQS. Instance EC2-B reads indexes of images from SQS as soon as these indexes are available in the queue, and performs text recognition on these images (i.e., downloads them from S3 one by one and uses Rekognition for text recognition).

Note that the two instances work in parallel: For example, Instance EC2-A is processing image 3, while Instance EC2-B is concurrently processing image 1 that was recognized as a car by instance A. When Instance EC2-A terminates its image processing, it adds index -1 to the queue to signal to instance EC2-B that its work has been done. When instance EC2-B finishes, it prints to a file, in its associated EBS, the indexes of the images that have both cars and text, and also prints the actual text in each image next to its index.

Attempted Solution

The following solution was attempted using the AWS account provided by my school. If you have an individual account things should be a little different, but the idea is basically the same.

1. Login to your AWS account.
2. Once you login to your AWS Lab under Courses > Modules, select Learner Lab.
3. Start Lab and follow the Readme tab (located on top-right along with Start Lab, End Lab, AWS Details, and Reset buttons) to start your AWS environment. To start the AWS console make sure you click the AWS button with the green circle. Red circle means the lab is inactive and green circle means the lab is active.
4. Make sure you copy the AWS access_key, secret_key, and session_token (can be found in AWS details button) and paste it on your ~/.aws/credentials file. Along with that download the PEM file under SSH key to authenticate later when you access the EC2 instances through terminal. (Copy your AWS keys. These keys are available regardless of a student or an individual account).
5. Head over to the AWS Management console and search for EC2. Once you head over to the EC2 Dashboard, the following steps will help create two instances.

Create two EC2 instances to work parallelly:

1. Click on Launch instance.
2. Enter the name of the EC2 instance you want to create.
3. Under the AMI select Amazon Linux 2 AMI (HVM) — Kernel 5.10, SSD Volume Type.
4. Select Instance type to be t2.micro. T2 instances are a low-cost, general purpose instance type that provides a baseline level of CPU performance with the ability to burst above the baseline when needed.
5. Select vockey as a Key-Pair value which should be pre-populated. Note, you can create your own Key-Pair value with required permissions.
6. Under Network Settings, select Create security group and check the below settings.

• Allow SSH traffic from
• Allow HTTPs traffic from the internet
• Allow HTTP traffic from the internet
• And instead of Anywhere, select My IP to only send traffic from your IP address.

Note: It is recommended to not change settings under Configure storage and Advanced details unless you know what you are doing. Follow the above step twice to create two instances. My instances are named EC2-A and EC2-B and looks like this:

Add IAM roles to the created instances:

1. Once you create your instances, head over to EC2 instances to see your instances. If your instances aren’t running select an instance, click on Instance state dropdown and Start instance.
2. Once instances are running, select an instance (one-by-one) head over to Actions > Security > Modify IAM role.
3. From the dropdown select the **LabInstanceProfile** which is pre-populated. Please note, this role might not have access to S3, SQS, or Rekognition which is required for the project). And update the IAM role.
4. If the IAM role doesn’t have access to S3, SQS, or Recognition, head over to IAM > Roles > LabRole and provide the following permissions as policies:

• AmazonSQSFullAccess
• AmazonS3FullAccess
• AmazonRekognitionFullAccess

Once the policies are attached you are all set to access the EC2 instances.

Working with the JAVA programs:

• We will have two different programs, one is to recognize Object and the other is to recognize Text. Please read the project description to understand why we need two programs.
• The object detection program will run on the first instance while the second instance will run the text detection program.
• Please make sure you have the executable JAR files for each of the programs, as we will upload the JAR files in the instances.
• Once you have the JAR files ready you can upload it to the respective EC2 instances using Cyberduck (Mac) or WinSCP (Windows). I am using Cyberduck for the project since I’m working with a Mac system.
• If you want to learn how to upload file in EC2 instance using Cyberduck, follow the link — FTP into your EC2-instance with Cyberduck

Note: The username while you FTP to your EC2 instance using Cyberduck should be ec2-user.

SSH Access from Mac:

We will now SSH from Mac to access both our EC2 instances.

Note: These instructions are for Mac/Linux users only.

• Please read through the second and third point in this before you start to complete the actions, because you will not be able see these instructions when the AWS Details panel is open.
• Choose the AWS Details link.
• Choose the Download PEM button and save the labsuser.pem file. (Typically your browser will save it to the Downloads directory.)
• Open a terminal window, and change directory cd to the directory where the .pem file was downloaded. For example, run this command, if it was saved to your Downloads directory:

cd Downloads

• Change the permissions on the key to be read only, by running the command:

chmod 400 labsuser.pem

• Return to the AWS Management Console, and in the EC2 service, choose Instances. Check the box next to the instance you want to connect.
• In the Description tab, copy the IPv4 Public IP value.
• Return to the terminal window and run this command (replace public-ip with the actual public IP address you copied):

ssh -i <filename>.pem ec2-user@<public-ip>

• Type yes when prompted to allow a first connection to this remote SSH server. Because you are using a key pair for authentication, you will not be prompted for a password.

Once we SSH to the two EC2 instances we will have something like this:

Run the programs on respective EC2 instance:

1. Make sure to update your access_key, secret_key, and default_region on your AWS terminal.
   - To update the above information, type aws configure on the AWS terminal.
   - The default region should be us-east-1.
2. Once you are done with the configuration, run the programs using the command `java -jar <NAME_OF_YOUR_JAR_FILE>.jar`.
3. For the second program since we want to output the result in a text file, we can use the command `java -jar <NAME_OF_YOUR_JAR_FILE>.jar > output.txt`.

• An output.txt file will be created and the output of the second program (running on the second instance) will be recorded on the file.
• The file will have the necessary data about the indexes of the images that have both cars and text, and also prints the actual text in each image next to its index.

Running program on EC2-A instance (First EC2 instance):

• Once you run the AWSObjectDetection.jar on EC2-A instance the images that satisfies the condition will be pushed to the SQS (Queue).

• We have 6 items that are pushed to the queue, since only 6 items satisfies the condition (Label = “Car” and Confidence > 90).
• The queue is created like so:

• And the contents of the queues can be obtained by long polling:

Once we populate the queues we can see how does it look when we run the AWSTextRekognition program on EC2-B instance.

Running program on EC2-B instance (Second EC2 instance):

• We run the AWSTextRekognition.jar on EC2-B instance like so:

• When instance B finishes, it prints to a file (output.txt), the indexes of the images that have both cars and text, and also prints the actual text in each image next to its index.
• The final output stored in output.txt looks like this:

Resources:

• https://github.com/Boro23-wq/AWS-Image-Recognition-Pipeline

AWS image recognition pipeline using S3, SQS, and Rekognition. was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

One of the many reasons behind Next.js’s traction is due to the ability to render an application on the client-side (in the browser), on the server-side as well as the ability to statically generate pages during build time. Let us have a good look at what each of these terms means:

1. Client-side rendering: In a client-side rendered application, the server essentially sends a blank HTML page (loading state) to the client without any dynamic content. You won’t really see anything meaningful for split seconds. While the loading state is being rendered, the client (the browser) sends multiple API requests to the desired server to fetch the dynamic content and later rehydrates the application with the dynamic data.

2. Server-side rendering: In a server-side rendered application, the server pre-renders the page with dynamic data, and eventually once the hydration is done on the server-side, it delivers a fully populated HTML page with dynamic data to the client. Server-side rendering essentially generates the entire HTML for a page on the server.

3. Static-site regeneration: Static-site generation generates the pages during build time. Basically, a site that is statically generated will produce the HTML pages ahead of time even before any user requests. And, with Next.js’ Incremental-static regeneration (ISR), we can statically generate on a per-page basis, without needing to rebuild the entire site, which means that you can update the static pages incrementally as new data comes in.

How CSR works?

• When a client sends a request to the server for a webpage, the server sends a blank HTML page (without any dynamic data) to the client.
• The client immediately serves the blank HTML page with the loading state. (We would notice loading animations most of the time). That is when the client is making those API requests to fetch the dynamic data.
• Once the dynamic data is available the client-side/browser re-hydrates the application with the dynamic/new data.

How SSR works?

• When a client sends a request to the server for a webpage, the server essentially pre-renders and prepares the HTML page with all the dynamic data.
• That is the reason why server-side rendering tends to have slow Time To First Byte (TTFB) since they are doing work on the server.
• Once the server sends the pre-rendered page to the client, the client displays the HTML page. This helps avoid multiple trips to request data from the client-side as well.

How SSG works?

• The basic static-site generation involves pre-generating or generating the pages (with/without dynamic data) during the build time even before any user requests.
• The client displays the statically generated page instantly. But there is a certain caveat to this approach. By any chance, if we have a lot of pages to pre-generate, that will significantly increase the build time of the application.
• There’s another really interesting approach involving static-site generation which is called Incremental Static Regeneration (ISR). ISR allows to statically generate on a per-page basis, without needing to rebuild the entire site.
• Which means that an application will serve all the pre-built page as requested, but if the user requests for a page that wasn’t pre-generated, it will serve a fallback version (or a loading state), meanwhile Next.js will make API requests to generate the requested page on the server.
• And on subsequent requests to the same page, Next.js will serve the already generated page and won’t regenerate it.

Usecases of CSR, SSR, and SSG

Client-side rendering

• Authenticated pages or paywall/private dashboard pages.
• Pages with frequent data updates. For eg. Pages with real-time data updates.
• Banking websites where data is requested on-demand.
• Pages that don’t require SEO optimizations.

Server-side rendering

• Can be used with pages that require a heavy workload.
• Websites that require link previews.
• Websites with lots of pages (only render on request).
• Pages that do require SEO optimizations.

Static-site generation

• Documentation pages where data is not frequently updated.
• Blog sites.
• Great for isomorphic applications/websites.
• Pages that do require SEO optimizations.

Demo

I’ve built a basic application that demonstrates client-side rendering, server-side rendering, and static-site generation using Next.js. You can go ahead and check out the application at Pokedex w/ Next. The application was built in order to implement and help explain Next.js’ data fetching techniques. Next.js provides a really great developer experience by allowing the developers to choose how they want to render the application per-page basis.

References

• Next.js’ data fetching techniques.
• Demo application repo.
• Toptal — CSR vs SSR vs SSG

I built a Pokedex to demonstrate Next.js’ data fetching techniques. was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

At some point in time as a developer, you would very well come across using AWS S3 bucket as storage for uploading files. And that’s what we try to accomplish today. I will take you through the entire flow and let you know the exact setup/configuration I use to start storing any type of files in S3. I’ll be using Nest.js and Typescript for the demonstration. Although you can store anything in an S3 bucket (text files, images, videos, blobs), we will be dealing explicitly with images since we only want to store image files for the demonstration.

On a side note, we will not require any access/secret AWS config keys since we will be using localstack as the development environment. Localstack, if you don’t know already basically helps us avoid the tedious upfront work that you would generally put in configuring the development environment which I’d say can be a lot time-consuming. In case if you do want to have the access/secret keys, you are great to have those. Include them in a .env file and make sure to pull it out in the S3 config provider file.

Also, I am using the localstack docker image that will help me support the AWS cloud services like S3. Go ahead and pull the localstack docker image if you don’t have it already. Once you install that, you will be ready to keep going. If you are looking for a guide that will help you install and configure localstack you can visit their Github.

Quick steps to install localstack

• Download the Docker Desktop for your system. You can find the downloadable files here.
• Pull the localstack docker image from Docker Hub. You can find the image here.

S3 Config Provider

We have the S3 config provider that does all the setups that we require to get started. Since we don’t actually require any real access/secret keys we can hardcode the keys like so or if you have the keys be sure to pull it out from the .env file. We now have the S3 object with the required config. We have the methods getS3() and getBucketName() to export the S3 object and the name of the bucket to be used anywhere in the project.

Also, be sure to run the createBucket() method once to create a bucket for you with the bucket name testbucket. You can make use of the last line to create a bucket.

Defining the DTO

Let us define the DTO of the image file object along with the response object that we will receive once we upload the image to the S3.

We are all set with the DTO. Now we can go ahead and define the only route that will handle the HTTP POST request in the controller.

Controller Class

Inside the controller file, we define the route or path prefix /upload that will take care of the action to upload the image file to S3. We are using FileInterceptors to only intercept files with a specific key. The upload method below will delegate the rest of the operation to the service file by calling the upload method inside the service file which performs the required logic to upload the image to S3.

The primary objective of a controller is to handle incoming requests to one of its endpoints and return responses back to the client. Here, we finally return a response success/error object notifying if the image was uploaded or not. Let us now write the logic to actually upload the image to S3 inside the service class.

Service Class

The service class (ImageUploadService) is responsible for uploading the image to S3 and is designed to be used by the UploadImageController. What we have here is a basic service class. It creates an instance of the S3 provider to grab the actual S3 object to perform the upload operation on it.

The essence of a service class or a provider is to organize and share business logic, data, or functions with multiple components within an application.

We finally return a promise with the resolve/reject object based on if the operation was successful. The very next step is to bundle up the controller and the service file under one roof. A module is commonplace to group components, and services, which are related to the application. Let us do it using the module class.

Module Class

The UploadImageModule class creates a module with the controller and provider files that we’ve created earlier. Every module that we create inside a project can be shared. For example, if we had another module importing the UploadImageModule, it would have access to the UploadImageService and its methods.

The very last step is to actually import this module (UploadImageModule) into the root app module. Let us do just that for the final step.

Once we are done importing the UploadImageModule to the root AppModule we are good to test the application. We will be using the Thunder Client VSCode extension to test the endpoint. Before firing up the Thunder client make sure to run the Nest server and localstack using the commands below:

We can see from the image above we receive a response back with the data object containing the Link (URL) of the image uploaded to S3. The image is now accessible from the URL. There you go we are now finally done with implementing a service that uploads image files to an S3 bucket.

Thanks for sticking around.

References

• NestJS documentation
• Localstack
• S3 101: What is an S3 and why should I use it?
• AWS S3 official website

Upload image to AWS S3 (Localstack) using Nest + Typescript. was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have been writing Typescript a lot lately. I’m using it when I work on personal projects or when I’m working with a team. At first, I was just snowed under the fact that I would have to write so much more code and that didn’t really motivate me to pick it up. But that didn’t really stop me from not trying at all. I’ve read so many compelling blogs that proved why Typescript is a must-try and how it helps build scalable web applications, that I couldn’t help but try and get a taste for myself.

I wanted a resource that will help me get started. I went through the React Typescript Cheatsheet which helped me learn the essence right away. I also used a course from educative.io that helped me understand the building blocks and pieces. Once I was there I almost instantly knew that even though I was writing more code, I made my codebase very predictable and maintainable so to speak.

So here I am trying to get across the features that helped me adopt Typescript almost instantly. I’m pretty sure there are tons of benefits of a typed system, but I would just mention a few that I’m liking the most.

1. Code Navigation

We have a users.service file that imports a User class. A lot of times it might happen that you can’t quite remember or not sure what the shape of the User object might be, or a teammate of yours wanted to check out your code.

In that case, you can almost instantly switch between files (or navigate between files). Typescript can help you conveniently navigate between files in your codebase. You can also make use of the shortcuts below to easily navigate between files.

• Go to Definition (F12) — Go to the source code of a symbol definition.
• Peek Definition (Option or Alt + F12) — Bring up a Peek window that shows the definition of a symbol.
• Go to References (Shift + F12) — Show all references to a symbol.
• Go to Implementation (Cmd or Win + F12)— Go to the implementations of an interface or abstract method.

2. Code Predictability

With code-predictability TypeScript assures that variable/function types don’t change and it would only accept the type it was initially defined. If a variable is explicitly given the type - string, it can only hold values of the type - string. All of this makes the codebase so much predictable as you now don’t have to worry about things breaking down due to mismatch in types and assignments.

In the gif above, we notice we have a method called createUser that accepts a parameter to create a user. Now, there’s definitely a question as to what params it will accept. We try to insert a number but we are instantly thrown a squiggly notifying us about the type-mismatch.

To know more about the type the method accepts we can navigate to the service file. As we can see, the method createUser accepts a param of type string. And, now we are pretty sure about the params when we create couple more users in the future.

3. Code Refactoring

We have a class called Users that we export, which we are using in a lot of files on our codebase. The thing to notice here is that we want to change the Users class to be called a User (renaming for better naming convention) which makes sense because the User class represents the shape of a specific user. Let us try to rename the class and see what we run into.

As you can tell right away from the gif, the controller file turns all red. Not just the controller file but all the files that import the Users class will throw an error since the class doesn’t exist anymore.

This is how convenient code refactoring is with Typescript. We now just need to rename the class in each of the files it is being imported, rather than trying to figure out where you might have used that class. Also with Typescript, if you change the path to a file, the relative import to that file will be updated without you even having to update, which might be well intimidating if you have a lot of imports for the same file.

4. Less-error code

In a paper published by Microsoft, it has been stated that TypeScript could have helped prevent 15% of the public bugs for public projects on GitHub. This number can be quite significant in terms of saving time during the inspection of common bugs. It helps mitigate the situation where you are trying to figure out the common bugs and your focus is completely diverted which is not really ideal.

Typescript helps to check types during compile time which now means that you’ll instantly be thrown an error that could have potentially break your code. It helps prevent shipping buggy code to the production while helping fix bugs relatively faster and with more efficiency.

5. Better IntelliSense

IntelliSense helps developers be more efficient while writing code. It provides features such as code completion, parameter info, and quick info, which is essentially a way of hinting you about what’s next.

In the gif above we assign the props to be of type addNumbers. We have defined the type of addNumbers. Since we have defined the type of the props, we can now have IntelliSense help us with code completion with the right values and methods.

IntelliSense can do so much more. It can help us with automatic imports, smart renaming of variables, fixing imports when changing relative paths to a file, and removing unused variables/methods.

Wrap Up

I would highly encourage you to try using TypeScript to have a first-hand experience and to try all the features that it enables, as we discussed earlier. It will very much help skyrocket the productivity levels while you write code and makes your codebase maintainable and scalable. If you are looking for a starting point I highly recommend you to visit the Typescript — Getting started guide to get started.

Typescript — Supercharged features of a typed-system was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction.

Nest (NestJS) is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, and is built with and fully supports TypeScript. — NestJS Docs

Essentially, NestJS is a layer on top of Node that has supercharged methods and implementations that can help us write server-side applications quick and easy. Nest is very convenient to content all your needs. It is highly customizable and by default uses Express under the hood but can be optionally configured to use Fastify as well!

Why might we need Nest.js when we have Node.js?

• Nest provides a layer of abstraction on top of Node, which means that it can now leverage the features of Node as well as expose supercharged APIs for better performance and efficiency.
• Developers love features and when you know you got more of them, you simply can’t deny it. That’s the case with Nest.js. You have now access to tons of third-party modules that can speed up your development process.
• I believe it’s not at all a complete deviation from the back-end paradigm. We are still writing the same kind of code, a very similar structure but with an added layer of robustness.
• NestJS is also highly configurable with ORM’s (like TypeORM) which we can make use of to work with databases. This again means that you also have great TypeORM features like Active Record and Data Mapper pattern that you can now leverage easily. The Active Record pattern can necessarily help you obtain simplicity while the Data Mapper pattern can help your code be more maintainable.
• Another point to add is that Nest admits that its architecture is heavily inspired by the Angular framework. It’s always a good idea of having effortless testing available when in need and a way to maintain the codebase efficiently. And, Nest provides you just that. A much-needed structure!

3-Tier Architecture Nest.js is predisposed towards.

When we talk about laying down a firm architecture, the most we care about is how we isolate different parts of an application such that the part that makes sense together lives together. Following an architectural pattern can supposedly help resolve spaghetti code that you might be writing.

For example: Considering the flow diagram below, we realize that controllers and service layer work together to carry out a logic but are entirely two different things. Controllers essentially deal with the routes of your application. A controller may have few different routes and it all depends on the routing mechanism to control which controller receives what request. But what if you dump all your business logic inside of the controllers. Maybe register a new user if the user is not yet registered or carry out validation checks just within the controllers.

That doesn’t make too much sense after all. It wouldn’t probably make much difference if you just have a small application. But when the application grows and you have to register more controllers and routes and have to write more business logic, that’s where things seem to get out of control and are certainly not maintainable.

1. Controllers: A controller’s sole purpose is to receive requests for the application and deal with routes.

2. Service Layer: This part of the block should only include business logic. For example, all the CRUD operations and methods to determine how data can be created, stored and updated.

3. Data Access Layer: This layer takes care and provides logic to access data stored in persistent storage of some kind. For example an ODM like Mongoose.

NestJS Project Directory structure.

Once you scaffold a new NestJS project using its CLI, it gives you a few boilerplate files to start with. These are the core files that you would normally work with. The directory structure would look something like this:

src
| — app.controller.spec.ts
| — app.controller.ts
| — app.module.ts
| — app.service.ts
| — main.ts

app.controller.ts: Controller file that will contain all the application routes.

app.controller.spec.ts: This file would help writing out unit tests for the controllers.

app.module.ts: The module file essentially bundles all the controllers and providers of your application together.

app.service.ts: The service will include methods that will perform a certain operation. For example: Registering a new user.

main.ts: The entry file of the application will take in your module bundle and create an app instance using the NestFactory provided by Nest.

Right away you know that there’s a certain structure laid out that you need to follow. And that is what helps developers write clean, scalable, and maintainable code.

Let us look at some code.

Let us create a service file and export a class called CatsService which will implement a few methods which we can import and utilize in our controller file.

Here we are exporting a class called CatsService and have defined three different methods. We also use @Injectable() which is a decorator. The decorator attaches metadata and marks a class available to be provided and injected as a dependency. Since we have injected this class as a dependency, let's use it inside of the controller to retrieve the cats.

In the controller file, we are importing the CatsService and have instantiated the service inside of the constructor. The CatsService dependency is injected through the class constructor (Dependency Injection). This will expose all the various methods that we have defined inside the CatsService. We can now retrieve the cats using the controller.

Dependencies are services or objects that a class needs to perform its function. Dependency injection, or DI, is a design pattern in which a class requests dependencies from external sources rather than creating them. — Angular

Here the decorator @Get() takes an argument (the method being decorated, in this case, getCats and getOneCat) and returns the same function with added functionality (or a return value in this case, which is a string).

Also, the @Get() decorator accepts a pathname that we can make use of to request a particular route. For example, a request to /cats/allCats will invoke the method getCats and return all the cats.

Making a request to the endpoint

Let’s request to the endpoint getAllCats that we just defined and see what we get returned.

As we can tell the return result is received as expected. This is technically the pattern that we are going to see a lot with Nest. We have a service file that will implement all the methods/logic of our application while the controller file will take care of returning the results from the services using appropriate routes.

The module file above bundles all our controllers and providers/services together and exports a class that can be imported to instantiate our application. Every application has at least one root module. Nest uses this root module to create the application graph — the internal data structure Nest uses to resolve module and dependencies.

We can also create multiple feature modules that will help us organize the code relevant to a specific feature. All the feature modules can then be imported inside the root app model. For demonstration, we only have one root module above (the cats.module.ts file in this case).

The main file bootstraps a Nest application for us while creating the module (CatsModule) we just created. The main file is the entry point of our application. To create a Nest application instance, Nest uses the core NestFactory class. NestFactory exposes static methods that allow creating an application instance.

There we have it. We have a simplistic NestJS application that pretty much describes the best practices and patterns that NestJS follows and how it can help build scalable, maintainable, and testable code. I hope this introduction to NestJS was fairly simple and can help you understand the blocks and pieces that work together within NestJS.

References

• NestJS Documentation.
• Node.js project architecture.

Nest.js — Architectural Pattern, Controllers, Providers, and Modules. was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

Zustand is a pretty neat state-management tool. When I say state-management, you might as well want it to be compared with Redux or Context. But, this blog wouldn’t be the typical rundown of pros and cons and comparing technologies as every technology has its own pros and cons. Instead, we are going to have a look at how Zustand makes it easy to get started with handling state on your applications.

By any chance, if you are looking for a top-hole definition of Zustand, here it is:

It is a small, fast and scaleable barebones state-management solution. It has a pretty neat API based on hooks and isn’t boilerplatey at all to start with.

Get started

To get started with Zustand you would need its npm package. You can download it from npm using:

npm install zustand

Create a store

Once we are done installing the package we can go ahead and create the store. Creating a store is as easy as it can get. We have a really basic example of how we can create a store and then access the store within components.

‘create’ in Zustand provides us with two different methods ‘set’ and ‘get’. The naming is probably self-explanatory of its purpose. The ‘Set’ method is used to set/merge the state, while the ‘Get’ method helps us to access the state in the store.

Bind within components

Right after creating the store, we can access the hook anywhere in our component like so. Neat and easy! Note, there is no extra provider required to access the state. Just select the state you want access to and Zustand will take care of re-rendering the component when the state changes.

Function ‘Counter’ grabs the value of count stored in the state and displays it within p tags, while ‘IncrementCounter’ performs mutation to the state by incrementing the state value.

Zustand simply makes life easier without needing to write too much code and its intuitive hooks API is sleek to be fair.

Fetch everything or slices from multiple states

While you can fetch the entire state entity all at once, it is not recommended since every state change will cause a re-render of the component. Fetching everything can be implemented as:

const state = useStore();

With Zustand we can also grab slices of multiple states without fetching everything right away. It is very helpful if you want to perform atomic state-picks.

const nuts = useStore((state) => state.nuts);
const honey = useStore((state) => state.honey);

Additionally, we can also define an object that performs multiple state-picks.

‘shallow’ allows us to trigger state update when keys of the object change or update. The above code will trigger a re-render when either of `state.nuts` or `state.honey` changes.

Performing asynchronous actions

Let’s not forget every time we build an application we somehow always need to reach out to an API for some data. And fortunately, Zustand has taken care of performing async actions for us.

I’m certainly mind-blown by how much work we can actually do with Zustand’s intuitive and clean API. I would highly recommend you to check out a few other features available with Zustand. For me, it was a kind experience for the fact that I didn’t need many configs to start with (literally zero-config upfront). It is pretty much convenient how simple the implementations are. If you want to try out a simple React application using Zustand, you can visit here and get a taste of convenience for yourself.

Zustand — A simple, fast, and convenient state-management solution using Hooks API. was originally published in Webtips on Medium, where people are continuing the conversation by highlighting and responding to this story.

We all want to create beautiful layouts, add exquisite animations, and want to deliver a top-notch user interface but let me be honest, how many of us are really aware of the web vitals that can help deliver a blazingly fast user experience. In short, Google uses these web vitals to provide quality standards on user experiences.

What are Web Vitals?

Web Vitals are essentially a way to quantify the user experience of one’s website, which if optimized can help deliver a great user experience. It is an initiative by Google and they have provided a few different tools to monitor the performance of websites. When one maintains a website it’s just not about delivering the website and putting forth the information for users to consume. But what we do need to take care of are the microscale details including “Does the user see what they want to see?” or “Did the same user visit your website for the second time?”.

Taking care of the modest details will surely take you a long way. In fact, it is a snowball effect. Small optimizations can lead the path to much larger optimizations going forward. Well even though there are a lot of things to consider while delivering a top-notch user experience, Core Web Vitals makes it relatively easy and simplifies the concept of user-centric design by helping us focus on metrics that matter the most.

What are Core Web Vitals?

Core Web Vitals primarily encompasses three specific measurements: Largest Contentful Paint (visibility), First Input Delay (interactivity), and Cumulative Layout Shift (stability).

Let us go through each of them and understand what they really mean.

• Largest Contentful Paint (LCP): It measures how fast your website loads. Anything below 2.5s is deemed a good score.
• First Input Delay (FID): It measures how long a user has to wait before they can interact with your website. Anything below 100ms is a good FID score.
• Cumulative Layout Shift (CLS): It measures the visual stability of a website. It mainly occurs due when an asynchronous event fires and inserts DOM elements on the fly on top of existing content.

Tools to measure Core Web Vitals.

There are a handful of developer tools that support Core Web Vitals. Below I have put up a picture just to display a few. You can make use of the tools to generate the Web Vitals score report and see how far you need to optimize your website.

There is a really descriptive workflow described in the web.dev blog that talks about how we can use all of the tools above to optimize the Core Web Vitals for a website. If you have some time and want to understand it better I would highly suggest you follow the link above. If not, let me write down the essence for you quickly.

• First of all, you can use Search Console’s Core Web Vitals that will generate a report to help you identify the number of pages that require optimizations. And, this is all generated based on field data. Field data is essentially Real User Metrics (RUM) data of real users over the course of a duration (usually a month).
• Once you have the pages that require some digging, you can then use PageSpeed Insights (which I highly recommend) to generate lab and field data on the webpage.
• If you are down to optimize your site locally, using tools like Lighthouse and Chrome DevTools can help you boil down every aspect of Core Web Vitals that requires optimization.

A great resource would be to use web.dev/measure that can help prioritize a set of guides for optimization. Also, it is recommended that you use Lighthouse Continuous Integration (CI) on every pull request you make to make sure you have optimized the site before deploying the changes to production.

I would suggest you use PageSpeed Insights to generate the Web Vitals score right away if you don’t know where to start.

Get started with PageSpeed Insights

To get started let us go ahead and see PageSpeed Insights’ typical report that records the core web vitals scores. PageSpeed Insights has an intuitive UI and the navigation is quite simple. Also, you will have an option to optimize for both Mobile and Desktop devices. Make sure you generate a report for both the device types as you will likely have different scores for different devices.

Once you have the URL of the site you want to generate the report for go ahead and click analyze. It might take a few seconds before you see something like this:

As you can see the result is based on the real-world field data and says if the page passes the Core Web Vitals assessment or not. The report records four different web vitals. They are First Contentful Paint (FCP), First Input Delay (FID), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS). You can also view suggestions based on each page by analyzing individual page URLs. Suppose you want to generate a report for the About page of your portfolio, you can go ahead and check the About page (www.portfolio.com/about) and record its scores.

Additionally, you also receive a Lab score which essentially means that the scores are based on assumptions of user data. The lab score would look something like this:

Lab score comes along with a brief description of what these scores are and helps you visualize where you might need some digging. These scores are very helpful for testing your website and can help you to perform iterative optimizations along the way.

What’s more? Suggestions and Improvements

What if the web vitals score for your site isn’t too great the first time around. You don’t have to worry about not knowing where the problem in your site might be. In fact, PageSpeed Insights helps you with a diagnostic section that can perhaps act as a guide or a starting point. As you can see in the picture below, I have drawn out in red boxes to highlight places where PageSpeed Insights wants you to dig in and resolve some of these issues with your site.

These highlights are pretty helpful as you can now deal with solving the specific problem right away than just being baffled and not knowing where things are unsettled. Every diagnosis will also have a “Learn More” section that you can follow to learn how to tackle the specific problem.

Additionally, right at the bottom, you’d also have a “Passed Audits” section listing out where your site is doing great at.

Improve Site Experience and Ranking

You might have a question now that if we really need to care about the web vitals anyway? Let me clear up something. Web Vitals score is just one way or one of the ways Google ranks user sites essentially. Before you even get there and try to optimize your site for SEO, make sure your site has high-quality and relevant content. By relevance or high quality, I just mean a site that users would love to visit.

So in that case, you can’t expect a site to be ranked really high even with high-quality content because it somehow lacks in web vital assessment and vice versa. Definitely, it’s a mix of both that would make your site ranked higher.

There’s a quote from Google that says:

A good page experience doesn’t override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search.

Very simply if there are multiple pages that have quality content the only deciding factor of one page being ranked higher than the other would be the Web Vitals score. So to sum up make sure you work on both quality and relevant content as well as the SEO optimizations for Google to rank your site.

Core Web Vitals Can Remediate Your Website’s Bad User Experience. was originally published in Webtips on Medium, where people are continuing the conversation by highlighting and responding to this story.

Not a very long time ago, CSS style sheets were the only appropriate way to paint any modern app. That is basically the traditional method of styling at the document level — creating a style.css file and referencing it on the HTML document for the styles to appear.

But with constant updates and improvements, we now have with us something known as styled-components. Styled components are basically an innovative way of using Javascript’s ES6 syntax, along with CSS which enables us to enhance our styling in React components. From very old and basic .css files to .scss files and styled-components, there have been some massive upgrades so to speak.

To put out in very simple terms, styled-components allow us to write CSS inside of JavaScript. That’s it! We can still use CSS/SCSS files that would still be compiled back into CSS modules.

Before we run through what styled-components can bring to the table let me clarify why do we even need them.

Well, imagine when an application grows and expands there are certainly a lot more things to consider being a developer. Worrying about dedicating a specific folder to encapsulate all the CSS related files, identifying how to scope them, and making very sure that there are no clashes in namespaces. These are a few of the many problems that styled-components are effectively intercepting right off the bat. Additionally, encapsulating CSS in JavaScript also means no more extensive HTTP requests to fetch all the CSS assets beforehand.

Why Styled Components (Extended)?

Styled components allow us to write CSS inside of JavaScript using tagged template literals (``) and it removes the overhead of mapping components and styles together.

Styled components were created to handle the following reasons:

• Styled components automatically monitor components that are rendered on a webpage and only injects the critically required styles. This means that there is no overhead of extra HTTP requests for fetching the CSS assets.
• Styled components generate unique class names for the styles. Developers now don’t have to worry about namespace clashes.

• Adapting the styling of a component based on its props or a global theme is simple and intuitive without having to manually manage dozens of classes.
• Automatic vendor prefixing: write your CSS to the current standard and let Styled components handle the rest. Styled components use the stylis.js package under the hood for prefixing the CSS rules.

Features of Styled-components

1. Passing Props:

Props in styled-components act the same way as props passed into any React component.

2. Dynamically Changing Elements:

We can dynamically change elements using styled-components as demonstrated below. As you can see in the example below we convert a span element to act as link passing the 'as' prop made available to us.

Now, although CustomText is only a span, it will behave like a link.

3. Leveraging Themes:

Themes allow us to be consistent by making styles available to all our different components. We can now define a common style and apply it to any component we want.

There are tons of handy features that styled-components come with. It also has a few advanced features like concurrent server-side-rendering and passing ref props, just to name a few. Please do check out their official docs by visiting here to know about all its features.

References

• Building a react component library using styled-components.
• Getting most out of styled-components.

Styled Components in React was originally published in Webtips on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we are going to write a reusable custom hook, and build a simple application that will make use of the hook. If you don’t already know hooks were a part of React from v16.8 onwards. They were essentially included as a feature to avoid using classes or class-based components. We can leverage state and other React features the same way we did while using React class-based components. Hooks are just a cleaner way to write programs in React.

What we will have by the end of the tutorial are two components mainly a User component and a Post component. Each of these components will pass an ID using fetch to make a request against the JSON Place holder API. If the user and the post with respective IDs exists, the data will be displayed. And, if they don't exist we'll display some kind of texts notifying that the data wasn't found.

Now one of the hunches that we will encounter while writing the component is that we’ll probably end up writing very similar code. So to avoid writing any repetitive code we write a custom hook component that our User and Post component concurrently leverages for requesting and retrieving data.

Basic Setup

The only setup you will need for this application is having a react app. Run the following command to get started:

npx create-react-app .

Note: Make sure you have npm version > 5.2, to be able to run npx.

If not update your npm using:

npm install -g npm@latest

After you update the npm to the latest stable version, you can now use the npx command to create the react app.

Folder Structure

Everything that we will work on will reside inside the src directory, so we don't need to worry about anything else.

The basic folder structure after creating the react app will look something like this:

src / App.js
---- App.css
---- index.js
---- index.css

You might have more files than this. In case you do, go ahead and delete those files as we will no longer need them for this application.

Note: I have only highlighted the src folder since we will only be working inside this directory.

Now that we have the basic structure ready, we can keep going.

Creating a components directory

Create a /components directory inside of /src, that will hold all of our components.

Now inside the components directory, go ahead and create three different directories. The first one being card that will be the container holding the user and post data. The second directory will be the user directory that contains our user component while the third is the post directory that will contain the post component.

Inside card, user and post directories create the files card.component.jsx, user.component.jsx and post.component.jsx respectively.

Note: The card directory will have a card.css file for styling the card container.

The folder structure will look something like this after creating all the files:

- src/
--- components/
----- card/
------- card.component.jsx
------- card.css
----- user/
------- user.component.jsx
----- post/
------- post.component.jsx

Card Component

The card component essentially holds the User and the Post data.

Styling the card component to make it look decent.

User Component

The User component displays the user data.

We notice there is an import useFetch that we haven't written yet. Don't be surprised, but that will be the custom hook we will be writing a little later.

Post Component

The Post component will display the post data as expected.

We import useFetch here as well. Let us now go ahead and create a separate component for the hook.

useFetch Hook

Inside components directory create another directory called effects and inside effects create a file named use-fetch.effect.js. The same file will hold all the logic of actually making a fetch request to the API and returning the response back to the components.

The useFetch custom hook accepts a ‘URL’ parameter, does the fetching, and returns the data to the components that requested the data. That is all the useFetch custom hook does pretty much. Instead of us fetching data from each of these components we now leverage useFetch as a reusable component. And next time we have another component that requires the same component logic, we already have useFetch that can do the trick for us.

App.js

Now for us to display the data on our browser we need to hook our components inside of App.js and pass the id as props that the components receive.

And after all that is done, we can now see something like this on the screen.

There you go, we have our custom hook up and running. Understandably a custom hook is very much a necessity when we write components that use the same component logic. This process bares us from writing any repetitive code and instead write a reusable custom hook component that can be leveraged by various components at a time.

Write a Custom Reusable Hook (useFetch). was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Multi-factor authentication is an authentication method in which a user is granted access to a website or application only after successfully presenting two or more pieces of evidence to an authentication mechanism: knowledge, possession, and inherence.

In the same way, the two-factor authentication method requires you to enter additional data as evidence to access your account. The most common forms of two-factor authentication involve entering a code as used by Google and Facebook for additional security.

Advantages of Two Factor Authentication

• Added layer security and added protection against cyber attacks.
• Do not incur any extra costs while setting up.
• Easy and convenient setup. For most implementations, all a user has to do is enable two-factor authentication and scan a QR code or enter their cellphone number so they can view or receive authentication codes respectively

NOTE: In this tutorial, we will deal with a backend that implements the time-based one-time password (OTP) made available to us by the Speakeasy library. This tutorial only covers the backend implementation of the two-factor authentication.

Setup

The very first step is to make sure you have appropriate versions of Node and npm installed. If not already you can follow the below links to download the absolute essentials as the very first thing we will be doing is run a Node server.

• Node
• NPM

The next thing we do is create a project directory:

$ mkdir 2-fa
$ cd 2-fa

Now that we have our project folder, we will spin up a package.json using npm init:

$ npm init -y

After you go through a couple of ‘yes’ and customize the setup, you will have a package.json file that might look something like this:

{

   "name": "2-fa",
   "version": "1.0.0",
   "description": "Two factor Authentication using Speakeasy",
   "main": "app.js",
   "scripts": {
      "test": "echo \"Error: no test specified\" && exit 1"
   },
   "keywords": [],
   "author": "Sintu Boro",
   "license": "ISC"
}

Run the following command to install the necessary dependencies:

$ yarn add express body-parser node-json-db uuid speakeasy ||
$ npm install express body-parser node-json-db uuid speakeasy

• Express is a Node.js web application framework that we’ll use to spin our server.
• The middleware body-parser package allows us to parse encoded data from incoming HTTP requests and expose them as req.body, so we can extract the essential data.
• Node-json-db will be used as a database instance for storage.
• Speakeasy is a one-time passcode generator, that we require for the two-factor authentication demonstration.

We now have all the necessary dependencies and are ready to create our server. In the project folder, create an index.js file that will act as an entry point to our project and add the following code to it:

At the root of your project, run the app to make sure everything is working alright:

$ node index.js

And now if we hit the route /api, we receive the following as a JSON response:

Generate Secret Key

We now need to generate a secret key that in turn generates us the two-factor authentication code through the Authenticator extension that we will be using. We will also have a route to register a user containing just the userID and the secret key generated by speakeasy.

To do this we will use Speakeasy’s generateSecret function. The response returns an object that has the secret in ASCII, hex, base32, and otpauth_url formats. We will only be using the base32 string to set up two-factor authentication. Paste the following code to create the register user route:

Right after we add the routes we can now make a POST request to this route to register a user like so:

Now open the Google Authenticator extension/app(this can be installed as an extension) and enter the secret key you just received like so:

Verify the secret

We now have the code generated to us through the secret key by the authenticator app. We now need to verify this code. Notice we have stored the secret as a temporary secret on the storage/database. Only after relevant validation, we can go ahead and store it permanently.

To perform the validation, we need to create another endpoint. The endpoint that verifies the code for us looks something like this:

Now open up the two-factor authentication extension and retrieve the code so we can verify the secret using a Postman request to the verify route.

After the validation, the secret key is now stored permanently and is used to verify future codes.

Verify User Tokens

The final step in the two-factor authentication is verifying the code that the user enters from their authenticator app. We need to add another route that will confirm that the tokens entered by the user are valid. The verification is handled by the Speakeasy TOTP(Time Based One Time Password) verify function.

This receives an object that contains the secret, the encoding to use to verify the token, the token, and a window option. A window refers to the period of time that a token is valid. This is usually 30 seconds but can vary depending on the time selected by the developer of the two-factor process.

You want to be careful to now pass out a large window allowance as that would lead to the verification process becoming less secure. Copy the code below to add the endpoint to validate the tokens.

Now hit the /validate route and verify the code from the authenticator using Postman.

And there you go! We have successfully implemented a two-factor authentication using Speakeasy. We looked into how we can register a user and create a secret shared between your server and the authenticator app; verifying the secret and using it to validate tokens.

The entire index.js file would look something like this:

References

• Two-Factor Authentication using SpeakEasy — Logrocket.
• For a video explanation of the tutorial please visit Traversy Media — Two Factor Authentication on Youtube.

Originally published at https://boro-blogs.netlify.app.

Two-Factor Authentication (2FA) Using Speakeasy and Express. was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.