Forem: Eric O Okiti

Adding Tailwind to Nuxt 3

Eric O Okiti — Fri, 09 Dec 2022 13:50:33 +0000

This week, I was setting up a Nuxt 3 application and I googled how to add tailwind to a Nuxt 3 application, I saw lots of results that almost worked. I guess the writers didn't really test what they wrote or better yet they're not developers, just technical writers (I'm not throwing shades at anyone 🤓). I decided to drop this little post so I could reference in the future and it can also help others as well.

Install Tailwind dependencies

To get started, install the tailwind dependencies

npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

Generate Tailwind config file

npx tailwindcss init -p

The above command generates a tailwind.config.js file in the root of your project.

Configuring Tailwind

Open the tailwind.config.js file in your editor and modify to match the code below.

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./components/**/*.{js,vue,ts}",
    "./layouts/**/*.vue",
    "./pages/**/*.vue",
    "./plugins/**/*.{js,ts}",
    "./nuxt.config.{js,ts}",
    "./app.vue"
  ],  theme: {
    extend: {},
  },
  plugins: [],
}

Add Tailwind to Style

Add the following to a assets/css/styles.css file (Create file if it doesn't exit).

@tailwind base;
@tailwind components;
@tailwind utilities;

Update Nuxt config

Finally we update our Nuxt config to include our css in the build process and also make use of tailwind plugin in postcss (Postcss supercharges our css with JavaScript). Autoprefixer helps us write css without worrying about vendor prefixes.

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  css: [
    '@/assets/css/main.css',
  ],

  postcss: {
    plugins: {
      tailwindcss: {},
      autoprefixer: {},
    },
  },
})

Just like that, I was able to use tailwind with Nuxt 3. Feel free to drop comments or request modification.

Supercharge your NodeJS Express application

Eric O Okiti — Fri, 09 Dec 2022 13:14:46 +0000

Most Node.js developers have crossed paths with express at one point or another. Most modern frameworks even have express working underneath the hood.

The objective of this post is to share some tools, design patterns, and techniques I've used to supercharge my express applications to make them more robust, efficient and maintainable.

Decorators

Decorator is a design pattern that makes it possible to easily wrap our code with extra functionalities. NestJS makes use of decorators a lot, making it super easy to abstract redundant or repeated codes. In practice, decorators can be used to abstract routers, middleware, request validation, and anything else in an express application. What's even more awesome is that you don't need to learn so much to get started using decorators. With @decorators/express you can easily setup and use basic decorators in your express application.

import { Controller, Post, Request, Response } from '@decorators/express';
import { Request as Req, Response as Res } from 'express';

@Controller('/auth')
export class AuthController {
  private readonly services: Services;

  constructor() {
    this.services = Container.get<Services>(Services);
  }

  @Post('/signup')
  async SignUp(@Request() req: Req, @Response() res: Res) {
    const data = await this.services.signUp(req.body);
    res.status(201).json({
      message: 'SignUp successful',
      data,
    });
  }
}

The code snippet above shows an example of how we use @decorators/express to create a signup route without even setting up the router.

Dependency injection

A classical programming principle says that a class should receive its dependencies instead of instantiating them. In its simplest form, we want to avoid writing const classInstance = new Class() whenever we need to use a class. Abstracting object initialisation and destruction minimises the stress of designing and using classes. The module responsible for maintaining class instances is called an IoC container (IoC means Inversion of control).

IoC is only a methodology, not a concrete implementation of DI. Again, you don't have to build your own IoC container to get started with using DI, some frequently used DI frameworks are;

Inversify
TypeDI for TypeScript
@decorators/di
Nest.Js

My personal favourite is @decorators/di. The code snippet below shows how I use DI to manage my auth service class in an Express application;

import { Injectable } from '@decorators/di';
import * as bcrypt from 'bcrypt';
import * as jwt from 'jsonwebtoken';

import { AppError } from '../../Exceptions';
import { Errors } from '../../Exceptions/errors';
import { vars } from '../../utils/vars';
import { authModel } from './schemas/schema';

