DEV Community: Chidubem Okoli

Building a Custom VPC on AWS with Terraform: Understanding the Architecture

Chidubem Okoli — Wed, 26 Aug 2026 21:03:23 +0000

A VPC (Virtual Private Cloud) is the foundation for networking in AWS. It provides an isolated virtual network where AWS resources such as EC2 instances, databases, and application servers can communicate with each other and with external services in a controlled way.

In this project, I provisioned a custom VPC using Terraform and configured public and private subnets, routing, internet connectivity, security controls, an EC2 instance and an S3 Gateway VPC Endpoint.

More importantly, this project helped me understand how these networking components fit together rather than treating them as isolated AWS resources.

The Architecture

The infrastructure consists of:

A custom VPC using 10.0.0.0/16
A public subnet using 10.0.1.0/24
A private subnet using 10.0.2.0/24
Two Availability Zones
An Internet Gateway
Separate public and private route tables
A security group allowing SSH only from my IP
An EC2 instance in the public subnet
An S3 Gateway VPC Endpoint connected to the private route table
DNS support and DNS hostnames enabled

The architecture can be represented as:

                         INTERNET
                             │
                             │
                    ┌────────▼────────┐
                    │ Internet Gateway│
                    └────────┬────────┘
                             │
              ┌──────────────┴──────────────┐
              │            VPC              │
              │         10.0.0.0/16         │
              │                             │
              │  ┌───────────────────────┐  │
              │  │    Public Subnet      │  │
              │  │     10.0.1.0/24       │  │
              │  │      eu-west-2c        │  │
              │  │                       │  │
              │  │        EC2             │  │
              │  │         │              │  │
              │  │   Security Group      │  │
              │  └───────────────────────┘  │
              │                             │
              │  ┌───────────────────────┐  │
              │  │   Private Subnet      │  │
              │  │     10.0.2.0/24       │  │
              │  │      eu-west-2b        │  │
              │  │                       │  │
              │  │   Private Route Table │  │
              │  │          │            │  │
              │  │          ▼            │  │
              │  │    S3 Gateway        │  │
              │  │      Endpoint        │  │
              │  └───────────────────────┘  │
              │                             │
              └─────────────────────────────┘

1. Creating the VPC

The VPC is the top-level network boundary for the infrastructure.

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "main-vpc"
  }
}

The VPC uses the CIDR block:

10.0.0.0/16

This provides the address space from which the subnets are created.

The /16 gives the VPC a large address range, while smaller /24 networks can be carved out for individual subnets.

I also enabled DNS support and DNS hostnames so resources inside the VPC can use AWS-provided DNS functionality.

2. Dividing the VPC into Subnets

A VPC is a large network, so it is common to divide it into smaller networks called subnets.

I created two:

Public subnet:  10.0.1.0/24
Private subnet: 10.0.2.0/24

The public subnet is located in eu-west-2c, while the private subnet is located in eu-west-2b.

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidr
  availability_zone       = "eu-west-2c"
  map_public_ip_on_launch = true
  tags = {
    Name = "public-subnet"
  }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidr
  availability_zone = "eu-west-2b"
  tags = {
    Name = "private-subnet"
  }
}

A subnet belongs to one Availability Zone.

Using different Availability Zones also introduces the basic concept of fault isolation: resources can be distributed across physically separate Availability Zones instead of depending entirely on one.

What makes a subnet public?

The name public-subnet does not make a subnet public.

A subnet becomes public when its associated route table provides a route to an Internet Gateway.

This distinction is important.

3. Internet Gateway

The Internet Gateway provides connectivity between the VPC and the internet.

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}

However, simply attaching an Internet Gateway to the VPC does not make every subnet public.

The subnet must have a route that directs internet-bound traffic to the Internet Gateway.

That brings us to route tables.

4. Route Tables

A route table determines where network traffic should be sent.

For the public subnet, I created a route table with a default route:

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.gw.id
  }
  tags = {
    Name = "public-rt"
  }
}

The important part is:

0.0.0.0/0 → Internet Gateway

0.0.0.0/0 represents all IPv4 destinations.

Therefore, this route essentially says:

If traffic is destined for somewhere outside the VPC, send it toward the Internet Gateway.

The public subnet is then associated with this route table:

resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}

The private subnet has a separate route table:

resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "private-rt"
  }
}

There is no direct route from this route table to the Internet Gateway.

Therefore, resources in the private subnet do not have a direct route to the public internet.

This is what makes the subnet private from a routing perspective.

5. Public vs Private Communication

