In an ideal setting, you would write code for a feature, add that code to the staging area, and then commit it before going to the next part. This helps keep your commit history clean. (Don't worry if you don't have a clean history. Many of us don’t.)

But now, imagine a scenario where you have multiple features to build. You've committed the first. You've started the third, but then you found out you needed to build the second one first, because the third depends on it. It might seem like you have to go back in time and build out that second feature without mixing in the code changes for the third, and without deleting the code changes for the third.

So how do you do that?

In this article, you’re going to learn about Git stash, what it is, and the basic commands you need to be able to use it.

What We’ll Cover:

• What is Git Stash?

• How to Use Git Stash

  • Pushing Commands To The Stash

  • Applying Changes From The Stash To The Working Directory

  • Listing The Items In The Stash List

  • Removing Items From The Stash

  • Creating A New Branch From Stash

  • Showing The Changes In The Stash

• Conclusion

To understand and get the most out of this tutorial, you’ll need to have a basic understanding of Git.

What is Git Stash?

Git stash provides storage (in the form of a stack) where you can store changes to your code. It lets you keep these changes separate from the current working directory until you're ready to apply them.

git stash is a relatively simple command, and has a few variations like:

• git stash push

• git stash pop

• git stash apply

• git stash drop

• git stash clear

• git stash show

• git stash list

How to Use Git Stash

Pushing Code Changes to the Stash

To push uncommitted changes from the working directory to the stash, you can use git stash push. When you do that, the changes disappear from the working directory and are saved in the stash. The working directory is then set back to the last commit (which, in the example below, is the Feature one).

git stash push

You can also write the git stash push command as just git stash – it means the same thing and performs the same way. You can also add a message to it with the -m or --message flag:

git stash push -m "Feature two I was working on"

You can use the -u flag or --include-untracked to include untracked changes in the stash. This way, the changes not yet tracked by Git can be included in the stash.

git stash push -u
git stash push --include-untracked

On the other hand, you can decide to push only staged changes to the stash with the -s or --staged flag:

git stash push -s

You can also suppress feedback messages with the -q or --quiet flag:

git stash push -q

When you're done with your edits on the current working directory, you can commit and push without the older changes bleeding into it. They're safely stowed away in the stash.

Anytime you use the git stash command, you add a stash to the stash list. The stashes are identified by their index numbers.

Applying Changes from the Stash to the Working Directory

Let’s say you had a quick fix to do. You’re done committing that, and you want to continue with what you were working on. You can restore the changes from the stash to continue working on them.

You can do this by using the git stash apply command or the git stash pop command:

git stash apply

git stash apply applies the latest changes from the stash to the working directory, but doesn’t delete the code from the stash. You can select a particular entry to apply by index number:

git stash apply --index stash@{1}
# You'd need to use quotes "stash@{1}" if you're writing this in PowerShell

git stash pop, on the other hand, applies the latest changes from the stash, then deletes them from the stash. Basically, popping from a stack. You can select a particular stash entry to pop by index number.

git stash pop

git stash pop --index stash@{1}
# You'd need to use quotes "stash@{1}" if you're writing this in PowerShell

Listing the Items in the Stash List

You can use git stash list to list out the stashes in the stash list. It’s arranged by index number (like {0}, {1}, and so on). Any time you do a git stash push, it adds a stash to the stash list.

git stash list
stash@{0}: WIP on master: b2a2709 Feature one
stash@{1}: WIP on master: b2a2709 Feature one

Removing Items from the Stash

You can use git stash clear to clear the stash list. But if you just want to drop a particular entry from the stash list, you can use git stash drop and specify the entry you want to drop by the index number. This doesn’t apply its changes to the working directory.

git stash clear

git stash drop stash@{0}
# You'd need to use quotes "stash@{0}" if you're writing this in PowerShell

Creating a New Branch from Stash

You can also create a new branch from a stash using git stash branch. The syntax is git stash branch <branchname> [<stash>].

git stash branch premium-branch stash@{0}
# You'd need to use quotes "stash@{0}" if you're writing this in PowerShell

If you don’t add the stash index, it will just use the last stash.

git stash branch premium-branch

Showing the Changes in the Stash

You can use git stash show to show the changes you’ve made in your stashed changes.

C:\file-path\git_stash_example> git stash show
 text.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Conclusion

Git stash is one of those quiet tools that becomes indispensable once your workflow starts to get messy. It allows you to shelve unfinished ideas, switch context without panic, and keep your commits clean. With it, you can safely carry out urgent fixes, and juggle dependent features without muddling up your commit history.

If you enjoyed this article, share it with others. You can also reach me on LinkedIn or X.

In a previous article, we built a Next.js portfolio blog. Here, you’ll learn how to deploy it on Vercel with GitHub Actions.

Prerequisites

To be able to deploy your project, you should have a GitHub repository of the project (you can still follow along if you already have a Next.js project), and a Vercel account. Here is the GitHub repository that we’ll be working with. You can clone it to follow along.

How to Deploy Your Next App

Create Vercel Token and Add it to Your Secrets in GitHub

In your Vercel account, go to Settings, then go to Tokens.

In the Create Token section, enter a name for your token, select an expiration date and click “create”.

You should see a success message with your token. Next, go to your GitHub repository, and click on the “Settings“ tab.

In the Settings tab, go to Secrets and Variables on the sidebar, then click on Actions.

You’ll see a section for adding secrets. Add a secret named VERCEL_TOKEN, and paste the token there.

The Vercel token is a token used to authenticate the GitHub runner. The Vercel CLI installed on the GitHub runner is going to execute the commands with your account. So, instead of it having to login, it uses the access token to verify that it was actually authorized by you to take the actions.

The Organization ID is used to tell Vercel which organization or team account the project should be created under.

The Project ID then tells Vercel the specific project you want to deploy. Just like the Organization ID, it is a unique identifier.

Install the Vercel CLI and Login

Use the command below to install vercel CLI globally on your computer:

npm install -g vercel

Then log into the CLI with the following command:

vercel login

Use one of the options to login.

I used GitHub. Select one with your arrow keys, and click enter.

Create a Vercel Project from Your Local Directory

Navigate to your project directory if you’re not already in it. If you have already created a project on Vercel through the web interfce, use the vercel link command to link your current directory to the Vercel project. If you don’t already have a Vercel project, just type vercel in the CLI and follow the prompts to setup the project.

With that, Vercel will create a .vercel folder in the project. Open it, and go to the project.json file.

In the file, you should see your project ID and organization ID. Copy them and create secrets in your GitHub repository for each one.

Create your GitHub Workflow File

At the root of your project folder, create the .github/workflow folder. Then create a workflow file called vercel_deploy.yml.

In the file, write this:

name: Vercel Production Deployment
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    branches:
      - main
    paths:
      - '01-simple-blog/**'  

jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: 01-simple-blog
    steps:
      - uses: actions/checkout@v2

      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
        continue-on-error: true

      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

This is the workflow file for my simple-writer-portfolio project.

First, we have the environment variables:

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
# Other code

Then we have the trigger. This triggers when I push to the main branch, affecting files in the 01-simple-blog subdirectory.

# Previous code
on:
  push:
    branches:
      - main
    paths:
      - '01-simple-blog/**'  
# Other code

Then we have the job definition. Here, I defined a job “Deploy-Production” that runs on Ubuntu. By default, all commands there will run in the 01-simple-blog directory, which is equivalent to running cd 01-simple-blog from the root before running commands on the shell. I did this because the Next.js project is in that directory, where the package.json is located.

# Previous code
jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: 01-simple-blog
# Other code

Then the steps involved:

# Previous code
 steps:
      - uses: actions/checkout@v2

      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
        continue-on-error: true

      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

With these steps, Vercel is first installed on the GitHub runner. Then the vercel environment information is pulled. The project is built with vercel build, and the pre-built artifacts are then pushed to Vercel.

Push to GitHub and watch your code deploy

Stage your changes, if any:

git add .

Commit the changes:

git commit -m "Added GitHub Actions workflow"

And push:

git push origin

Now, go to your repository online, and check the deployment.

Conclusion

With your basic GitHub workflow in place, you can now make changes to your code, push to GitHub, and have it deploy automatically. Though Vercel allows you to connect your repository directly, this method provides you with more flexibility and customizability. If you enjoyed this article, share it with others. You can also reach me on LinkedIn or X.

A blog sounded like a good solution for this, so I set out to build one. In this article, I will walk you through how I did it with Next.js.

The basic idea here was to build a website where I wouldn’t need to write code in the future. I just wanted to be able to add the URL of a new article to a JSON file, and the website would extract information like the title, date, cover image, and description and then update itself with it. No database.