@Injectable()
export class Services {
  private async genToken(id: string, type: string, exp: string): Promise<string> {
    const token = jwt.sign({ id, type }, vars.jwtSecret, { expiresIn: exp });
    return token;
  }

  async signUp(data: SignUpRequest) {
    const { email, password, firstname, lastname } = data;
    const alreadyExistingUser = await authModel.findOne({ email });
    if (alreadyExistingUser) throw new AppError(Errors.EmailAlreadyExits);

    const hashedPassword = await bcrypt.hash(password, 10);
    let user: any = await new authModel({ email, firstname, lastname, password: hashedPassword }).save();
    user = user.toObject();
    delete user.password;
    const token = await this.genToken(user._id.toString(), 'auth', '100d');
    return { user, token };
  }
}

In my auth controller, I don't have to create an instance of the auth service myself since I used @Injectable() decorator to make my class injectable. In the code below, notice how I get the instance of the auth service from the IoC container;

import { Container } from '@decorators/di';
import { Services as AuthService } from './service';

@Controller('/auth')
export class AuthController {
  private readonly services: AuthService;

  constructor() {
    this.services = Container.get<AuthService>(AuthService);
  }
...

Just like that, we're writing clean codes 😁.

Request validation using decorators

Another classic technique used by Nest.js is the use of decorators in validating request body. When using this methodology, you can use same class based types for type checking and also for validation. I wrote an article on how we could archive this using class validation here. I also wrote an npm package called pipe-validation which means you don't have to implement the entire validation flow yourself.

Validating requests using validation pipes in Typescript

Eric O Okiti — Sun, 13 Nov 2022 10:29:14 +0000

When building APIs, validation of the request body is a must-have. One of the popular tools for validation in Node.js is JOI. I've used Joi for years, and it gets the job done. Recently, I've been exploring other efficient and cleaner ways of archiving this, especially with TS. If you've used Nest JS before, you might have stumbled on validation pipes, enabling you to implement validation using your DTOs and validation decorators. I'll look into how we can archive this in our projects.

Please note that the focus of this post is not folder structure. Instead, it is on how to validate requests. So I'm using a flat folder system in this post. Feel free to structure and nest your files as you please.

We'll start by installing two libraries we will use, class-transformers and class-validator. Class-transformer will transform our class-based dto or types into an object and map them to the request body. Class-validator will make it possible to add validation rules using decorators.

npm i class-validator class-tranformer

An assumption is that you're using express in building your API. Next, we'll create a file called validation.ts

touch validation.ts

Add the following code snippet to the just created file.

import { plainToInstance } from 'class-transformer';
import { validate } from 'class-validator';
export * from 'class-validator';

export const validationPipe = async (schema: new () => {}, requestObject: object) => {
  const transformedClass: any = plainToInstance(schema, requestObject);
  const errors = await validate(transformedClass);
  if (errors.length > 0) {
    return errors;
  }
  return true;
};

From the above snippet, we have a function that takes two parameters, the schema or dto or class-based types and the request object. First, we use plainToInstace to convert and map our dto into an object we can validate. Next, we use the validate function from the class-validator library to validate the request and return the errors, if any.

Simple right? Now we can use this function in our Node.js API server.

...
import { validationPipe, IsString, IsNumber } from './validation';

class bookDto {
  @IsString()
  name: string;
  @IsNumber()
  year: number;
  @IsNumber
  price: number;
}

app.post('/books', async (req, res) => {
  const result = await validationPipe(booksDto, { ...req.body })
  if(result.errors) {
     res.status(400).json({ ...result })
  }
});

This way, we can use our class-based types for validating requests and type checking, making our code cleaner and more maintainable than using a separate schema for validation.

We can take it a step forward and use it as a middleware function.

Using as a middleware

We could use the validation pipe as middleware, meaning cleaner code. To archive this, we'll create a new file named validate.ts or any other name you prefer to use.

touch validate.ts

Add the code snippet below into the file

...
import { validationPipe, IsString, IsNumber } from './validation';

export const validationMiddleware (validationSchema) => async (req, res, next) => {
    const result: any = await validationPipe(validationSchema, { ...req.body, ...req.params }, { pretty: false });
      if (result.errors) {
        console.log(result);
        return res.status(400).json({
          success: false,
          ...result,
        });
      }

      next();
      return true;
};

We can now use our newly created middleware in our app.

import { validationMiddleware } from './validate.ts';
import { validationPipe, IsString, IsNumber } from './validation';

class UserDto {
  id: number;
  @IsString()
  firstName: string;
  @IsString()
  @MaxLength(4)
  lastName: string;