One of the most useful things I learned from this project is that "private" does not mean "cannot communicate with anything."

Both subnets belong to the same VPC:

VPC: 10.0.0.0/16
Public subnet:  10.0.1.0/24
Private subnet: 10.0.2.0/24

The VPC has a local route that allows communication within the VPC.

Therefore, a resource in the private subnet can communicate with a resource in the public subnet using their private IP addresses, assuming security controls allow the traffic.

The difference is that the private subnet does not have a direct route to the public internet.

A simple way to think about the components is:

Route table: Where should traffic go?
Internet Gateway: Provides a path between the VPC and the internet.
Security Group: Is the traffic allowed?
Subnet: Which section of the VPC does the resource belong to?

6. Security Groups

I created a security group specifically for SSH access:

resource "aws_security_group" "allow_ssh" {
  name        = "allow_ssh"
  description = "Allow SSH inbound, all outbound"
  vpc_id      = aws_vpc.main.id
}

The inbound rule allows TCP traffic on port 22 only from my IP address:

resource "aws_vpc_security_group_ingress_rule" "ssh_ipv4" {
  security_group_id = aws_security_group.allow_ssh.id
  cidr_ipv4         = var.my_ip
  from_port         = 22
  ip_protocol       = "tcp"
  to_port           = 22
}

My IP is represented as a /32 CIDR, meaning a single IPv4 address.

This is preferable to opening SSH to:

0.0.0.0/0

which would allow SSH attempts from any IPv4 address.

For outbound traffic, I allowed all IPv4 traffic:

resource "aws_vpc_security_group_egress_rule" "allow_all_ipv4" {
  security_group_id = aws_security_group.allow_ssh.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "-1"
}

Security groups are stateful, meaning return traffic for an allowed connection is automatically permitted.

7. Launching the EC2 Instance

The EC2 instance is placed inside the public subnet:

resource "aws_instance" "main" {
  ami                    = var.ami_id
  instance_type          = "t2.micro"
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.allow_ssh.id]
  key_name               = aws_key_pair.generated_key.key_name
  tags = {
    Name = "main-instance"
  }
}

When the instance is launched, AWS creates a primary Elastic Network Interface (ENI) for it.

The ENI is essentially the virtual network adapter that connects the EC2 instance to the VPC.

It is associated with things such as:

The subnet
A private IP address
Security groups

The EC2's network interface provides its connection to the VPC and carries its private network identity.

Because the instance is in the public subnet and the subnet is configured to assign public IPv4 addresses to launched instances, the instance can also receive a public IPv4 address.

This allows me to connect to it from outside the VPC using SSH, provided the route and security group rules allow the connection.

8. S3 Gateway VPC Endpoint

The private subnet doesn't have a direct route to the internet.

But I still wanted resources in the private subnet to be able to access Amazon S3 without requiring a NAT Gateway.

For this, I created an S3 Gateway VPC Endpoint:

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.eu-west-2.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids = [
    aws_route_table.private.id
  ]
  tags = {
    Name = "s3-gateway-endpoint"
  }
}

The endpoint is associated with the private route table.

This provides a private path from the VPC to S3 without requiring the private subnet to have general internet connectivity.

Conceptually:

Private subnet
      │
      ▼
Private route table
      │
      ▼
S3 Gateway Endpoint
      │
      ▼
Amazon S3

This is different from giving the private subnet internet access through a NAT Gateway.

The subnet remains private while still being able to reach the AWS service it needs.

9. SSH Key Management

For SSH authentication, I used Terraform's TLS provider to generate an RSA private key:

resource "tls_private_key" "ec2_key" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

The corresponding public key is registered with AWS:

resource "aws_key_pair" "generated_key" {
  key_name   = "registry-vpc-key"
  public_key = tls_private_key.ec2_key.public_key_openssh
}

Terraform then writes the private key to a local file:

resource "local_file" "private_key" {
  content         = tls_private_key.ec2_key.private_key_pem
  filename        = "${path.module}/registry-vpc-key.pem"
  file_permission = "0400"
}

The 0400 permission ensures that the private key file is readable only by the file owner.

10. Following an SSH Connection Through the Architecture

Putting everything together, an SSH connection from my computer to the EC2 looks roughly like this:

My Computer
     │
     │ TCP 22
     ▼
  Internet
     │
     ▼
Internet Gateway
     │
     ▼
Public Subnet
     │
     ▼
EC2 Network Interface
     │
     ▼
Security Group
     │
     │ Source IP allowed?
     │ TCP 22 allowed?
     ▼
    EC2