To understand how I would go about it, I checked the metadata of the HTML text from each of the platforms I considered. I used my articles, of course, like the one in the project folder. I found out that most of them used Open Graph metadata. So, that was easy to scrape. But, I also found out that some information wasn’t in the meta tags – instead, it was in the JSON-LD. At the end of the day, I ended up using both in my functions.

What we’ll cover:

1. How the Blog Site Works

2. The Structure of an Article on the Blog

3. How the Search Feature Works

4. The Project Structure

5. Steps to Build the Blog

6. Conclusion

Pre-requisites

Understanding this article requires some knowledge of programming and web development. You need to have basic knowledge of HTTP, HTML, CSS, JavaScript, and React to be able to follow along easily.

If you don't have those skills, you may still be able to understand the general structure and working principles.

How the Blog Site Works

The project consists of client components and server components. It is a website, so ideally, it's just a front-end. But it has to fetch data from URLs – and doing that from the client-side won’t work due to CORS blocking, as the requests will be emanating from a browser. So, it has to run on the server.

The fetchArticles() function runs on the server – then this happens:

The fetchArticles() function accesses the URLs, extracts and processes the HTML and JSON Linked Data objects from the response, and returns an array of Article objects to the Home page.

The HomePage component is a client side component that has another component in it, named HomeClient. This HomeClient is a client side component. It has to be because it has useState hooks.

But the HomePage component calls the fetchArticles() function and sets the articles constant (which is an array of Article objects, as defined by the interface in the ArticleCard.tsx file). The articles constant is then passed down to the HomeClient component as a prop.

Inside the HomeClient component, there are two components – the Hero component, and the MainBody component. The Hero component shows the welcome message, and also has the search bar. The MainBody component is where the tags and the article grid are. Logic for filtering articles are also in the MainBody component.

Inside the MainBody component, there is the ArticleCard component that takes the filtered array of Article objects from the MainBody as props, and renders an article card for each. These cards are rendered inside the grid in the MainBody component.

What does an article look like?

The articles are defined by an interface:

export interface Article {
  id: number;
  title?: string;
  description?: string;
  publishedDate?: string;
  url: string;
  imgUrl?: string;
  siteName?: string;
  tags?: string[];
}

The interface, as shown above, specifies that the object will have eight properties, of which only the id and url are compulsory. Those compulsory properties are actually what’s needed in the JSON file from which the web server will read.

When the URL is visited by the server, the title, description, and other properties (except the tags) are obtained automatically and populated. Then the object is created.

The article cards consist of the article’s cover image, the name of the platform where it was published, the date published, the title, and a description. All of this is wrapped in an anchor linking to the URL. The tags are not visible on the cards, but are used in filtering operations.

How does the search feature work?

There's a reason why the Hero component and the MainBody component are in the same parent component. That wasn't my initial design, but after I saw that the search bar would look better in the Hero component, and that I needed to set the searchTerm state in the Hero component and use it in the MainBody component, that became the best option for me: to put both of them in the same parent, so I could pass down the useState hook as props into both of them.

The search feature works basically by filtering the articles array based on the tags selected, or the search term entered. Here is what the code looks like:

 useEffect(() => {
    const anyTagActive = isActive.some((val) => val);

    const filtered = articles.filter((article) => {
      console.log('Search term: ' + searchTerm || 'searchTerm');
      const searchMatch =
        article.title?.toLowerCase().includes(searchTerm.toLowerCase()) ||
        article.description?.toLowerCase().includes(searchTerm.toLowerCase()) ||
        article.tags?.some((tag) => tag.toLowerCase().includes(searchTerm.toLowerCase())) ||
        article.siteName?.toLowerCase().includes(searchTerm.toLowerCase()) ||
        article.publishedDate?.toLowerCase().includes(searchTerm.toLowerCase());


        console.log('This is the searchMarch: ' + searchMatch || 'FALSE searchMatch');
        console.log(article.title || 'article.title no wan show');

      const tagMatch = article.tags?.some((tag) => {
        const index = tags.indexOf(tag);
        return index !== -1 && isActive[index];
      }) || false;

      if (anyTagActive) {
        return tagMatch && searchMatch; // Only return articles if tag is active and search matches
      }

      return searchMatch; // If no tags active, return all that match the search term
    });

    setFilteredArticles(filtered);
  }, [articles, searchTerm, isActive]);

Here, we use a useEffect() hook to monitor for changes in the articles, searchTerm, and isActive constants. isActive is a useState() hook that has an array of boolean values the length of the tags array.

const [isActive, setIsActive] = useState(tags.map(() => false));

Here, the filtered constant is equal to the filtered values of articles.

const filtered = articles.filter();