  @IsBoolean()
  @IsOptional()
  verified: boolean;
}
...
app.post('/', validationMiddleware(UserDto), (req, res) => {
  ...
  # Your code goes here.
});

I've combined all the code in this post into an npm package called pipe-validation. Like & comment if love the post or think there's any improvement that can be made.

Don't use underscores in your HTTP headers

Eric O Okiti — Thu, 05 May 2022 06:54:25 +0000

Recently, I've been working on an API server built with Node.js and hosted on AWS Elastic Beanstalk.

The server manages resources for organisations. Apart from the Authorisation token, which tells us who the user is, we added another token which identifies the organisational resources he wants to access. A user can be part of multiple organisations, so we decided to follow this approach.

The header was named ORG_API_KEY. The staging environment was Heroku; everything worked perfectly until deployed to the AWS Elastic Beanstalk production server. We kept getting 401 error (missing api_key).

After hours of debugging, I found out that Elastic Beanstalk running Nginx as a reverse proxy by default has the Nginx option underscores_in_headers turned off (That is the default for Nginx). Somehow Heroku and other servers I've worked with have this option turned on, so I never noticed.

It was now a matter of preference to either turn on this option using our .ebextensions config or modify our headers and change the underscores to dash. Just to be sure, I tried both approaches, which worked.

curl --HEADER "ORG_API_KEY: some-random-token" # won't work
curl --HEADER "ORG-API-KEY: some-random-token" # works fine

To enable this option using Nginx config, you'll have to navigate to the following folder or create one if it does not exit .ebextensions > nginx > conf.d in this folder you should have a configuration file or create one (myconfig.conf or any other name with .conf extension). I already have a config file which I use to increase the size of a request so I added a new line. My config now looks like this;

client_max_body_size 20M;
underscores_in_headers on;

Using underscore is valid according to HTTP standards, in their defence, they (Nginx) said:

This is done in order to prevent ambiguities when mapping headers to CGI variables as both dashes and underscores are mapped to underscores during that process.

The reason is valid, so instead of turning on the option of allowing underscores, we modified the headers changing underscores to dash. I didn't like the bug, but I enjoyed the learning. What other server configurations have you learnt about?

How to validate uploaded files in Node JS

Eric O Okiti — Sat, 26 Mar 2022 12:18:17 +0000

In this note, we'll look at how we can handle file validation and compression in Node JS.
If you have a better way of handling validation or compression, please drop it in the comment section.
In most cases, files are parsed in a Node JS server using either Multer, busboy, or Formidable.
While the content used in this writeup uses Multer, it can easily apply to any system.

File validation
Files in Node JS are usually in JSON format. The format for files is one of the two shown below.

// If memory storage is used
{
  fieldname: 'image',
  originalname: 'image.png',
  encoding: '7bit',
  mimetype: 'image/png',
  buffer: <Buffer bytes>,
  size: 25471
}

// If the file is stored locally
{
  fieldname: 'image',
  originalname: 'Meta1.png',
  encoding: '7bit',
  mimetype: 'image/png',
  destination: 'uploads/',
  filename: 'ed84692635f46d86c4be044f4acca667',
  path: 'uploads/ed84692635f46d86c4be044f4acca667',
  size: 25471
}

The fields we will use for validation are originalname, mimetype, and size fields.

Checking the file extension.

We will use a bitwise right shift operator coupled with some inbuilt JS functions to get the file extension.

const file_extension = image.originalname.slice(
    ((image.originalname.lastIndexOf('.') - 1) >>> 0) + 2
);

The above method has proven to work for 98% of cases, including misspelt filenames, i.e. image.png.png, photo.jpeg.jeg.

Since we now have the file extension, we can check to see if it's valid.

// Array of allowed files
const array_of_allowed_files = ['png', 'jpeg', 'jpg', 'gif'];

// Get the extension of the uploaded file
const file_extension = image.originalname.slice(
    ((image.originalname.lastIndexOf('.') - 1) >>> 0) + 2
);

// Check if the uploaded file is allowed
if (!array_of_allowed_files.includes(file_extension)) {
  throw Error('Invalid file');
}

Checking only the file extension is not practical since anyone can edit a file name and change the extension, i.e. I can easily change a file name from todo-list.docx to todo-list.png.

For this reason, we will also need to check the mimetype of the file to ensure it's an image. We will follow a similar approach in doing this.

const array_of_allowed_file_types = ['image/png', 'image/jpeg', 'image/jpg', 'image/gif'];
if (!array_of_allowed_file_types.includes(image.memetype)) {
  throw Error('Invalid file');
}

combining the two checks, we'll have;

// Array of allowed files
const array_of_allowed_files = ['png', 'jpeg', 'jpg', 'gif'];
const array_of_allowed_file_types = ['image/png', 'image/jpeg', 'image/jpg', 'image/gif'];

// Get the extension of the uploaded file
const file_extension = image.originalname.slice(
    ((image.originalname.lastIndexOf('.') - 1) >>> 0) + 2
);

// Check if the uploaded file is allowed
if (!array_of_allowed_files.includes(file_extension) || !array_of_allowed_file_types.includes(image.memetype)) {
  throw Error('Invalid file');
}

Checking file size

To check the file size, we use the size field. The size is usually given in bytes, so we have to convert it to the desired format for our evaluation. In our case, we converted it to MB.

// Allowed file size in mb
const allowed_file_size = 2;
if ((image.size / (1024 * 1024)) > allowed_file_size) {                  
  throw Error('File too large');
}

Putting the above validations together, a typical middleware in express to validate uploaded files will look like the code below

export const auth = (req, res, next) => {
    const image = req.file;
    // Array of allowed files
    const array_of_allowed_files = ['png', 'jpeg', 'jpg', 'gif'];
    const array_of_allowed_file_types = ['image/png', 'image/jpeg', 'image/jpg', 'image/gif'];
    // Allowed file size in mb
    const allowed_file_size = 2;
    // Get the extension of the uploaded file
    const file_extension = image.originalname.slice(
        ((image.originalname.lastIndexOf('.') - 1) >>> 0) + 2
    );

    // Check if the uploaded file is allowed
    if (!array_of_allowed_files.includes(file_extension) || !array_of_allowed_file_types.includes(image.memetype)) {
        throw Error('Invalid file');
    }

    if ((image.size / (1024 * 1024)) > allowed_file_size) {                  
       throw Error('File too large');
    }
    return next();
}

Conclusion

File validation is very important. Although this writeup made use of images, and a single file upload, it can easily be modified to work for other file types. Adding it inside a loop, it can validate an array of files as well.
The codes has been bundled up into an NPM package that can easily be integrated. follow the link to find it. Fileguard.

Deploying a Node.js application to AWS Elastic Beanstalk using Github actions

Eric O Okiti — Sat, 12 Feb 2022 21:07:31 +0000

In this note, I'm jotting down how to deploy a Node.js application to AWS Elastic beanstalk using Github actions. Part of my assumption is that you have an existing project on Github, and you also have a running EBS environment.
Before we take a deep dive, let's taste the depth using one foot. GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository or deploy merged pull requests to production. An alternative to Github actions can be Circle CI, Travis CI, or Jenkins.

Automating your deployment comes with so many advantages. Part of it has been faster time to market, reduced risks, and better code quality. Now that we're tasted the waters let's take a deep dive.

We first need to create a .github folder at the root of our project directory. after that, let's navigate inside the .github folder and create another folder called workflows. Inside the workflow folder, create a config file with the extension .yml. The file's name can be anything, but in my case, I made it prod.yml.

We can break down the process into several jobs and steps in the config file. We're trying to keep it simple to have a single appointment with several steps.
In the first part of the config file, we'll define the name of the action and the branch that triggers our action.

name: production

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

As seen above, the action is name production; the action is triggered with a push to the main branch, or a pull request is merged to the main branch. You can add multiple branches as well.

Next, we define our job and the environment(OS and node version) on which it will run. We do this using the following code;

jobs:
  ci:
    runs-on: ${{ matrix.os }}