Several components have different responsibilities in this flow.

The route table provides the path.

The Internet Gateway provides connectivity between the VPC and the internet.

The network interface connects the EC2 to the VPC.

The security group determines whether the incoming connection is permitted.

Understanding these responsibilities makes the architecture much easier to reason about.

11. What I Built

The final infrastructure can be summarized as:

AWS Region: eu-west-2
│
└── VPC: 10.0.0.0/16
    │
    ├── Availability Zone: eu-west-2c
    │   └── Public Subnet: 10.0.1.0/24
    │       ├── Public Route Table
    │       │   └── 0.0.0.0/0 → Internet Gateway
    │       │
    │       └── EC2
    │           └── SSH allowed from my IP
    │
    └── Availability Zone: eu-west-2b
        └── Private Subnet: 10.0.2.0/24
            ├── Private Route Table
            │
            └── S3 Gateway VPC Endpoint

The project demonstrates the fundamental building blocks of AWS networking:

VPC → Subnets → Route Tables → Internet Gateway → Security Groups → Network Interfaces → EC2 → VPC Endpoints

The most important lesson for me was understanding that these components are not independent pieces of configuration. They work together to determine where resources live, where their traffic can go, and which traffic is allowed.

This foundation makes it much easier to understand more advanced AWS architectures such as load-balanced applications, private application tiers, NAT Gateways, RDS deployments, ECS, and multi-AZ infrastructure.

Deploying a React App to AWS S3 + CloudFront

Chidubem Okoli — Thu, 13 Aug 2026 23:38:59 +0000

What I built

CountryRank is a React (Vite) app for exploring and comparing countries. I deployed it to AWS using a production-grade static hosting setup: a private S3 bucket serving the build output, sitting behind CloudFront for HTTPS, caching, and correct handling of client-side routing.

Stack

React + Vite: the app itself, built to static assets with npm run build
AWS S3: private bucket storing the build output, no public access
AWS CloudFront: CDN in front of S3, HTTPS, custom error handling for SPA routing
AWS IAM (bucket policy): scoped access control via a service principal and condition
Origin Access Control (OAC): the mechanism that lets CloudFront read from the private bucket

Architecture

I built this project in two deliberate stages. I set up plain S3 static hosting first to understand the baseline, then added CloudFront and OAC after seeing the limitations of the S3-only setup.

Step 1: S3 bucket setup

