Forem: Gilbert Chris

[Boost]

Gilbert Chris — Mon, 22 Dec 2025 09:04:38 +0000

Serverless Africa: Building Smarter Apps with Google Cloud Functions A practical demo from DevFest Mt Kenya

Gilbert Chris ・ Dec 22

Serverless Africa: Building Smarter Apps with Google Cloud Functions A practical demo from DevFest Mt Kenya

Gilbert Chris — Mon, 22 Dec 2025 09:04:15 +0000

“What if you could ship scalable applications without constantly worrying about servers, infrastructure, and backend chaos?”

That was the guiding question behind my talk at DevFest Mt Kenya 2025, where I explored how serverless architecture on Google Cloud Platform (GCP) can simplify backend development while enabling powerful, real-world solutions.

To avoid abstract theory, I built and demonstrated a small but complete project called Anime-san—a serverless application that ties together frontend, Cloud Run, Pub/Sub, Cloud Functions, and an M-Pesa STK Push flow.

Why Serverless Matters (Especially in Africa)

In many African developer ecosystems, teams are small, resources are limited, and products need to scale quickly once they gain traction. Traditional backend setups often introduce challenges like:

Server provisioning and maintenance

Downtime handling

Scaling during traffic spikes

Complex deployments

Serverless platforms like Google Cloud Functions and Cloud Run shift this burden to the cloud provider. Developers can focus on business logic, not infrastructure.

The Demo Project: Anime-san

Anime-san is a lightweight demo app with a simple idea:

Display random anime quotes

Allow users to “tip” the developer via an STK Push (demo flow)

Process requests asynchronously using cloud-native services

Despite its simplicity, it demonstrates a real production-style architecture.

High-Level Architecture

The project is split into three main parts:

Frontend (React)

Fetches random quotes from a public Anime API

Displays quotes in a clean UI

Sends tip requests to the backend

Backend API (Cloud Run)

Built with Node.js and Express

Exposes a /tip endpoint

Publishes tip requests to a Pub/Sub topic

Runs fully serverless on Cloud Run

Cloud Function Subscriber

Listens to the Pub/Sub topic

Processes incoming tip events

Triggers an STK Push flow (demo/sandbox)

This decoupled approach ensures the system is scalable, resilient, and event-driven.

Why Pub/Sub?

Instead of handling everything synchronously, the backend publishes messages to Google Cloud Pub/Sub.

Benefits:

Loose coupling between services

Better error handling and retries

Easier scaling

Cleaner separation of concerns

This pattern is especially useful for payment flows, notifications, and background processing.

M-Pesa Integration (Demo Context)

While the demo uses sandbox credentials, it reflects real-world patterns used in production M-Pesa integrations:

Backend validates and publishes payment intent

Subscriber handles payment logic asynchronously

Frontend gets immediate feedback without blocking

This architecture works well for:

Fintech applications

E-commerce platforms

Donation and tipping systems

Utility and service-payment apps

Lessons from the Demo

Serverless reduces cognitive load
Less time spent managing servers means more time building features.

Event-driven systems scale naturally
Pub/Sub and Cloud Functions make it easy to handle growth.

Local problems deserve global tools
Combining M-Pesa with modern cloud tools unlocks powerful local solutions.

Demos matter
Seeing a system work end-to-end is far more effective than slides alone.

Why This Matters for GDG Communities

The goal of this demo wasn’t just to show GCP features—it was to inspire developers to:

Build confidently with cloud-native tools

Think in events, not monoliths

Design systems that scale from day one

Apply global technology to local challenges

Final Thoughts

Serverless is not magic—but when used correctly, it’s a force multiplier.

Anime-san may be a small demo, but it represents a bigger idea:
African developers can build scalable, production-ready systems using modern cloud platforms—today.

Huge thanks to GDG Mt Kenya and everyone who attended the session.

Here is the repo:
https://github.com/GilbertKamau/Anime-san-Cloud-Functions

Building a Scalable Backend with DynamoDB Streams — My Journey Before the AWS User Group Pwani Talk

Gilbert Chris — Sat, 06 Dec 2025 23:10:32 +0000

When I agreed to give an online presentation to the AWS User Group Pwani, I knew I didn’t want to show slides full of theory. I wanted something real. Something I could build, demo, and explain — a project that actually does something.

So I decided to create a small but scalable backend system using:

API Gateway

AWS Lambda

DynamoDB

DynamoDB Streams

Everything worked perfectly during the live session (thank God 😅),
but the journey of building it before the talk…
that’s where the real learning happened.

This blog is about that journey — what I built, what surprised me, and the gems I picked up along the way.

Let’s dive in.

🌱 Why This Project?

Before the presentation, I wanted to answer one question:

“How can you build a backend that can scale to millions of users without managing servers?”

AWS has many ways to answer that question, but DynamoDB Streams stood out because:

they’re simple but powerful

they’re event-driven

they allow your backend to react to data in real-time