    strategy:
      matrix:
        os: [ubuntu-latest]
        node: [14]
    env:
      NODE_ENV: "development"

After that, the next step involves the actual steps involved in building, uploading, and deploying our application.

    steps:
      - name: Checkout 🛎
        uses: actions/checkout@master

      - name: Setup node env 🏗
        uses: actions/setup-node@v2.1.2
        with:
          node-version: ${{ matrix.node }}

      - name: Cache node_modules 📦
        uses: actions/cache@v2
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Installing NPM
        run: npm install

      - name: Linting check
        run: npm run lint

      - name: Building application
        run: npm run build

      - name: Generate deployment package
        run: zip -r deploy.zip * .[^.]* -x "**node_modules**"

      - name: Get timestamp
        uses: gerred/actions/current-time@master
        id: current-time

      - name: Run string replace
        uses: frabert/replace-string-action@master
        id: format-time
        with:
          pattern: '[:\.]+'
          string: "${{ steps.current-time.outputs.time }}"
          replace-with: '-'
          flags: 'g'

      - name: Beanstalk Deploy for app
        uses: einaregilsson/beanstalk-deploy@v16
        with:
          aws_access_key: ${{secrets.ACCESS_KEY_ID}}
          aws_secret_key: ${{secrets.SECRET_ACCESS_KEY}}
          application_name: <application name>
          environment_name: <Replace with your environment name>
          region: us-east-2
          version_label: "version-label-${{ steps.format-time.outputs.replaced }}"
          deployment_package: deploy.zip