Create the bucket. The name has to be globally unique, lowercase and hyphens only. Dots break SSL matching later if CloudFront gets added.
Turn off Block Public Access for this initial public-hosting stage. AWS made me type a confirmation phrase here rather than just unchecking a box, a useful signal that this is a consequential decision and not a routine toggle.
Enable static website hosting on the bucket:
- Index document: index.html
- Error document: index.html
Attach a bucket policy granting public read access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::dubem-country-rank-app/*"
    }
  ]
}

Two details worth internalizing here. Resource needs /* because s3:GetObject acts on individual objects, not the bucket itself; the bucket ARN without /* refers to the container (its configuration, its listing) rather than what's inside it. And S3 validates the bucket name in the policy against the actual bucket it's attached to, so a typo gets rejected immediately on save.

Upload the build. This is where S3's flat structure matters:

# Wrong: nests everything under a dist/ prefix, so index.html isn't found at root
aws s3 sync dist s3://dubem-country-rank-app/

# Right: the trailing slash means "copy the contents of dist", not "dist as a unit"
aws s3 sync dist/ s3://dubem-country-rank-app/

S3 has no real folders. Everything is a flat list of objects with string keys, and the console just visually groups keys that share a prefix. sync (as opposed to cp --recursive) only uploads what's changed, which matters once I'm redeploying repeatedly.

At this point the site was live on the S3 website endpoint. No server was running anywhere, just object storage answering HTTP requests. But it had real gaps: no HTTPS, no CDN, no custom domain and broken client-side routing. A path like /countries/nigeria isn't a real object in the bucket, so direct navigation or a refresh returns a 404 unless the error document papers over it. Even then, the response still carries a 404 or 403 status code, which is bad for SEO and monitoring. That's what CloudFront fixes.

Step 2: CloudFront setup

Putting CloudFront in front isn't just adding a CDN. It's a structural shift in the trust model. Three things change together:

The bucket goes back to fully private.
CloudFront gets a dedicated identity via OAC to read from it.
The bucket policy's principal changes from "*" to a scoped AWS service principal.

Creating the distribution through the guided console flow looked like this:

Distribution type: Single website or app
Origin: selected via Browse S3, which resolves to the bucket's REST/object endpoint (bucket-name.s3.region.amazonaws.com) rather than the website endpoint
No custom Route 53 domain for now; CloudFront gives a free *.cloudfront.net domain by default
WAF's managed protections left on default (free tier, no cost) rather than customized

Why the REST endpoint and not the website endpoint? OAC works by having CloudFront sign its requests to S3, and only the REST API understands signed requests. The website-hosting endpoint is public-only by design and can't validate a signature. Since the bucket is going private anyway, the website endpoint becomes irrelevant at this stage regardless.

One consequence worth flagging: the REST endpoint has no concept of index or error documents. Everything configured in Step 1's hosting settings doesn't carry over. CloudFront needs its own equivalent settings, covered next.

Step 3: Setting up OAC

Enabling "Allow private S3 bucket access to CloudFront" during distribution creation is the actual OAC toggle. It does two things: it creates an Origin Access Control resource, and it auto-generates a bucket policy update scoped to that resource.

The generated policy looked like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipal",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::dubem-country-rank-app/*",
      "Condition": {
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:cloudfront::942004241182:distribution/E2XUCTY83EAT31"
        }
      }
    }
  ]
}

The Condition block matters more than it looks. Service: cloudfront.amazonaws.com alone would let any CloudFront distribution in any AWS account read the bucket. Scoping it to a specific SourceArn restricts it to this one distribution. Without that, I would just be trading one public-access problem for a slightly narrower one.

Important: enabling OAC updates the bucket policy, but it doesn't touch Block Public Access or remove prior policy statements automatically. That's what bit me next.

Errors I hit and how I fixed them

1. AccessDenied on the CloudFront root URL

After the distribution deployed, hitting the CloudFront URL returned:

<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
</Error>

I reasoned through it like this: when requesting /, what object key was CloudFront actually asking S3 for? Nothing in the setup so far told CloudFront that / should resolve to index.html. That's a distribution-level setting called Default Root Object, and it isn't inherited from anything configured back in Step 1.

Fix: in the distribution, go to General, click Edit and set Default Root Object to index.html.

2. Client-side routes still broken after that

Fixing the root didn't fix direct navigation to /countries/nigeria. Same underlying problem as the S3-only stage, still unresolved, because Default Root Object only handles the exact-root case.

Fix: Custom Error Responses on the distribution:

HTTP error code	Response page path	HTTP response code
403	`/index.html`	200
404	`/index.html`	200

Both codes are needed because a private bucket accessed via OAC tends to return 403 for a missing key rather than a clean 404. It doesn't distinguish "doesn't exist" from "not allowed to see it," it just denies. This is the fix plain S3 hosting couldn't offer: CloudFront can rewrite the status code itself, not just swap in different content, so a deep-linked SPA route now returns a legitimate 200 while React Router takes over client-side.

3. Old public bucket policy left stacked on top of the new one

After everything was working, I went back and checked the bucket policy directly instead of assuming the wizard had cleaned up after itself. I found the original Principal: "*" statement from Step 1 still sitting there, alongside the new CloudFront-scoped one. Block Public Access was also still off.

That meant the bucket was reachable two ways: through CloudFront (secured, cached, HTTPS) and directly via the old public endpoint (none of that), quietly defeating the point of the whole migration.

Fix:

Removed the old Principal: "*" statement, keeping only the CloudFront-scoped one.
Re-enabled Block Public Access.
Verified by testing both URLs: the CloudFront URL still worked, and the direct S3 endpoint failed. That's the actual proof the bucket is only reachable through the intended path.

What I learned

S3 access control is layered: Block Public Access is the master override, the bucket policy is the grant, and the resource ARN scope decides bucket versus object. All three have to align, and missing any one breaks things in a specific, diagnosable way.
S3 "folders" are prefixes, not real directories. This affects upload commands directly, not just how the console displays things.
Website-hosting endpoints and REST endpoints are genuinely different features with different capabilities. OAC only works with the REST one.
CloudFront doesn't inherit S3's static-hosting settings. Default Root Object and Custom Error Responses have to be configured independently, and skipping them produces specific, traceable errors rather than vague failures.
Auto-generated policies from console wizards can leave old, conflicting statements behind. It's worth checking the actual policy JSON manually rather than assuming the tool fully cleaned up after itself.
Debugging AccessDenied is faster when reasoning through which layer is missing (policy, public access block, or routing config) rather than guessing and re-toggling settings at random.

Set Up SSH Keys on Windows: A Step-by-Step Guide

Chidubem Okoli — Tue, 02 Sep 2025 08:08:57 +0000

Secure Shell (SSH) is a security protocol that creates a highly secure connection between your computer and GitHub. It uses a pair of cryptographic keys—a public key you share and a private key you keep safe—to verify your identity.

The main benefit of using SSH keys is convenience and security. Once set up, you can connect to GitHub to push and pull code without having to enter your username and personal access token every time.

Here's a step-by-step guide on how to set up your SSH keys in a Windows environment.

Step 1: Check for Existing SSH Keys
First, let's see if you already have an SSH key pair. It's good practice to avoid creating new ones if you don't have to.

a) Open PowerShell (press the Windows key, type PowerShell, and press Enter).

b) The default directory is /.ssh. Run the following command to list files in the .ssh directory, which is where keys are typically stored:

ls -a ~/.ssh

c) Look for a pair of files named something like id_rsa and id_rsa.pub, or id_ed25519 and id_ed25519.pub. If you see a .pub file, you already have a key and can skip to Step 3.

Alternatively, you can get the key by typing into the powershell terminal

cat id_ed25519.pub

Step 2: Generate a New SSH Key Pair

If you don't have an existing key, you'll need to create one. We'll generate a modern and secure Ed25519 key.

a) In your PowerShell terminal, run the following command. Make sure to replace "your_email@example.com" with the email address associated with your GitHub account.

ssh-keygen -t ed25519 -C "your_email@example.com"

b) The command will prompt you to choose a location to save the key. The default location (~/.ssh/id_ed25519) is perfect, so just press Enter.

c) Next, you'll be asked to enter a passphrase. 🔐

A passphrase adds an extra layer of security; if someone gains access to your computer, they still can't use your key without knowing the passphrase.
It's highly recommended to use one, but you can leave it blank by pressing Enter twice.

> Enter passphrase (empty for no passphrase): [Type a passphrase]
> Enter same passphrase again: [Type passphrase again]

You've now created two files in your ~/.ssh directory: id_ed25519 (your private key) and id_ed25519.pub (your public key). Never share your private key!

Step 3: Add Your SSH Key to the ssh-agent
The ssh-agent is a background program that securely stores your private key and manages its passphrase so you don't have to re-enter it constantly.

a) First, ensure the ssh-agent service is running. This command will start it if it isn't active.

Start-SshAgent

b) Now, add your private SSH key to the agent.

ssh-add ~/.ssh/id_ed25519

c) If you created a passphrase in the previous step, you will be prompted to enter it now.

Step 4: Add Your Public SSH Key to GitHub
Now you need to tell GitHub about your public key so it can grant you access.
a) Now you need to copy your public SSH key. To do this, we’re going to use a command called cat to read the file to the console.

cat ~/.ssh/id_ed25519.pub

b) Open your browser and navigate to GitHub.

Click your profile picture in the top-right corner, then click Settings.
In the left sidebar, click SSH and GPG keys.

c) Click the New SSH key button.

d) In the Title field, give your key a descriptive name, like "My Windows Laptop" or "Work PC".

e) Click inside the Key field and paste your key by pressing Ctrl + V.

f) Finally, click Add SSH key. You may be asked to enter your GitHub password to confirm.

Step 5: Test Your SSH Connection
Let's make sure everything is working correctly.

a) Back in your PowerShell terminal, run this command:

ssh -T git@github.com

b) You may see a warning about the authenticity of the host. This is normal for the first connection.

The authenticity of host 'github.com (IP ADDRESS)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes and press Enter.

c) If everything is set up correctly, you'll see a welcome message with your username! 🎉

Hi your-username! You've successfully authenticated, but GitHub does not provide shell access.

You're all set! You can now clone, pull, and push to your GitHub repositories using SSH without needing to enter your credentials every time.

How I Fixed Firebase’s “Unauthorized Domain” Error While Building Resumpire

Chidubem Okoli — Wed, 09 Jul 2025 14:52:58 +0000

The Problem:

I was deep into building resumpire.vercel.app (a resume builder app) when I hit a wall. Firebase kept rejecting my authentication requests with an “Unauthorized Domain” error.

At first, I was running through all the usual suspects:

Maybe I broke something in my codebase?
Could there be a dependency version conflict?
Is there a typo in my config?

After scouring my codebase trying to find the bug, I finally spotted the issue.
Turns out, the issue was much simpler.

The Culprit: Firebase’s Authorized Domain List
Firebase Authentication only allows requests from domains you explicitly authorize. That means:

If you’re testing locally, you must add http://localhost (or your custom dev URL) to Firebase’s Authorized Domains list.

If you’re deploying, your live domain (e.g., resumpire.vercel.app) needs to be added too.

My deployed domain resumpire.vercel.app wasn't in the Firebase Authorized Domains list. I'd only added localhost during development.

How I Fixed It

Opened Firebase Console → Authentication → Settings
Scrolled to “Authorized Domains”
Added my production domain (resumpire.vercel.app)
Reloaded the app → Auth worked instantly

Lesson learned: Always check the docs (and the obvious settings) first.

Why This Matters
This wasn’t just about fixing an error—it reinforced a bigger lesson:

Small oversights cause big blockers.
Reading docs > guessing.
Every error is an avenue to learn and grow which makes you a better dev.

How I Built an AI-Powered Text Processor Using Chrome AI API.

Chidubem Okoli — Thu, 27 Mar 2025 08:40:36 +0000

Introduction

When I first discovered the Chrome AI API, I recognized its potential immediately. The ability to integrate AI-powered text processing directly into a web app—without requiring a backend—opens up new possibilities for seamless user experiences. Using React and TailwindCSS, I built a practical AI Text Processor capable of summarizing, translating, and detecting languages entirely in the browser.

In this guide, I’ll walk you through:
✔ Why the Chrome AI API is a game-changer
✔ Step-by-step setup (including troubleshooting tips)
✔ How I built the UI with React & TailwindCSS
✔ Lessons learned and where to go next

Setup & Prerequisites

Before diving in, you’ll need:

1) Comply with Google’s AI Policies

Ensure your use case follows Google’s Generative AI Prohibited Use Policy.

2) Install Chrome Canary

Download Chrome Canary (v129.0.6639.0 or newer). Why Canary? The API is experimental and only available here for now.

3) Check Storage Requirements

Minimum 22GB free storage. If storage drops below 10GB, Chrome automatically deletes the model.

4) Enable the Summarization API

Open chrome://flags/#summarization-api-for-gemini-nano
Select Enabled
Relaunch Chrome

5) Force-Download the AI Model

Open DevTools (F12) and run:

await ai.summarizer.create(); // Triggers model download await ai.summarizer.capabilities(); // Check status
Repeat the second command until it returns "readily" (~3-5 mins).

Stuck? If you see:

"The model was available but there was no execution config available for the feature."

Wait 24 hours and retry (Google rolls out access gradually).

Troubleshooting Tip: For full documentation, check Chrome’s AI API Guide here.

Why the Chrome AI API?

This API brings serverless AI to the browser with:
✅ No backend needed – Runs entirely client-side.
✅ Blazing fast – Responses in milliseconds.
✅ Privacy-focused – No data sent to third-party servers.
✅ Easy integration – Just call ai. methods like translate() or summarize().

Project Features

The AI Text Processor includes:

Text Input - A responsive text area for content entry
Language Detection - Automatic identification of input text language
Text Summarization - Concise distillation of key information
Multilingual Translation - Conversion between supported languages
Accessible Interface - Screen reader compatible with keyboard navigation
Error Handling - Graceful failure modes and user feedback

Tech Stack

React – UI components & state management.
TailwindCSS – Rapid styling.
Chrome AI API – ai.summarizer, ai.translator, ai.detector.

Building the App

1) Initialize the Project

npm create vite@latest ai-text-processor --template react cd ai-text-processor npm install

2) Add TailwindCSS

npm install -D tailwindcss postcss autoprefixer npx tailwindcss init -p

Configure tailwind.config.js:

export default { content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx}"], theme: { extend: {} }, plugins: [], };

Add to index.css:

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

3) Create the UI
A simple layout with:

A textarea for input.

Buttons for actions (Summarize/Translate/Detect).

A results panel (conditional rendering with error handling).

4) Integrate the Chrome AI API

const handleSummarize = async () => { try { const summary = await ai.summarizer.summarize(text); setResult(summary); } catch (error) { setResult("Error: " + error.message); } };

Future Improvements

More languages – Expand translation support.

Offline mode – Cache results for poor connectivity.

Custom prompts – Let users tweak summarization style.

Conclusion

The Chrome AI API opens up exciting possibilities for browser-based AI apps. While still experimental, it’s a glimpse into a future where frontend devs can leverage AI without backend complexity.

Try the demo & code

GitHub Repo Link here
Live Link here
Note: This implementation is currently available only for desktop platforms

Recreating the Interswitch Homepage with React and TailwindCSS.

Chidubem Okoli — Tue, 14 Jan 2025 13:24:30 +0000

Introduction

Recreating a modern, visually appealing landing page is always an exciting challenge. This week, I focused on building a replica of the Interswitch homepage using React and TailwindCSS. This article provides a technical walkthrough of the process, from project setup to implementing reusable components and styling. Here's how I approached it:

Project Setup with Vite

Vite has become my go-to tool for React projects due to its blazing-fast build times and simplicity. The setup process involved:

npm create vite@latest interswitch-clone --template react
cd interswitch-clone
npm install

With the development server running, I was ready to start coding.

Structuring Components

Breaking the homepage into reusable components was essential for maintainability and scalability. Below are a few key components I implemented.

NavBar Component

import { useState } from "react";
import { FaBars, FaTimes } from "react-icons/fa";
import { FiChevronDown } from "react-icons/fi";

const Navbar = () => {
  const [isOpen, setIsOpen] = useState(false);
  const [dropdownOpen, setDropdownOpen] = useState(false);

  const navLinks = [
    { title: "About Us", hasDropdown: true },
    { title: "What We Do", hasDropdown: true },
    { title: "Financial Inclusion", hasDropdown: false },
    { title: "Corporate Responsibility", hasDropdown: false },
    { title: "News & Insights", hasDropdown: false },
  ];

export default Navbar;

Stats Component

const Stats = () => {
  return (
    <div className="bg-blue-50 py-12">
      <div className="max-w-7xl mx-auto px-4 sm:px-6 lg:px-8">
        <div className="flex flex-col gap-8">
          <div className="flex flex-col md:flex-row items-start gap-8">
            <h2 className="text-3xl md:text-4xl font-semibold text-gray-900 flex-1">
              Pushing the boundaries of innovation to deliver payment solutions that enable commerce across Africa
            </h2>
            <div className="flex-1 flex flex-col gap-4">
              <p className="text-xl text-gray-700">
                Bespoke payment solutions for your modern lifestyle, business collections, disbursements, and payment processing.
              </p>
              <button className="bg-blue-950 text-white px-6 py-3 rounded-md hover:bg-blue-900 transition w-fit">
                Learn More
              </button>
            </div>
          </div>
export default Stats;

Styling with TailwindCSS

TailwindCSS made styling the components seamless. By leveraging utility classes, I could focus on functionality without writing custom CSS. For example, the hero section below uses Tailwind’s gradient and typography utilities to create an eye-catching design.

const Hero = () => {
  return (
    <div className="text-blue-950 pt-6 relative">
      <div className="max-w-6xl mx-auto px-4 sm:px-6 lg:px-8">
        <div className="grid md:grid-cols-2 gap-12 items-center">
          <div>
            <h1 className="text-2xl md:text-7xl mb-6 mt-16 font- text-blue-950">
              The Gateway To Africa&apos;s Payment Ecosystem
            </h1>
            <p className="text-xl md:text-xl mb-8 text-black-200">
              We create and sustain a payment ecosystem that helps 
  commmerce evolve, businesses grow and individuals thrive.
            </p>
          </div>
       </div>
     </div>
  </div>


export default Hero;

Key Takeaways

Componentization: Breaking the UI into reusable components ensured better maintainability.
TailwindCSS: The utility-first approach made styling intuitive and efficient.
Vite: Its fast build times improved the development experience.

Conclusion

Recreating the Interswitch homepage was a rewarding experience that solidified my understanding of React and TailwindCSS. By leveraging modern tools and best practices, I built a scalable and visually appealing landing page. If you’re working on a similar project or have questions, let’s connect in the comments!

Elevate Your JavaScript Journey: Tackling Projects and Unlocking Features 🚀

Chidubem Okoli — Thu, 05 Dec 2024 17:04:36 +0000

JavaScript is an ever-evolving journey where each project adds a new layer to your skills. Whether you're building a ticketing system or adding functionality to a to-do list, there's always something new to learn! Let me walk you through my recent experiments, lessons, and insights.

Building a Ticketing System 🎟️

When working on a ticket system, I wanted to level it up by allowing users to input any number of tickets instead of relying on predefined buttons. The goal was simple: improve flexibility while keeping the system intuitive.

Here’s what I learned:

DOM Manipulation Is Key: Capturing input values dynamically and using them effectively in your JavaScript logic is vital.

Validations Matter: When you let users enter values, ensure you're checking for edge cases like negative numbers or empty inputs.

Iterate & Improve: Building on the foundational ticket counter I developed earlier, I realized how important it is to refactor code for scalability.
If you're considering a project like this, start small. Add basic functionality, then challenge yourself to build on top of it.

Adding Delete Functionality to a To-Do List ✔️❌

To-do lists are a staple project for beginners—and for good reason! They offer a practical way to learn about adding and removing elements from the DOM. Recently, I wanted to add a delete button to each item dynamically.

My Approach:

Generate Buttons on Item Creation: When the user adds a new task, a delete button is created alongside it.

Add Event Listeners Dynamically: I attached an event listener to each button to handle the deletion logic.

Parent-Child DOM Interaction: Using parentElement, I ensured clicking the delete button would remove its corresponding list item.
Here’s a snippet of the core idea:

function addTask(taskText) {

  const li = document.createElement("li");
  li.textContent = taskText;

  const deleteBtn = document.createElement("button");
  deleteBtn.textContent = "Delete";


  deleteBtn.addEventListener("click", () => {
    li.remove();
  });

  li.appendChild(deleteBtn);
  document.querySelector("#task-list").appendChild(li);
}

With this approach, I learned how important it is to structure your DOM interactions cleanly and avoid cluttered logic.

Lessons Learned 🧠

1.Experimentation Drives Learning

Projects like these reinforce that theory is nothing without practice. By experimenting with features, I gained a deeper understanding of DOM manipulation, event listeners, and JavaScript logic.

2.Simple Features, Big Impact

The smallest changes—like a delete button—can significantly enhance your project's user experience. Don't underestimate the value of small wins!

3.Learn in Layers

Building on previous projects is the best way to reinforce your skills. I started with a basic ticket counter, then expanded it. Similarly, I took my to-do list from "add-only" to "add-and-delete."

What's Next?🔮

JavaScript is all about iteration. I’m excited to explore more advanced concepts like input validations, animations, and even local storage to persist data between sessions.

If you're on a similar journey, start small and stay consistent. Every project you complete is another step forward.

Let me know in the comments—what’s your favorite beginner-friendly JavaScript project?

Happy coding! 🚀

Installing And Running NPM Packages Using The Terminal

Chidubem Okoli — Mon, 04 Nov 2024 08:57:52 +0000

When working on a JavaScript project, chances are you'll need to install and use npm (Node Package Manager) packages.

npm is essential for managing libraries and tools that enhance your development process. If you're new to this, here's a step-by-step guide to installing and running npm packages using the terminal.

Prerequisites
Install Node.js: Ensure that the recent version of Node.js is installed on your machine, as npm comes bundled with it. You can check if it's installed by running:

node -v

and

npm -v

If you don't have it installed, download it from https://nodejs.org/https://nodejs.org/ and follow the installation instructions.

After confirming it is successfully installed, create a folder for your project or navigate to an existing one.

Initialize The Project

To start using npm, you need a package.json file, which tracks the project's dependencies and scripts. You can create one by running:

npm init

You’ll be prompted with some basic questions (like project name, version, description, etc.). You can either answer each or press Enter to accept the defaults.
Alternatively, you can use npm init -y to create a default package.json file without prompts.

Installing npm Packages

With npm, you can install packages either globally or locally to your project.

Local Installation: Installs the package in the project directory and adds it to your package.json.

npm install package-name
This installs the package locally. You'll find it under the node_modules folder, and it will be listed in your package.json file.

Global Installation: Installs the package globally on your system, making it available from any directory.

npm install -g package-name

This installs the package globally, allowing you to run the package commands directly in any project without needing to install it locally.

Using npm Scripts to Run Commands

Scripts defined in package.json can simplify common tasks like running tests or starting the server. In your package.json, there’s a "scripts" section where you can define custom commands.

Example:

"scripts": { "start": "node index.js", "test": "echo \"Error: no test specified\" && exit 1" }
In this example:

"start" will run "node index.js".
You can replace "test" or "start" with other custom scripts.

To run a script, use:

npm run script-name

Running Installed Packages from the Terminal

If you installed a package globally, you can use it directly in the terminal.
For locally installed packages, use npx, which comes bundled with npm:
npx package-name
Example:

npx create-react-app my-app
This command runs the create-react-app package without needing to install it globally.

Updating and Removing Packages

To update a package, use:
npm update package-name
To remove a package, use:

npm uninstall package-name
This command will remove the package from the node_modules folder and from package.json.

Conclusion
By understanding these basic npm commands, you can confidently install, run, and manage packages in any Node.js project.