If you’ve ever wanted to track changes in your database — who registered, who updated their profile, who deleted their account — Streams are the perfect tool.

🧠 DynamoDB Streams — Explained Like You're 10

Think of your DynamoDB table as a notebook.

Every time someone writes in it:

adds a new line

edits a line

erases a line

DynamoDB Streams captures that event like a security camera.

Then it whispers to your Lambda function:

“Hey, someone added a new user!”

“Hey, someone updated their email!”

“Hey, someone deleted an item!”

Your Lambda can react instantly.

That’s the magic of event-driven architecture.

🛠️ Step 1: Building the Backend API

I started with the essentials:

✔ API Gateway endpoint → /register
✔ Lambda function → validates & stores user data
✔ DynamoDB table → Users
✔ Duplicate checks → no repeated emails/usernames

When a user registers, the API saves:

`{
  "name": "Alice",
  "email": "alice@gmail.com",
  "username": "al"
}
`

and returns:

`{"message": "User registered successfully"}`

Simple. Clean. Serverless.

🔄 Step 2: Turning on DynamoDB Streams

Next, I enabled Streams on the Users table with:

Stream type: NEW_AND_OLD_IMAGES

This means:

for INSERT → record the new item

for MODIFY → record both old + new

for DELETE → record the old one

Then I connected the Stream to a new Lambda:

📌 LogUserChangesFunction

This Lambda would “listen” to any change on the table.

⚙️ Step 3: Building the Stream Processor Lambda

Here’s the Lambda handler:

export const handler = async (event) => {
  console.log("=== DynamoDB Stream Event Received ===");
  for (const record of event.Records) {
    const type = record.eventName;
    try {
      if (type === "INSERT") {
        console.log("USER ADDED:", JSON.stringify(record.dynamodb.NewImage));
      } else if (type === "MODIFY") {
        console.log("USER UPDATED - OLD:", JSON.stringify(record.dynamodb.OldImage));
        console.log("USER UPDATED - NEW:", JSON.stringify(record.dynamodb.NewImage));
      } else if (type === "REMOVE") {
        console.log("USER DELETED:", JSON.stringify(record.dynamodb.OldImage));
      } else {
        console.log("UNKNOWN EVENT:", type, record);
      }
    } catch (err) {
      console.error("Error processing record:", err, record);
      throw err;
    }
  }
  return { statusCode: 200 };
};

This tiny function became my “activity logger” for the entire database.

🧪 Step 4: Testing — Where the Learning Really Happened

This is where the real story lives.

📌 Mistake 1: Expecting Streams to Show Old Data

I added a new user named Alice before I turned on Streams.

Later, when I checked logs…
no event.

Because:

☑️ Streams only capture events that happen after you enable them.
❌ They do NOT show past historical changes.

📌 Mistake 2: Updating an Item Is Not an Insert

When I updated Eve’s username from toto → kichwa, I got:

USER UPDATED - OLD: ...
USER UPDATED - NEW: ...

Perfect.

📌 Mistake 3: IAM Is the Silent Gatekeeper

At first, I got errors like:

“Cannot access stream. Ensure GetRecords, ListStreams permissions…”

Streams won’t even fire unless IAM is correct.

Give Lambda:

`dynamodb:GetRecords

dynamodb:GetShardIterator

dynamodb:DescribeStream

dynamodb:ListStreams`

After fixing that, everything worked flawlessly.

📈 Why This Architecture Is Actually Scalable

This simple system becomes extremely powerful because each part scales automatically:

1️⃣ API Gateway

Handles thousands of requests per second.

2️⃣ Lambda

Scales by spawning new instances based on traffic.

3️⃣ DynamoDB

Scales horizontally and supports millions of reads/writes per second.

4️⃣ Streams

Process events asynchronously without slowing down the main API.

Together, they form a backend that can grow from 10 users to 10 million without refactoring.

No servers.
No patching.
No worrying about capacity.

Just pure scalability.

🧩 What I Learned (The Real Takeaways)
✔ Serverless is not about writing less code

It’s about letting the platform handle scaling.

✔ Real scalability comes from loose coupling

Streams turn your system into Lego blocks that talk to each other.

✔ IAM is everything

You can write perfect code and still get blocked by one missing permission.

✔ Logs are your best debugging tool

Every DynamoDB event tells a story.

✔ Event-driven architecture is addictive

Once you start using Streams… you start seeing events everywhere.

🎤 Final Thoughts

When I finally gave the presentation to AWS User Group Pwani, everything worked smoothly — no errors, no surprises, just a clean demo.

But the real win was everything I learned before that moment.

I didn’t just build an API.
I built a scalable, event-driven backend using real AWS production tools.

More importantly:

I gained a deeper understanding of how modern backends should behave — reactive, decoupled, scalable, and effortless to maintain.

If you're curious about serverless, DynamoDB Streams is one of the best ways to start.
Simple idea → big power.

And who knows — your next small experiment might become your next talk or your next startup.