      - name: Deployed!
        run: echo App deployed to ELB

From the above code, some steps to note are:

Step 7: Generate deployment package.
During my trials, I discovered that each project has some individual files required to run. By default, running the zip -r * command zips the files but excludes the hidden files (files and folders starting with a dot .), so feel free to modify the zip command to include the required files.

Step 10: Beanstalk Deploy for app
We're using einaregilsson/beanstalk-deploy@v16 action for beanstalk deployment. At the point of writing, we're using version 16 of the package. Feel free to check for updates and modify the parameters as required. The full code is shown below.

name: production

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  ci:
    runs-on: ${{ matrix.os }}

    strategy:
      matrix:
        os: [ubuntu-latest]
        node: [14]
    env:
      NODE_ENV: "development"


    steps:
      - name: Checkout 🛎
        uses: actions/checkout@master

      - name: Setup node env 🏗
        uses: actions/setup-node@v2.1.2
        with:
          node-version: ${{ matrix.node }}

      - name: Cache node_modules 📦
        uses: actions/cache@v2
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Installing NPM
        run: npm install

      - name: Linting check
        run: npm run lint

      - name: Building application
        run: npm run build

      - name: Generate deployment package
        run: zip -r deploy.zip * .[^.]* -x "**node_modules**"

      - name: Get timestamp
        uses: gerred/actions/current-time@master
        id: current-time

      - name: Run string replace
        uses: frabert/replace-string-action@master
        id: format-time
        with:
          pattern: '[:\.]+'
          string: "${{ steps.current-time.outputs.time }}"
          replace-with: '-'
          flags: 'g'