Inside the filter method is where the arrow function with the logic for filtering is written – (article) => {//logic}. We have two constants: tagMatch and searchMatch. The searchMatch constant is true when the title, description, tags, site name, or published date includes the search term. Else, it's false. The tagMatch constant is true when any tag from the article's array of tag is present in the tag list, and also has a corresponding isActive value of true.

If any tag at all is active, then the results for both tagMatch and searchMatch are returned, but if no tag at all is active, then only the searchMatch is returned as true.

The filtered article list is what is then passed into the ArticleCard component.

<ArticleCard articles={filteredArticles} />

Project Structure

This is what the project file structure looks like:

At the root, we have the config files and node_modules which is not displayed here. The public folder holds all the images and icons. Then, in the src folder, we have app, component, and utils.

The components folder holds the files for the components – the nav bar, footer, hero, main body and article card. The utils folder has all the functions that run in the background and do not need to render anything. The fetchArticles function is there, along with other functions for extracting the date published, title, description, image URL, and others from HTTP responses gotten from the article URLs. The app folder has the favicon, the global CSS stylesheet, the page and layout files, articles.json which is the JSON file where I add new article URLs for rendering, a test HTML file (wsl.html), and the about/ and api/ directories.

Inside the about folder, we have the about page, and inside the API folder, we have tthe folder, metadata-local-test which is no longer relevant to the project. I used it initially to create an internal API to fetch from the URLs. But I later restructured the codebase.

Steps to Build the Blog

1. Install Next.js

To install Next.js, navigate to the folder where you want the project to reside and open that location in your terminal. Then type the following:

npx create-next-app@latest

You're going to be met with the following prompts:

2. Navigate to your newly created project folder and install dependencies

In the newly created project folder, run the project in development mode to preview your newly created Next project. You will be shown a message directing you to localhost on port 3000. Now, it's time for us to start creating what we want.

Now, one more thing you'll need to do. In the project, I used lucide-react to get one of the icons, and cheerio to extract data from the HTML. So, you’ll need to install those dependencies.

To install lucide-react, use this command in the project folder:

npm install lucide-react

Then install cheerio:

npm install cheerio

3. Change the title and description in the page metadata

The title is what shows up at the top of your browser tab when you open up the website. Right now, it should be showing 'Create Next App.' We don't want that.

Since this is not just HTML, there is no index.html to change the title in the header element. Rather, Next.js provides us a Metadata object we can use to change things like that. And it'll be in the layout.tsx file in the app or src folder. Head over there and change it to whatever you want the title to be. I’m using “Chidiadi Portfolio Blog”.

4. Create the necessary components

Navigate to the side panel, and under the src folder, create a components folder. This is where the components will live. Here, create the article card, footer, main body and nav bar.

For the Navbar, this is the code:

export default function Navbar(){
    return(
        <>
        <div className="text-3xl md:text-base flex w-[100vw] md:w-[98.2vw] lg:w-[98.8vw] h-[60px] bg-black text-white px-0 md:px-7 md:py-2 items-center justify-center md:justify-between">
            <h1 className="font-bold">CHIDIADI   ANYANWU</h1>
            <div className="hidden md:block flex space-x-4">
                <a href="/" className="hover:text-gray-400">Blog</a>
                <a href="/about" className="hover:text-gray-400">About</a>    
            </div>
        </div>
        </>
    );
}

Here's what the Hero component looks like:

"use client";

import { Search } from 'lucide-react';
import { useState } from 'react';

interface HeroProps {
    searchTerm: string;
    setSearchTerm: React.Dispatch<React.SetStateAction<string>>;
  }
export default function Hero({ searchTerm, setSearchTerm }: HeroProps) {
    const [buttonColor, setButtonColor] = useState('');

    return (
        <div className="bg-[url('/img-one-1.jpg')] bg-cover bg-center bg-no-repeat flex flex-col items-center justify-center h-[400px] relative">
           <div className=" absolute inset-0 bg-black opacity-60"></div> 
            <h1 className="text-4xl text-white font-bold text-center z-10">My Portfolio Blog</h1>
            <p className="mt-4 mx-4 text-xlarge text-white md:text-xl text-justify md:text-center z-10" style={{ fontFamily: "Cormorant Garamond" }}>
                My name is Chidiadi Anyanwu. I am a technical writer with a strong background in networking. 
                I write about Networking, Cloud, DevOps, and even sometimes web development like this one. I built this
                website with Next.js, and there's also an <a href="/" className="text-blue-500 hover:text-blue-700 hover:underline">article about that.</a>
                  This website holds my technical articles in one place. It is a repository of my written works.
            </p>
            <div id="searchbar" className="h-9xl mt-4 flex align-items-center justify-center w-full" >

                <form onSubmit={(e) => {e.preventDefault();  setSearchTerm(searchTerm);}} className="group mt-4 relative w-[70%] md:w-[50%]">
                    <input  value={searchTerm} onChange={(e) => setSearchTerm(e.target.value) } onFocus={()=>{setButtonColor('bg-blue-500'); console.log('input focused')}} onBlur={()=>{setButtonColor('');}}type="search" placeholder="Search Chidiadi's articles" className="h-[50px] w-full px-[48px] border-3 border-blue-300 rounded-[25px] focus:outline-none focus:border-blue-500 text-black bg-white"/>
                    <button className={`h-[42px] w-[42px] absolute right-0 mr-1.5 mt-1 rounded-[50%] bg-blue-300 ${buttonColor}`}>
                        <Search  className='m-auto text-white'/>
                    </button>
                </form>

            </div>
        </div>
    );
}

In this file, we created the HeroProps interface to accept the search props. Then we deconstructed both searchTerm and setSearchTerm from it as props to the Hero component. We’ll make it a client component 'use client' because of the buttonColor useState() hook that changes when the search bar is clicked and sets the search button background color.

The MainBody component looks like this:

"use client";

import { useEffect, useState } from 'react';
import ArticleCard, { Article } from './ArticleCard';

interface MainBodyProps {
  searchTerm: string;
  articles: Article[];
}

export default function MainBody({ searchTerm, articles }: MainBodyProps) {
  // Get articles from JSON file and create array of article objects

  const [filteredArticles, setFilteredArticles] = useState<Article[]>([]);

  const tags = ["Networking", "Cloud", "DevOps", "Web Dev", "Cybersecurity"];
  const [isActive, setIsActive] = useState(tags.map(() => false));


  // Filter articles based on search term and active tags
  useEffect(() => {
    const anyTagActive = isActive.some((val) => val);

    const filtered = articles.filter((article) => {
      console.log('Search term: ' + searchTerm || 'searchTerm');
      const searchMatch =
        article.title?.toLowerCase().includes(searchTerm.toLowerCase()) ||
        article.description?.toLowerCase().includes(searchTerm.toLowerCase()) ||
        article.tags?.some((tag) => tag.toLowerCase().includes(searchTerm.toLowerCase())) ||
        article.siteName?.toLowerCase().includes(searchTerm.toLowerCase()) ||
        article.publishedDate?.toLowerCase().includes(searchTerm.toLowerCase());


        console.log('This is the searchMarch: ' + searchMatch || 'FALSE searchMatch');
        console.log(article.title || 'article.title no wan show');

      const tagMatch = article.tags?.some((tag) => {
        const index = tags.indexOf(tag);
        return index !== -1 && isActive[index];
      }) || false;

      if (anyTagActive) {
        return tagMatch && searchMatch; // Only return articles if tag is active and search matches
      }

      return searchMatch; // If no tags active, return all that match the search term
    });

    setFilteredArticles(filtered);
  }, [articles, searchTerm, isActive]); 

  console.log(filteredArticles);

  return (
    <div className='scroll-smooth'>
      <div id="tags" className="flex w-full h-[200px] md:h-[60px] justify-center gap-5 py-4 flex-wrap max-w-[100vw] scroll-smooth">
        {tags.map((tag, index) => (
          <p
            key={index}
            onClick={() => {
              const newIsActive = [...isActive];
              newIsActive[index] = !newIsActive[index];
              setIsActive(newIsActive);
            }}
            className={`h-[48px] w-[140px] border-3 rounded-[40px] px-2 py-2 text-center font-bold ${
              isActive[index]
                ? 'bg-black border-black text-white hover:bg-gray-700 hover:border-gray-700'
                : 'border-blue-500 hover:bg-blue-500 hover:text-white'
            }`}>
            {tag}
          </p>
        ))}
      </div>

      <div id="articlegrid" className="w-[100vw] md:w-[98vw] grid gap-2 grid-cols-1 md:grid-cols-2 xl:grid-cols-3 mt-5 px-3 py-3">
        <ArticleCard articles={filteredArticles} />
      </div>
    </div>
  );
}

Here, we have props from the parent component too, but we only need the articles fetched and the search term. We don't need to set the fetch term from this component.

To render the tags, I first created the array of tags and an array of boolean values to record the states of the tags (whether they're active or inactive).

const tags = ["Networking", "Cloud", "DevOps", "Web Dev", "Cybersecurity"];
const [isActive, setIsActive] = useState(tags.map(() => false));

Then, inside the return statement, I mapped through the tag array to render them one by one. The onClick event handler also works here to make sure that the isActive state for that particular tag is toggled when it is clicked.

So how does this work? It creates a new array called newIsActive that is a copy of the isActive array. It then gets the particular tag by index number and inverts it. Then it sets the isActive array to this new array.

{tags.map((tag, index) => (
          <p
            key={index}
            onClick={() => {
              const newIsActive = [...isActive];
              newIsActive[index] = !newIsActive[index];
              setIsActive(newIsActive);
            }} . . .

This is the code for the ArticleCard:

import React, { useState } from 'react';
import Image  from 'next/image';

export interface Article {
  id: number;
  title?: string;
  description?: string;
  publishedDate?: string;
  url: string;
  imgUrl?: string;
  siteName?: string;
  tags?: string[];
}

interface ArticleProps {
  articles: Article[];
}

const ArticleCard = ({ articles }: ArticleProps) => {

  return (
    <>
    {articles ?

      (articles.map((item, id) => (
        //anchor tag for the link
        <a key={id}  href={item.url} className='max-w-[350px] mx-auto mb-5'>
            <div className="sm:w-[350px] hover:brightness-70" data-title={item.title} data-description={item.description} data-published-date={item.publishedDate} data-tag="Networking" data-site-name={item.siteName}>
            <Image
              src={item.imgUrl || '/img-2.jpg'} 
              alt={item.title || 'Article Image'}
              width={350}
              height={400}
              className="object-cover rounded-[10px]"
            />
            <div className="flex h-[43px] text-[14px] text-gray-500 gap-2">
                <p id="Platform" className="py-2 h-[42px] md:text-sm mt-auto mb-auto">{item.siteName}</p>
                <div className="h-1 w-1 bg-black rounded-full mt-auto mb-auto bg-gray-500"></div>
                <p id="publishedDate" className="py-2 h-[42px] mt-auto mb-auto">{item.publishedDate}</p>
            </div>
            <h1 id="titleOfArticle" className="font-bold text-base md:text-3xl">{item.title}</h1>
            <br/>
            <p className='w-full md:w-[350px]'>{item.description}</p>
            </div>
        </a>
      )))
      :

      ( Array(6).fill(0).map((item, id) => (
        <div key={id} className="w-full md:w-[350px] h-[350px] bg-gray-500 mx-auto mb-5 hover:brightness-80 rounded-[10px] animate-pulse"></div>
      )))
    }
    </>
  );
};

export default ArticleCard;

Here, we defined and exported the Article interface so that we can create Article objects in the MainBody. Then, we created an interface to pass down the props of an array of Article objects.

Next, there's this part to ensure it renders something even if for some reason no Article object was passed:

{
    article?
    ( {/*If article exists, render this*/} )
    :
    ( {/*Else, render this */} )
}

Our fail-safe here is an empty array of six objects with the Tailwind animate-pulse:

 ( Array(6).fill(0).map((item, id) => (
        <div key={id} className="w-full md:w-[350px] h-[350px] bg-gray-500 mx-auto mb-5 hover:brightness-80 rounded-[10px] animate-pulse"></div>
      )))

I could have made this part much better, but I was feeling a little lazy. I also used the Image from Next, instead of the regular img. This requires that you edit the next.config.ts file. I had to go add all the paths that the images could possibly be loaded from:

Just like in the screenshot above, the syntax is:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  images: {
    remotePatterns: [
        {
            protocol:"https",
            hostname:"licdn.com",
            pathname:"/**"
        },
        {
            protocol:"",
            hostname:"",
            pathname:""
        }
        ],
    },
};
export default nextConfig;

It takes a remotePatterns array that consists of remote pattern objects, which have a protocol, hostname, and pathname property. Make sure the protocol and hostname properties are not empty like in the second object in the code sample above. That would cause errors. It’s either the objects are populated properly or they’re deleted.

The Footer looks like this:

export default function Footer() {

    return (
        <footer className="bg-gray-100 text-center py-4 mt-10">
            <div className="flex align-items-center justify-center text-sm text-blue-400 font-bold">
                <a href="/" className="hover:text-blue-600">Home</a>
                <p> &nbsp; &nbsp; | &nbsp; &nbsp; </p>
                <a href="/about" className="hover:text-blue-600">About</a>
            </div>
            <p className="text-sm text-gray-600">© {new Date().getFullYear()} Chidiadi Anyanwu. All rights reserved.</p>
            <p className="text-sm text-gray-600">Built with Next.js and Tailwind CSS</p>
        </footer>
    );

}

This new Date().getFullYear() helps me get the current year all the time.

5. Place the components properly

The nav bar and footer components are things that will not change no matter the page you visit. So they should be placed in a more permanent and untouched location. We can put both of them in the root layout.tsx file like this:

 <body className={`${geistSans.variable} ${geistMono.variable} antialiased scroll-smooth`}>
      <Navbar />
      {children}
      <Footer />
  </body>

{children} is where the contents from page.tsx will enter. So, we sandwiched all the other content in the Nav bar and footer. Apart from adding <link /> tags for fonts (because this is where the root HTML is), we really don't have business with this file again.

Now, in the same app/ folder where this layout file is, create the <HomeClient /> file. This is how it looks:

'use client';

import { useState } from 'react';
import Hero from '../components/hero';
import MainBody from '../components/mainbody';
import { Article } from '../components/ArticleCard';

interface Props {
  initialArticles: Article[];
}

export default function HomeClient({ initialArticles }: Props) {
  const [searchTerm, setSearchTerm] = useState<string>('');
  const [articles, setArticles] = useState<Article[]>(initialArticles);

  return (
    <div>
      <Hero searchTerm={searchTerm} setSearchTerm={setSearchTerm} />
      <MainBody searchTerm={searchTerm} articles={articles} />
    </div>
  );
}

Then, put the HomeClient component inside the page.tsx file:

import { fetchArticles } from '../utils/fetchArticles';
import HomeClient from './HomeClient';

export const revalidate = 3600;

export default async function HomePage() {
  const articles = await fetchArticles(); 

  return <HomeClient initialArticles={articles} />;
}

The server is set to fetch the articles at build time, and fetch again (revalidate) every hour (3600s). So, it doesn't fetch the articles from the URLs upon user request of the page.

Initially, it worked by fetching any time the component was mounted, but I noticed that this caused the page to load very slowly. The articles didn't pop-up on time, because there's a lot of fetching to be done.

In that same app/ directory, create an about/ folder, and create the page.tsx for that route:

import Image from "next/image";
export default function About() {
    return (
        <>
            <div className="flex items-center justify-center">
                <div className="margin-auto w-[90vw] md:w-[60vw] lg:w-[50vw] h-[450px] hover:bg-gray-100 border-1 md:border-2 border-gray-200 shadow-sm flex flex-wrap  items-center justify-center gap-2 mt-10 mb-10 rounded-lg">
                    <Image
                        src="/MyPhotoChidiadi.jpg" 
                        alt="Avatar"
                        className="rounded-[50%] h-30 w-30"
                        width={120} 
                        height={120} 
                    />
                    <div className="w-[90%] mx-auto">
                        <h1 className="text-xl text-center my-1 font-bold">About Me</h1>
                        <p className="text-justify my-3">
                            My name is Chidiadi Anyanwu. I love breaking down complex concepts.
                            I write about Networking, Cloud, DevOps, and even sometimes web development. 
                            You can connect with me by following any of the links below.
                        </p>
                        <hr className="border-gray-300 my-3" />
                        <div className="flex gap-7 w-full my-3 justify-center"> 
                            <a href="https://github.com/chidiadi01">
                                <Image src='/github-icon.svg' alt="github logo" width={24} height={24} />
                            </a>
                            <a href="https://linkedin.com/in/chidiadi-anyanwu">
                                <Image src='linkedin-icon.svg' alt="linkedin logo" width={24} height={24}/>
                            </a>
                            <a href="https://x.com/chidiadi01">
                                <Image src='x-2.svg' alt="x logo" width={24} height={24}/> 
                            </a>
                        </div>
                    </div>
                </div>
            </div>
        </>
    );
}

6. Create the utils folder and all the functions

The next step is to create all these files.

Under the same app/ directory, create the utils/ folder. app/utils/. Then start with the fetchArticles() function. The fetchArticles() function is what accesses the API route in the project to obtain the array of Article objects from an array of URLs. The fetchArticles() function returns an array of those objects which are then stored in the articles variable. It looks like this:

import { getPublishedDate } from './getPublishedDate';
import { getTitle } from './getTitle';
import { getImageURL } from './getImageURL';
import { getDescription } from './getDescription';
import { getPlatform } from './getPlatform';
import articleFile from '../app/articles.json';
import { Article } from '../components/ArticleCard';
import * as cheerio from 'cheerio';

export async function fetchArticles(): Promise<Article[]> {
  console.log('Fetching articles...');
  const results = await Promise.all(
    articleFile.articles.map(async (item) => {
      //Validate URL first
       if (!item.url || typeof item.url !== 'string' || item.url.trim() === '') {
        console.warn(`Invalid URL: ${item.url}`);
        return null; // Skip this item
      } 
      console.log('The URL: ' + item.url);
      let data;
      try {

        // Fetch metadata and HTML from the URL
        const response = await fetch(item.url, {
          headers: {
            'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36',
            'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
            'Accept-Language': 'en-US,en;q=0.5',
            'Referer': 'https://www.google.com/', 
          },
        });

        console.log('Fetched: '+ item.url);

        if (!response.ok) {
          console.error(`HTTP error! Status: ${response.status} for URL: ${item.url}`);
          throw new Error(`HTTP error! Status: ${response.status}`);
        }

        const html = await response.text();
        const $ = cheerio.load(html);
        const jsonScript = $('script[type="application/ld+json"]').html();

        console.log('Gotten HTML response');

        if (!jsonScript) {
          throw new Error('No JSON-LD script found on page');
        }

        const metadata = JSON.parse(jsonScript);
        console.log('Gotten metadata');


        // Combine metadata and HTML into a single object
        data = { metadata, html };
      } catch (error) {
        console.error(`Failed to fetch metadata for URL: ${item.url}`, error);
        return null;
        console.log('The default empty object has been returned here');
      }

      // Use the combined data (metadata and HTML) to construct the article object
      if(getTitle(data) && getDescription(data) &&
         getPublishedDate(data) && getImageURL(data) &&
         getPlatform(data) || (item.title && item.description &&
         item.image)) {
        return {
        ...item,
        id: item.id ?? 0,
        tags: item.tags ?? [],
        title: getTitle(data) || item.title || 'No title',
        description: item.description || getDescription(data) || 'No description',
        publishedDate: getPublishedDate(data) ?? 'No date',
        imgUrl: getImageURL(data) || item.image || '/img-2.jpg',
        siteName: getPlatform(data) || data.metadata?.publisher?.name || 'Unknown site',
        url: item.url || '',
      } as Article;
      console.log('Proper item returned');
      } else { return null; }
    })
  );

  // Filter out null values and sort the articles by published date in descending order
  const filteredResults = results.filter((article): article is Article => article !== null);
  const sortedResults = filteredResults.sort((a, b) => {
    const dateA = new Date(a.publishedDate || '').getTime();
    const dateB = new Date(b.publishedDate || '').getTime();
    return dateB - dateA;
  });
  console.log(sortedResults);
  return sortedResults;
}

It maps through the articles in the articleFile, which is the JSON file with an array of objects with article URLs. For each of them, it sends a request to the URL, and from the data gotten, returns an Article object. Then, the array of objects created, results, is first filtered to remove null objects, and sorted in descending order by their date properties. So, the latest article shows up first.

It’s then assigned in the HomeClient component:

 const articles = await fetchArticles();

In the fetchArticles() code above, you can see that some other functions were used to extract the properties from the URLs, and assign them. Also, during deployment, I found that Substack couldn’t be accessed by the server, so I’m going to add code to allow creation of Article objects from an RSS feed. That will be in the project repository.

Now, let's talk about the other functions.

The getTitle() function:

import * as cheerio from 'cheerio';

export function getTitle(data:any): string {
    if(!data) return 'Title Loading . . .';

    if (data?.html) {
        const $ = cheerio.load(data?.html);
        const ogTitle = $('meta[property="og:title"]').attr('content') || $('title').text();
        return ogTitle;
    }

        return 'The Title of The Article';
    }

This is a very simple function. It takes the data parameter, and if there's no data, it returns Title loading . . .. But if there is data, it checks to see if there's HTML in the data. If there is, it then uses cheerio to load the HTML text and extract the title from the Open Graph title metadata or from the <title> tag in the HTML header. Else, it returns The Title of the Article.

Here, we use jQuery-like syntax $ to select the HTML elements, like in $('title'). The data taken as a parameter is the response gotten from a HTTP request to the article's URL.

The getDescription() function:

import * as cheerio from 'cheerio';

export function getDescription(data: any): string {
  if (!data) return 'Description Loading . . .';

  if (data?.metadata || data?.html) {
    const $ = cheerio.load(data?.html || '');
    const description = data?.metadata?.description ?? $('meta[property="og:description"]').attr('content') ?? 'No description found';
    return description;
  }

  return 'No description found';
}

The getURL() function:

import * as cheerio from 'cheerio';

export function getURL(data: any): string{
    if(!data) return 'url';

    if(data?.metadata || data?.html){
        const $ = cheerio.load(data?.html);
        const url = data?.metadata.url || $('meta[property="og:url"]').attr('content');
        return url;
    }
    return 'url';
}

This function is not really used to get the URL of the article for use in the object. Rather, it is used to get the URL for another function, getPlatform(). It works the same way as the ones we discussed before.

The getPlatform() function:

import { getURL } from './getURL';

export function getPlatform(data: any): string {
    if (!data) return 'Platform1';

    const url = getURL(data);

    if (data?.html) {
      const regex = /^(?:https?:\/\/)?(?:www\.)?([^\/\n]+)\.(?:[a-zA-Z]{2,})/;
      const platform = url.match(regex);
      return platform?.[1].toUpperCase() || 'Platform2'; 
    }

    return 'Platform3';
  }

This function is meant to extract the name of the platform where the article is posted. I toyed with various ideas for how this should work. One of them was using the siteName property in the OG meta tags, but I realised from my inspection that not all platforms had it populated in a helpful way. So, the results gotten from that method would be too unpredictable.

So I decided to use regex (Regular Expressions) to extract the site name from the URL. As you can see from the code, I didn't achieve a perfect result, but it is usable.

First of all, it gets the URL of the article with the getURL() function. Then, it uses regex:

/^(?:https?:\/\/)?(?:www\.)?([^\/\n]+)\.(?:[a-zA-Z]{2,})/

Here, / and / at the beginning and end are to start and end the regex string. The caret ^ marks the beginning of a line.

Then, we have four groups ()()()(). The first one is a non-captured group (?: ). That means whatever text that matches that should be grouped together in a string, but should not be captured to be assigned to the variable. It captures any text with a 'http' in it, with or without the s s?, and with two slashes after. The forward slashes were escaped with backward slashes so they can be recognised as literal characters. Then, the whole group itself is made optional by adding the question mark after it (...)?. So, whether such a group is matched or not, the code works.

The second group is also a non-capturing group, also denoted by ?: being the first thing inside the bracket. This one matches any 'www.' in the string. It's also optional. A URL may not necessarily be written with it.

The third group is a capturing group as it doesn't have ?: inside the brackets. Rather, it has a character class in it []. But it's a negated class [^ ]. It makes sure that the class does not contain a newline character n (the newline character n is not a string of letter n – that's why it is escaped) or a forward slash /, because a URL is supposed to be one line, and not multiple lines. The + means one or more characters, ([^\/\n]+). Whatever is in this group will get captured in the variable.

Then, the next one matches a dot (it is escaped with a backslash \.). After that is the last group which is also non-capturing and matches any character which is alphanumeric, capital or small letter [a-zA-Z], that occurs more than two times {2, }.

So, if we have 'https://www.linkedin,com' we would have an array of captured groups ['https://www.linkedin.com','https://','www.','linkedin','com']. Group 1 = 'https://', group 2 = 'www.', group 3 ='linkedin', group 4 = 'com'. But since only group 3 is a captured group, others will be discarded, and we have an array with only two items, the full string, and the captured group: ['https://www.linkedin.com','linkedin'].

So, here, we return the second item in the array. The first item is always the full string we matched.

return platform?.[1].toUpperCase()

This doesn't account for sub domains, though. This is tricky because sometimes you want to use the name of the subdomain (as in my Substack), and sometimes you want to use the name of the domain. So, I left it like that.

The getImageURL() function:

import * as cheerio from 'cheerio';

export function getImageURL(data: any): string {
    if (!data) return '/img-2.jpg'; 

    if (data?.metadata || data?.html) {
        const $ = cheerio.load(data?.html);
        const ogImage = $('meta[property="og:image"]').attr('content') || data?.metadata.image;
        return ogImage || '/img-2.jpg'; 
    }

    return '/img-2.jpg'; 
}

This function works just like others, and obtains the cover image URL from either the Open Graph image meta tag $('meta[property="og:image"]').attr('content') or || the image property in the JSON-LD data data?.metadata.image.

The getPublishedDate() function:

import * as cheerio from 'cheerio';

export function getPublishedDate(data: any): string {

  if (!data) return 'Date';

  const publishedDate = data?.metadata?.datePublished;

  if (publishedDate) {
    const options: Intl.DateTimeFormatOptions = { year: 'numeric', month: 'long', day: 'numeric' };
    return new Date(publishedDate).toLocaleDateString('en-US', options);
  }

  if (data?.html) {
    const $ = cheerio.load(data?.html);
    const ogPublishedTime = $('meta[property="article:published_time"]').attr('content') ||
                            $('meta[property="og:published_time"]').attr('content') || 
                            $('meta[name="pubdate"]').attr('content');

    if (ogPublishedTime) {
      const options: Intl.DateTimeFormatOptions = { year: 'numeric', month: 'long', day: 'numeric' };
      return new Date(ogPublishedTime).toLocaleDateString('en-US', options);
    }
  }
  return 'Date';
}

This function is especially useful because of the need to convert the date from the ISO 8601 format (2025-04-07T10:47:19+00:00) to the more readable format I want (April 7, 2025). Here, I used the .toLocaleDateString() JavaScript function to make it work (see the (MDN).

7. Create your JSON file

Now, remember that we're building this to be able to pull URLs from a JSON file to put together and render the web page. That JSON file is the starting point of everything. I believe by now you're getting an error concerning that. So we need to create the JSON file.

In the app/ directory, create a new file and name it articles.json.

Then populate it like in this file below – an array of objects with id, URL, tags, and so on. Even though we are not trying to get the title, description, and everything from this file directly, I put in that feature. If you go back to our fetchArticles() function, you'll see that for most of the properties, whatever you write here will override what was gotten from the URLs.

It was partly a fail-safe because I thought that LinkedIn would block all requests, and as you can see from my blog already, some description tags were not well organized. So, we can replace them later with a cleaner description just by modifying this file.

{
    "articles": [
        {
            "id": 1,
            "url": "https://thenetworkbits.substack.com/p/an-overview-of-json",
            "tags": ["Web Dev", "DevOps", "Cloud"],
            "title": "",
            "description": "",
            "image": ""
        },
        {
            "id": 2,
            "url": "https://websecuritylab.org/how-safe-is-public-wi-fi-a-network-engineer-explains/",
            "tags": ["Networking", "Cybersecurity"],
            "title": "",
            "description": "",
            "image": ""
        },
        {
            "id": 3,
            "url": "https://www.freecodecamp.org/news/automate-cicd-with-github-actions-streamline-workflow/",
            "tags": ["DevOps"],
            "title": "",
            "description": "",
            "image": ""
        }
    ]
}

Here, we have an "articles" object with an array of objects, each of which have "id", "url", "tags", "title", "description", and "image" properties. You don't necessarily need the values of all of these except the ID and URL, but the keys have to be there to prevent errors.

8. Add the finishing touches

Now you can add your own favicon in the app directory. It could be a 24px by 24px file, or 48px by 48px file. It doesn't necessarily have to be in the app directory or be an icon file or be named 'favicon' – but I did it that way. You can just add this in the HTML header of your layout.tsx file which is your Next.js version of index.html. The favicon is the icon that shows on the tab in your browser when you open the page.

<link rel="icon" href="/favicon.ico" sizes="any" />

You can also read the Next.js documentations on that here: Metadata Files: favicon, icon, and apple-icon | Next.js. Then add your images to your public/ directory. Be sure to name them correctly, and reference them correctly.

Now, if your development server was down, spin it up again to see your end results!

npm run dev

Conclusion

If you've read this far, then you must be really interested in seeing the results of all this :) I already have that covered. Here's the blog. You can go through it and interact with it.

Also, this is the codebase. Feel free to fork it, clone it, and interact with it as well. If you enjoyed the article, please share it with others. You can also connect with me on LinkedIn or X. Thanks for reading.

The Continuous Integration (CI) part of CI/CD means that developers can always integrate or merge their changes into the shared repository without breaking anything. Continuous Delivery, on the other hand, means that the code changes are automatically prepared for release after testing and validation.

CI/CD primarily involves various stages like building, testing, staging and deployment.

• Build phase: This is where the code and its dependencies are compiled into a single executable. This is the first phase of Continuous Integration, and is triggered by an event like pushing code to the repository.

• Test phase: Here, the built artifacts are tested to be sure that the code runs as expected.

• Staging: Here, the application is run in a production-like environment so as to be sure it is production ready.

• Deployment: Here, the application is automatically deployed to the end-users.

In this article, I’m going to explain how GitHub Actions works. I’ll also talk about basic GitHub Actions concepts, and then we’ll use it to build an example CI/CD pipeline.

What is GitHub Actions?

GitHub Actions is a service or feature of the GitHub platform that lets developers create their own CI/CD workflows directly on GitHub. It runs jobs on containers hosted by GitHub. The tasks are executed as defined in a YAML file called a workflow. This workflow file has to live on the .github/workflows folder on the repository for it to work.

Basic GitHub Actions Concepts

GitHub Actions consists of events, jobs, tasks, runners, workflows, and various other features. Here is a brief explanation of the main concepts:

Events: An event is basically something that happened. With GitHub, an event can be a push (when you push your code to the repository), a pull request, or even a cron job. These events trigger the CI/CD process.

Tasks: When you use CI/CD, you want to be able to trigger an activity that should be done automatically. That activity is known as a task or step in GitHub. It could be building your code or testing it or deploying it.

Each of those tasks has to be defined by commands. A GitHub Actions task usually consists of the name, and the instructions on what to do in the form of a command which starts with - run: or an Action which starts with - uses:.

steps:
  - name: Checkout code
    uses: actions/checkout@v3

  - name: Set up Node.js
    uses: actions/setup-node@v3
    with:
      node-version: 16

  - name: Install dependencies
    run: npm install

  - name: Run tests
    run: npm test

  - name: Build project
    run: npm run build

  - name: Deploy
    run: echo "Deploy step goes here"

Runner: A GitHub runner is a server that runs your tasks. It executes what is defined in your GitHub workflow. You can use your own runners or you can use the GitHub runners.

Job: A job is a collection of steps that are being executed on the same runner. Jobs are defined in a file called the workflow.

Workflow: The GitHub workflow is a series of jobs defined in a YAML file, that are triggered upon an event. The events do not trigger individual tasks. They can only trigger workflows. Then the tasks in the jobs of the workflow are executed.

Contexts: These provide a way to access information about workflows, jobs, and environments in GitHub. They are accessed with the expression $${{ <context> }}. Examples include github, env, vars, and secrets. The github context is used to access information about the workflow. For example:

$${{github.repository}} # should tell the name of the repository

$${{github.actor}}  # should tell the username of user that initially triggered the workflow

Secrets: This is used to store and access sensitive information that’s used by, and is available to, the workflow. Secrets are redacted when printed to the log. An example is $${{secrets.GITHUB_TOKEN}}.

How to Build a Simple CI/CD Pipeline

Here, we’re going to build an example workflow to deploy a simple HTML and CSS website to GitHub Pages. Follow the steps below:

1. Go to the sample code in my repository and fork it from here.

2. Go to the settings tab in the GitHub repository:

3. Go to the Pages settings:

   

4. Set the deployment source to the main branch:

   

5. Go to the General Actions settings and scroll down to the bottom:

6. 

   At the bottom, set the Workflow permissions to read and write:

7. In the GitHub repository, you can clone it to your PC or press the fullstop (.) on your keyboard to open GitHub Codespaces, the online version of VS Code.

8. Go to the sidebar and click on create a new file:

   

9. Create a workflows folder and file. You can call it deploy.yaml.

   

10. Copy this code into the file:

name: Deploy Static HTML and CSS to GitHub Pages

# Trigger the workflow on push to the main branch

on:
  push:
    branches:
      - main
# Define what operating system the job should run on
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
    # Step 1: Checkout the repository
    - name: Checkout Code
      uses: actions/checkout@v4

    # Step 2: Check the files that have been checked out
    - name: Display files
      run: ls

    # Step 3: Deploy to GitHub Pages
    - name: Deploy
      uses: peaceiris/actions-gh-pages@v4
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }}
        publish_dir: ./ # The HTML and CSS files lie in the root directory, hence that should be the publish directory

11. Commit the code. You should see the job running when you go back to the repo:

When you’re done, go back to the home page of the repository and click on the Deployments section. There, you will see the GitHub Pages link to the deployment:

When you’re done, your repository should look like this.

Conclusion

In this article, you learned about how the CI/CD process works. We also covered the basic concepts of GitHub Actions. Finally, we created an example CI/CD pipeline with GitHub Actions. If you enjoyed this article, share it with others. You can also reach me on LinkedIn or X.

Why Use ECS?

There are other container orchestration tools, each with its merits, but ECS is made for AWS and provides seamless integration into the AWS ecosystem. You can use it with AWS Elastic Load Balancer (ELB), AWS Identity and Access Management (IAM), AWS CloudTrail, store persistent data in the AWS Elastic Block Store, or monitor it with AWS CloudWatch.

You can also use it with AWS Fargate, which is a serverless compute engine that provides fully managed containers.

What is Monitoring?

Monitoring is the process of tracking and observing the performance, availability and overall health of your resources, services, and applications. This helps to detect and troubleshoot issues before they impact users, improve application reliability and availability, optimize resource utilization and enhance the security of your applications.

It’s just a way to make sure all the infrastructure is running the way it is supposed to. It also helps you to know how much traffic your app is receiving if it’s a web app or website, and what is really going on with it.

There are different aspects of monitoring, some of which include:

• Performance monitoring: Here, we track and monitor the performance metrics of infrastructure, such as CPU usage, memory consumption, disk, I/O, and networks, and so on.

• Error and log monitoring: Here, we collect and analyze logs and error messages.

• Availability monitoring: We ensure that the systems are up and running.

• Security monitoring: We also track and monitor security-related events and activities to respond to potential threats and vulnerabilities. Monitoring can help you detect things like a DoS attack by identifying unusual patterns in incoming traffic.

What Do You Monitor on ECS?

In cloud monitoring, metrics are used to monitor the health and performance of the infrastructure. They are used together with dimensions. Metrics are the data points collected and monitored to measure the performance, health, and usage of your cloud resources and services.

Dimensions are attributes and characteristics that help to filter, categorize and give context to metrics. They are represented in the form of key/value pairs.

Amazon ECS provides various metrics for monitoring resources. Some of them include:

• CPUReservation: This is the percentage of CPU units reserved by running tasks.

• MemoryReservation: Percentage of memory reserved by running tasks.

• CPUUtilization: This is the percentage of CPU units used by running tasks.

• MemoryUtilization: This is the percentage of memory used by running tasks.

• ContainerInstances: This is the number of container instances in the cluster.

• RunningTasksCount: The number of tasks that are running currently in the cluster.

Amazon ECS also provides dimensions, some of which are:

• ContainerName: The name of the container.

• ClusterName: The name of the ECS cluster.

• ServiceName: The name of the service

• ServiceNameSpace: The namespace used to group a set of services in a cluster.

• InstanceType: This refers to the type of EC2 instance used. For example: t2.micro, c4.large, r5.xlarge, and so on.

• TaskID: The unique identifier assigned to each task.

In AWS ECS, you can monitor your resources at different levels. For example, at the cluster level, you can look at things like CPUUtilization, CPUReservation, MemoryUtilization, and MemoryReservation. At the service level, you can see things like CPUUtilization and MemoryUtilization.

How Do You Monitor ECS**?**

You can do this by making use of:

Amazon CloudWatch: This is a monitoring service by AWS that allows you to collect, analyze and visualize data from your AWS resources. It also helps you to set up alarms and be notified when a threshold is reached.

AWS Management Console: You can also view your cluster or service metrics directly on the management console.

The ECS API: The ECS API provides programmatic access to the ECS service so you can use it to create, modify and monitor clusters and resources from outside AWS.

Third party tools: There are third-party tools like Datadog, Prometheus, and others that can be used to monitor these metrics. Some of them will work seamlessly with AWS, some will require you to install an agent.

For monitoring of ECS on EC2 instances, you have direct access to the underlying EC2 instances, and can use traditional server monitoring tools to monitor metrics on the OS. For ECS on Fargate however, you don't have access to the EC2 instances.

How to Monitor ECS Clusters With AWS CloudWatch

With AWS CloudWatch, you can monitor your ECS clusters in many ways, from metrics to logs to setting up alarms. In this guide, I’ll show you how to use the Automatic Dashboards to view ECS cluster metrics. To do that, follow these steps:

1. From the AWS Management Console, open CloudWatch and go to Dashboards on the sidebar.

2. Click on the Automatic Dashboards tab.

3. Click on ECS Cluster. This will take you to the dashboard where you’ll see the pre-configured metrics for your ECS clusters.

You can also expand individual metrics.

Wrapping Up

In this article, you learned about ECS monitoring. You learned about the different metrics you can monitor and how to monitor them.

Lastly, you learned how to monitor ECS clusters using AWS CloudWatch.

Thanks for reading. You can connect with me on LinkedIn or follow me on X.

A computer is basically a piece of electronic circuitry that performs tasks as instructed by its users.

But for a human to interact with this hardware, they must really know and understand how it works. The person must also know the order in which to give the computer various tasks to produce a meaningful result.

But most of us don't know these things. What happened?

In this article, we're going to look at:

• The history of early computing

• How operating systems were developed

• Modern operating systems

• The development of kernels and shells

• The history of shells

• Why CLI tools are still important

The Early Days of Computers

In the 1800's, computers were mostly used to work on large amounts of numerical data. They were basically programmable calculators the size of small factories.

The data they worked on were also very physical. They were manually fed as punched cards into the machine's card readers. The computers were then programmed by physically rewiring cables, plugboards, and switches to determine what operations would be carried out on the input data. Some of the computers even processed logic through partially mechanical means.

Plugboards allowed you write (or wire) a program and store it so when you needed that program, you'd remove the current plugboard and install a new one. The output of the programs were printed out by line printers, saved on tapes, or punched on cards.

These programming and memory technologies were used in many forms of technological designs.

For example, the Enigma machine which was used to scramble letters and encipher top secret military and diplomatic communication had a plugboard you would rewire to change settings.

The IBM International Daily Dial Attendance Recorder also counted and recorded staff attendance on punched cards. These were more special-purpose equipment.

Early Operating Systems

The first-ever speech synthesis was done in 1962 on an IBM 704, a computer without an operating system.

At the time of the first computers, nobody ever thought of operating systems. People wrote their programs in machine language (or wired them on plugboards) and ran them. There was no way to run two programs at the same time or perform error detection/correction. Your program ran until it either crashed or completed.

IBM 704 computer with two operators in 1957

Initially, computers didn't ship with any software. Later on, IBM included FORTRAN and COBOL compilers in their mainframes. Then came 'resident monitors,' the precursor to operating systems. They literally got the name because they were software that resided in the company's memory and monitored tasks. They basically performed tasks like cleaning up after programs and helping to sequence jobs on the computers.

The first operating systems were made by computer owners who were tired of under-utilizing their computers. They didn't want to have to wait for a program to complete before they manually loaded in another set of data and programs.

One of these early operating systems was the Input/Output System of General Motors and North American Aviation (GM-NAA I/O). Its main aim was to execute the next program automatically after the current one was finished (batch processing). It was created in 1956, and is known as the first-ever working operating system.

IBM later modified one of its customer's operating systems and distributed it as IBSYS. Then, IBM thought that it wasn't good for different computers to have different (machine language) instruction sets, so they stopped all production and started a new line called System/360.

With this, they aimed to build just one operating system for all their computers. It didn't quite go as planned, so they ended up with a family of operating systems, OS/360.

OS/360 included features like time-sharing, error detection/correction, and device management, which are all features implemented in modern operating systems. The OS/360 was introduced in 1964 and was in use until 1977.

Early time-sharing technologies enabled multiple people to access the same mainframe from their different terminals at once. The first computer terminals were teletypewriters (or teletypes). Teletypes were developed around the 1830's but weren't used as computer terminals until the 1970's.

Modern Operating Systems

The MULTiplexed Information and Computing Service (MULTICS) operating system was initially developed for General Electric's 645 mainframe, and later Honeywell's mainframes when they bought over GE's computer division.

It was jointly developed in 1964 by GE, MIT, and Bell Labs, mainly as a successor to the Compatible Time-Sharing System (CTSS).

It came with a lot of new ideas to the computing world like access control, dynamic linking, support for ASCII, and dynamic reconfiguration.

Dynamic reconfiguration allowed the operators to remove and add memories and CPUs without logging out or disrupting users. With the advent of the Compatible Time-Sharing System (CTSS), computers were looked at as a utility.

The idea was that computers were too big and expensive and could be used by only one person at a time. But what if that expensive hardware could be used more efficiently by allowing more than one person to use them at the same time? That way, the computer could become a public utility, accessed from home with terminals.

With a public utility, you need to be able to carry out maintenance on different components without disrupting the service. That was the usefulness of dynamic reconfiguration.

That idea of computers becoming a public utility seems to have lived on with the use of servers, and now, cloud computing.

At a point, MULTICS didn't work out and the companies went their separate ways. Ken Thompson, one of the programmers, later described MULTICS as 'over-designed,' 'overbuilt,' and close to unusable. In an interview with Peter Seibel, he said that the things he liked enough to take from it were the hierarchical filesystem and the shell.

He later went on to create the UNIX operating system with Dennis Ritchie.

The Development of Kernels and Shells

One of the major features of the UNIX operating system was the splitting of the operating system into shell and kernel. The OS kernel was then meant to handle all the system calls, while the shell was used to access the system's services without exposing the inner workings of the operating system.

This concept was first introduced by French computer scientist Louis Pouzin in 1965. He also coined the term shell. This is how he described it in a document titled, The SHELL: A Global Tool for Calling and Chaining Procedures in the System.

We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console . . . we shall refer to that procedure as the "SHELL".

Louis Pouzin's Document on Shells

According to the document, when the user types in a command, the supervisor initiates a new stack to save the command, then calls the shell with the command as an argument.

He also envisioned a future where people created their own shells and used them without having to meddle with the underlying structure of the shell.

"An important facility is that the SHELL being itself a common procedure may be replaced by a private one supplied by the user. On that way, not only a particular procedure can be replaced on user's choice, but all conventions about typing commands may be tailor-made to user's wishes just by providing his own SHELL."

This idea was first implemented in MULTICS, and is one of the only things Ken Thompson admitted to liking enough to take from the project.

Now, in modern operating systems, the shell is the software that lets you communicate with the operating system, and access the OS services which are things like program execution, file management, and I/O management. It could be a command-line shell (CLI) or it could be a graphical user interface (GUI).

The kernel is the part that handles all the system calls, manages computer resources like memory, CPU, and storage, and handles timesharing between processes.

History of CLI Shells

Shells as we know them now really began with UNIX, and one of the first was the Thompson shell.

Thompson Shell (1971)

Ken Thompson, of course, went on to create his own shell. It was a simple command interpreter, not designed for scripting. It introduced the < > symbols for redirecting the input or output of a command, and the | symbol for piping.

C Shell (1978)

The C Shell (or csh) was created by Bill Joy and enabled scripting. The objective was to create a command language that looked more like the C programming language.

Bourne Shell (1979)

Stephen Bourne started work on the Bourne Shell in 1976 as a replacement for the Thompson Shell. It was intended as a scripting language. One of the major goals was to enable using scripts as filters.

Korn Shell (1983)

Developed by David Korn, the Korn Shell was based on source code from the Bourne Shell, and attempted to integrate the features of C Shell and Bourne Shell. It is POSIX.2 compliant.

Bourne Again SHell aka BASH (1989)

BASH was written by Brian Fox in 1989 and released under the GNU license as a free and open-source version of the Bourne Shell.

It was one of the first programs Linus Torvalds ported to Linux and is the default shell for most Linux distributions. It was built for scripting and is POSIX compliant.

Z Shell (1990)

The Z Shell (or Zsh) was created by Paul Falstad as an extended and improved Bourne Shell. The name was derived from the name of a teaching assistant at Paul's university named Zhong Shao.

It also enables scripting and is aesthetically superior to Bash. It supports plugins and extensions, auto-completion, and some other globing capabilities that are unavailable in Bash.

There are many other popular shells used today, but I'm not going to talk about them.

All these shells mentioned did not apply to Windows (until recently). Windows had two command-line shells: Command Prompt (cmd) and PowerShell. The PowerShell was created as an extension to Command Prompt. It supports cmdlets, scripting, piping, and many more features.

Then in 2019, that changed with Windows Terminal, a new terminal emulator for Windows that can run Bash on what is called Windows Subsystem for Linux (WSL). It also supports Command Prompt, PowerShell, and Azure Cloud shell out-of-the-box.

Why Are These CLI Tools Important When We Have Graphical User Interfaces (GUIs)?

You may wonder why we would take the pains to go through this whole evolution and yet still love to use CLI tools and shells. What's so interesting about typing commands into terminals?

The first and most compelling reason is that CLI tools are lightweight because they're text-based. In cases where you have servers and other devices where you need to optimize the use of resources, it's not very wise to use up most of the resources to run GUI interfaces.

Using the CLI can also provide you with a great deal of flexibility and speed that you won't get with a GUI. For example, you may want to search for all the images in a folder with 1000 files and rename them in a certain order. Doing that with your GUI will be time-consuming and maybe frustrating. With the CLI, you can just type a few commands.

Scripts are another important feature. Sometimes, there are tasks you want to carry out multiple times and you don't want to have to navigate through menus all the time or even type commands multiple times. You can write scripts that you run to automatically carry out the tasks repetitively.

In cases where you have to access devices remotely, like web servers or network devices, the CLI is also the most favoured method. Also, for some tasks, it's just easier to do them with a few commands than using your GUI—updating your apps on Linux for example.

Wrapping Up

We've really come a long way from purely mechanical computers to purely electronic computers. The way we interact with computers has changed over the decades, but command-line interfaces aren't going anywhere soon.

Thanks for reading. I hope you enjoyed this article. You can connect with me on LinkedIn.

One of the major mechanisms you use to do that is an access control list (ACL). An ACL is a set of rules for allowing or denying access to certain resources. Resources in this case may be files, networks, or devices.

In this article, we'll talk about what access control lists really are, and how you can use them. We're going to deal with:

• Filesystem ACLs and Network ACLs

• Firewalls and stateful packet filtering

• ACLs in Cloud Networking (Azure NSG, AWS SG, AWS NACL)

• ACLs in DNS (BIND9)

• ACLs in core networking (Cisco ACL types, Huawei ACL types)

Prerequisites

To understand this article, you need a basic understanding of networking, firewalls, and cloud computing. You may particularly need to understand basic of IP addressing and DNS concepts.

Types of Access Control Lists

When we talk about ACLs, many people just think of networks. But in fact, there are two types of ACLs:

• File system ACLs

• Networking ACLs

Filesystem ACLs help operating systems know what the user access privileges are for different files or directories in the system. NFSv4 ACLs and POSIX ACLs are examples of filesystem ACL types.

Networking ACLs are applied on interfaces and you use them to allow or deny traffic from certain sources or to certain destinations. This is what I'll be focusing on in this article.

Structure Of An ACL Rule

An ACL is like a group of rules identified by a name or number. An ACL rule usually has a priority number, the criteria (source address, destination address, and so on) and the allow/deny statement.

Cisco ACL structure

Firewalls and ACLs

A firewall is a security device or software that monitors the traffic going in and out of a device or network, and filters out unwanted or malicious traffic.

Until stateful packet inspection, ACLs were the major mechanism through which firewalls worked. With ACLs, packets are allowed and denied based on properties specified in the rules.

ACLs are stateless. You must create an inbound rule and a corresponding outbound rule, or else packets from one side might be blocked.

With stateful packet inspection (also known as dynamic packet filtering), you could then create security policies for a type of traffic. The firewall would establish a session whenever a packet is allowed, so that any response to that packet is allowed even though there was no specific policy to allow it.

This makes things easier and more efficient than using ACLs that are uni-directional. But it also means that more computing resources are utilized by the firewall and the network is slowed down.

Now, firewalls are a lot more complex than that with deep packet inspection (DPI), Intrusion Detection System (IDS)/Intrusion Prevention System (IPS) capabilities, and even antivirus capabilities, but those are outside the scope of this article.

Let's explore some networking situations where ACLs are used.

ACLs in Cloud Networking

The major cloud service providers (CSPs) provide forms of ACLs or firewall capabilities for their customers to use in their cloud infrastructure.

For example, in Microsoft Azure, we have what is called Network Security Groups (NSG) and in AWS, we have Security Groups (SG) and the Network Access Control List (NACL). These are all implementations of ACL-like security.

AWS

An AWS security group determines what traffic is allowed to and from the resources attached to that security group. It consists of a list of inbound and outbound rules, and is stateful.

Default AWS Security Group

An AWS Network Access Control List is another list of rules but at the subnet level. The rules consist of the rule number, type, protocol, port range, source, destination and allow/deny fields. A NACL can be applied more than one subnet, but a subnet cannot be attached to more than one NACL.

Inbound rules for AWS NACL

Azure

An Azure Network Security Group is a kind of firewall feature that works both at the subnet level and the network interface card (NIC) of the resources in your VNet. It is basically also a list of ACL rules consisting of priority number, name, port, protocol, source and destination.

Here, you can use IP addresses, service tags, or application security groups (ASGs) in the source and destination fields. NSGs are stateful.

Both the Azure NSG and the AWS NACL rules are very similar to the ACL rules used in core networking. Also, you cannot really refer to AWS Security Groups and Azure NSGs as ACLs because they're not stateless.

Azure NSG

ACLs in DNS

DNS servers help resolve domain names to IP addresses. If they accept and respond to requests from every device around them, it will impact their performance and make them susceptible to DDoS attacks. So, DNS administrators use ACLs to determine who can send DNS requests to the servers.

For example, in a BIND9 server, such an ACL will be defined in the named.conf file, and would look like this:

An ACL in BIND9

ACLs in Core Networking

This is a bit more complex than the other contexts we discussed above. ACLs on network devices are configured on the interfaces, and are used in many different scenarios. There are also different types of ACLs. By network devices, I mean devices like routers, switches, firewalls, access controllers, and so on.

Generally, these ACLs are identified by their names or ACL numbers, and their rules follow the format:

permit/deny criteria

For Cisco devices, there are two major types of IPv4 ACLs:

• Standard access lists

• Extended access lists

Standard ACLs

These ACLs permit or deny traffic based on only the source IP address.

R1(config)#access-list 10 permit 192.168.17.0 0.0.0.255

The rule above tells the router to permit packets from the 192,168,17,0/24 subnet. Note that 0.0.0.255 is not a subnet mask. It is a wildcard that tells the device to which extent it must match the address you entered. 255 means any number goes while 0 means it must match exactly.

So here, the network part 192.168.17 must be exactly the same in whatever packet, while the last octet (the host part) can be whatever. You can learn more about IP addressing here.

Extended ACLs

These ACLs permit or deny traffic based on what is known in networking as the 5-tuple (source address, destination address, source port, destination port, transport layer protocol).

R2(config)#access-list 100 permit tcp 10.1.1.0 0.0.0.255 host 10.2.2.2 eq 80

The command above tells the router to permit any packet using the TCP transport layer protocol, coming from the 10.1.1.0/24 network to port 80 (HTTP) of the host, 10.2.2.2.

The term 5-tuple in networking probably originated from mathematics. A tuple means a record/row. 5-tuple means a row with five columns – an ordered list of 5 elements.

The five elements we're mostly concerned with in networking when dealing with packets are the IP addresses (source and destination), port numbers (source and destination), and transport layer protocol. So, they're usually referred to as 5-tuple.

ACL numbers 1 - 99 and 1300 - 1999 denote standard ACLs while numbers 100 - 199 and 2000 - 2699 denote extended ACLs.

Many other vendors follow this pattern, but Huawei doesn't.

For Huawei devices, there are 5 types of IPv4 ACLs:

• Basic ACLs ( ACL numbers 2000 - 2999)

• Advanced ACLs (ACL numbers 3000 - 3999)

• Layer 2 ACLs (ACL numbers 4000 - 4999)

• User-defined ACLs (ACL numbers 5000 - 5999)

• User ACLs (ACL numbers 6000 - 6999)

Basic ACL: Permits or denies traffic based on source address. The ACL number ranges from 2000 - 2999.

Advanced ACL: Permits or denies traffic based on the 5-tuple (source IP address, destination IP address, source port, destination port, and protocol type).

Layer 2 ACL: Permits or denies traffic based on information in the frame header (source MAC address, destination MAC address, layer 2 protocol type).

User-defined ACL: Permits or denies traffic based on packet headers, offsets, character string masks, and user defined character strings.

User ACL: Permits or denies traffic based on source and destination IP addresses or user control list (UCL) groups, source and destination ports, and IPv4 protocol types.

acl 3500                                                
 rule 0 deny tcp source 10.1.1.0 0.0.0.255 destination 192.168.0.9 0 destination-port eq 80                                                                
 rule 5 allow tcp source 10.1.1.0 0.0.0.255 destination 192.168.0.9 0 destination-port eq telnet

Implicit deny

It is also important to note that even if you do not add any rule at the end of your ACL, the last rule there is always a deny rule. It is not shown, so it is implicit. But it is there. It denies any packet that does not match any rule in your ACL.

A Few Things To Know

ACL rules are executed sequentially, so if you have rule 3 and rule 5, rule 3 gets executed first.

It is always a good practice to create rules at intervals (rule 10, rule 20, rule 30) rather than just serially (rule 1, rule 2, rule 3). The reason is that you may want to add a rule in-between two existing rules, and you want the system to execute it in that particular order. It saves stress if there was space for that from the beginning.

Conclusion

Access control is critical to security. Digitally, ACLs have been the go-to mechanism for quick and easy access control. Though other methods like role-based access control (RBAC) and attribute-based access control (ABAC) have emerged, ACL still has its place in access control.

Thanks for reading. If you enjoyed this article, please share it so others can see it too.

You can also connect with me on LinkedIn.