      - name: Beanstalk Deploy for app
        uses: einaregilsson/beanstalk-deploy@v16
        with:
          aws_access_key: ${{secrets.ACCESS_KEY_ID}}
          aws_secret_key: ${{secrets.SECRET_ACCESS_KEY}}
          application_name: application_name
          environment_name: environment_name
          region: us-east-2
          version_label: "e-learn-${{ steps.format-time.outputs.replaced }}"
          deployment_package: deploy.zip

      - name: Deployed!
        run: echo App deployed to ELB

Also, the AWS secrets are stored using Github secrets. This is found in the settings tab of the repository. Click on settings, then scroll down till you find secrets in the sidebar. In the secrets dropdown, click on actions. Add the access key and the secret key to the secrets.

Change the application_name, environment_name, and the region to your AWS setup.

After that, you can save the file and push it to Github. In the actions tab of the repository, you'll see your CI running.

NOTE. AWS will look for a start script that will run automatically to start your application. You can specify this in a Procfile in the root of your project directory and add the following command web: npm run start.

You might need to tweak one or two in the config. Feel free to share your experience in the comment section.

How to install an SSL certificate on a Bitnami stack hosted on Amazon Lightsail?

Eric O Okiti — Sat, 12 Feb 2022 08:07:27 +0000

In this note, I'll be writing about how to install an SSL certificate on a Bitnami stack hosted on Amazon Lightsail. For the purpose of this tutorial, we'll be using WordPress installation on AWS Lightsail.
After days of figuring out the installation, I finally got a short and quick way of doing it. Let us get started.

Setting up Wordpress on AWS Lightsail

Log in to your AWS console.
In the search box inside the header, search for Lightsail. Click on it to go to the Lightsail console.
Once you're inside the Lightsail console, Click on create instance button.
In the create instance screen, you can choose your preferred instance location. Under the instance image, for the platform, choose Linux/Unix and App+OS (WordPress) for Select a blueprint. Scroll down to select your instance plan and pick a plan that supports your budget.
Under identify your instance, give the instance a unique and descriptive name.
Click on "create instance". You'll wait a while for AWS to perform its magic. Once the instance is created, we can install the SSL certificate.

Linking your domain to your Lightsail instance

After the setup is complete, the next step is to create a static IP address, assign it to your new instance, and link it to a domain. The domain can either be on AWS or on any other domain registry. The following steps will guide you through the process.

In your Lightsail console, click on the networking tab
Click on create static IP.
Choose the instance you want to add the static IP to. Then give it a unique name to identify it.
Click on create and it will generate a new static IP and attach it to your instance.
Add the static IP to your DNS server.

Installing SSL certificate

We'll need to ssh into the instance to add the SSL certificate. We will be using the Lightsail web terminal for this. To begin, click on the terminal icon on the instance card.

If it launches successfully, you'll see a screen like the one below.

If you've reached this point, the next thing we'll do is to run the command sudo /opt/bitnami/bncert-tool.
You'll get a prompt that an update for the tool is available. Enter Y (Yes) to update the tool. It is best to use the most recent version of the tool.

The tool will exit and run the update. After the update has run successfully, run the command sudo /opt/bitnami/bncert-tool again. This time, you will get a prompt to enter the domain names separated by space. you then enter your domain name, i.e. somethingfishy.com www.somethingfishy.com
NOTE: make sure to add only domain names that have been added to your DNS server to avoid an error.

After entering the domain names, hit enter and allow the tool to work. After a few seconds, another prompt will appear to enable redirection from HTTP to HTTPS, enter Y and continue. If you added a www domain to your list in the previous step, you would also get a prompt to redirect www or t non-www domain.

Yet another prompt will appear a few seconds after you hit enter from the previous step. This time it will list about 7 changes it wants to perform on your Binami instance. Enter Y and hit enter.

You'll get another one to accept the LetsEncrypt subscriber's agreement, Enter Y and click on continue.

After this, you should get a success message with the directories where the certs are. click on continue and close the terminal. You can visit your site now.

Extra: to get your Wordpress admin password use the command
`cat $HOME/bitnami_application_password

Please Like, Share, and Subscribe.