DEV Community: Gilbert Ngeno

When Your Database Becomes the Bottleneck: Scaling the Data Layer Before It Takes Down Your Application

Gilbert Ngeno — Thu, 17 Sep 2026 17:45:03 +0000

There is a common assumption in modern application architecture:

If the application gets more traffic, add more application servers.

That works surprisingly well—until it doesn't.

You add more Kubernetes pods. You increase the replica count. You enable autoscaling. Yet the application is still slow.

Requests continue timing out.

Users complain that pages take too long to load.

Then you look deeper into the architecture:

                    Internet
                       │
                       ▼
                ┌─────────────┐
                │Load Balancer│
                └──────┬──────┘
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
          ┌─────┐   ┌─────┐   ┌─────┐
          │ API │   │ API │   │ API │
          │ Pod │   │ Pod │   │ Pod │
          └──┬──┘   └──┬──┘   └──┬──┘
             │         │         │
             └─────────┼─────────┘
                       ▼
                ┌─────────────┐
                │  Database   │
                └─────────────┘

The application tier has scaled.

The database has not.

This is one of the most important challenges in production engineering because databases don't scale in exactly the same way as stateless application servers.

You can often add another API pod in seconds.

You cannot simply add another database and expect the workload to double in capacity.

The question therefore becomes:

How do you increase data-layer capacity without introducing unnecessary complexity or destabilizing the system?

1. Start by Finding the Real Bottleneck

Before changing the architecture, establish what is actually limiting performance.

A slow application does not necessarily mean the database needs more hardware.

The database could be spending most of its resources on:

inefficient queries
missing indexes
excessive connections
lock contention
disk I/O
large result sets
analytical workloads
replication
cache misses

A useful investigation starts with four dimensions:

                       Database
                          │
          ┌───────────────┼───────────────┐
          ▼               ▼               ▼
         CPU             Memory           I/O
          │               │               │
     Query cost       Cache usage      Disk latency
     CPU saturation   Buffer usage     IOPS

                    + Connections
                    + Locks
                    + Replication lag
                    + Query latency

Look at both infrastructure and query-level metrics.

For example:

CPU Usage              87%
Active Connections     920 / 1000
P95 Query Latency      480ms
Disk Latency           22ms
Replication Lag        4.2s
Slow Queries           18

These measurements tell a very different story from simply saying:

"The database is slow."

The first rule of database scaling is therefore simple:

Measure before modifying the architecture.

2. Remove Work Before Adding Capacity

The cheapest database capacity is the capacity you don't need.

This is where query optimization belongs.

Suppose an order-history endpoint executes:

SELECT *
FROM orders
WHERE customer_id = ?
ORDER BY created_at DESC;

If the table contains hundreds of millions of rows and the query lacks an appropriate index, the database may perform far more work than necessary.

A suitable index can change the access pattern from:

Millions of rows
       │
       ▼
    Scan rows
       │
       ▼
     Filter
       │
       ▼
      Sort
       │
       ▼
    Response

to:

       Index
         │
         ▼
 customer_id
         │
         ▼
 created_at
         │
         ▼
 Required rows

The same principle applies to:

selecting unnecessary columns
retrieving enormous result sets
inefficient joins
missing indexes
repeated queries
offset-heavy pagination

For large datasets, cursor-based pagination can also prevent increasingly expensive scans when users move deep into a result set.

The important idea is that scaling should begin with reducing unnecessary work, not immediately adding infrastructure.

3. Control How Much Traffic Reaches the Database

Even efficient queries can overwhelm a database if too many requests arrive simultaneously.

One common source of pressure is database connections.

Imagine:

100 API Pods
     │
     │ 100 connections each
     ▼
10,000 database connections

The database may spend significant resources managing connections instead of processing useful work.

Connection pooling gives the application a controlled pool of reusable connections:

                 API Pods
                    │
                    ▼
            ┌───────────────┐
            │Connection Pool│
            └───────┬───────┘
                    │
          Controlled connections
                    │
                    ▼
               Database

The pool must be sized according to actual database capacity.

More connections do not automatically mean more throughput. Beyond a certain point, concurrency can increase contention and reduce overall performance.

The same principle applies to traffic.

If a sudden spike sends far more requests than the database can process, rate limiting and backpressure can prevent the data layer from being overwhelmed.

Clients
   │
   ▼
API Gateway
   │
   ▼
Rate Limit / Queue
   │
   ▼
Application
   │
   ▼
Database

This turns an uncontrolled traffic spike into a workload the database can actually handle.

4. Keep Repetitive Reads Away From the Database

Not every request needs to reach the database.

Suppose thousands of users request the same product information.

Without caching:

1,000 requests
      │
      ▼
1,000 database queries

With a cache:

1,000 requests
      │
      ▼
    Cache
      │
      ├── Cache hits → Response
      │
      └── Cache miss
              │
              ▼
          Database

Caching is particularly useful for data that:

is requested frequently
changes relatively infrequently
is expensive to compute
can tolerate a defined amount of staleness

Typical examples include product information, configuration, permissions, and reference data.

However, caching introduces another engineering problem: invalidation.

You now have to decide:

When does cached data expire?
What happens when data changes?
Can stale data be shown?
What happens when many requests miss the cache simultaneously?

A cache therefore isn't simply "put Redis in front of the database." It is another consistency boundary that needs to be designed and monitored.

5. Separate Reads From Writes

If the workload is primarily read-heavy, a single database may be spending most of its capacity serving queries that don't modify data.

Read replicas can distribute that workload.

                    Application
                   /           \
                  /             \
             Writes             Reads
                │                 │
                ▼                 ▼
           ┌─────────┐      ┌───────────┐
           │ Primary │─────►│ Replica 1 │
           └─────────┘      └───────────┘
                                  │
                         ┌────────┴────────┐
                         ▼                 ▼
                    Replica 2         Replica 3

The primary handles writes while replicas serve suitable read traffic.

This can provide substantial additional read capacity without changing the application's fundamental data model.

But replicas introduce replication lag.

For example:

Primary:
Order status = SHIPPED

Replica:
Order status = PROCESSING

If the application immediately reads after a write, it may observe stale information.

Applications therefore need to distinguish between operations requiring:

strong consistency

and those that can tolerate:

eventual consistency.

For example, an order immediately after payment may need to be read from the primary, while a product catalog page may safely use a replica.

6. Stop Using the Transactional Database for Everything

A common source of database pressure is workload mixing.

The same database might simultaneously handle:

Customer transactions
Inventory updates
Reports
Analytics
Search
Exports
Background jobs

These workloads have very different characteristics.

A customer placing an order requires a predictable transactional response.

An analytics query scanning 500 million rows does not.

Running both against the same database creates competition for:

CPU
memory
disk I/O
connections
locks

A better architecture separates them:

                         Primary DB
                             │
              ┌──────────────┼──────────────┐
              │              │              │
              ▼              ▼              ▼
          Application      CDC / ETL      Replicas
                             │
                             ▼
                     Analytics Platform

Change Data Capture (CDC) can stream database changes into systems designed for analytical workloads.

The same principle applies to search.

Instead of forcing a transactional database to perform complex full-text searches:

                 Application
                /           \
               ▼             ▼
       Transaction DB    Search Engine

the database remains the source of truth while a specialized search system handles search-oriented workloads.

This is an example of workload specialization.

7. Partition Data When Tables Become Too Large

Sometimes the workload itself is reasonable, but the dataset has become enormous.

Consider:

orders
500,000,000 rows

Maintaining and querying a single structure at this size can become increasingly expensive.

Partitioning divides the table into smaller logical pieces.

For example:

orders
│
├── 2024
│   ├── Q1
│   ├── Q2
│   ├── Q3
│   └── Q4
│
└── 2025
    ├── Q1
    ├── Q2
    ├── Q3
    └── Q4

A query for recent orders can then operate on a smaller portion of the dataset.

Partitioning can also simplify:

archival
data retention
maintenance
index management
deletion of old data

But partitioning only helps when the partition key aligns with actual access patterns.

Choosing a poor partition key can simply move the bottleneck somewhere else.

8. When One Database Is No Longer Enough: Sharding

Eventually, a single database instance may reach a fundamental capacity limit.

At this point, the workload can be distributed across multiple database instances.

This is sharding.

                     Application
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
          Shard 1       Shard 2       Shard 3
             │            │            │
          Users A-D     Users E-M     Users N-Z

A shard key determines where a record belongs.

For example:

hash(customer_id)

might distribute customers across several databases.

This increases the amount of data and workload the system can handle collectively.

But it also introduces significant complexity.

A query that previously required one database:

SELECT *
FROM orders
WHERE customer_id = 1234;

may remain straightforward if the application knows the customer's shard.

A query such as:

Find the top 100 orders across all customers

may now require:

             Application
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    Shard 1    Shard 2    Shard 3
       │          │          │
       └──────────┼──────────┘
                  ▼
             Merge Results

Distributed transactions, cross-shard joins, rebalancing, and operational tooling all become more complicated.

For that reason, sharding should generally be introduced because measurements demonstrate that simpler approaches cannot meet the required capacity—not simply because the system is getting large.

9. Decouple Non-Critical Work With Events

Another way to reduce database pressure is to remove unnecessary synchronous work.

Consider order creation.

The customer-critical operation might be:

Create Order

But several other actions may follow:

Send email
Generate invoice
Update analytics
Notify warehouse
Update recommendations

Doing everything synchronously creates a long request path:

API
 │
 ├── Database
 ├── Email
 ├── Invoice
 ├── Analytics
 └── Warehouse

An event-driven architecture can separate those responsibilities:

                API
                 │
                 ▼
            Order Database
                 │
                 ▼
              Event Bus
          ┌──────┼───────┐
          ▼      ▼       ▼
        Email  Invoice  Analytics
                         │
                         ▼
                      Warehouse

The customer request completes once the critical transaction succeeds.

Other workloads can be processed asynchronously.

This improves resilience as well as database efficiency because temporary downstream problems do not necessarily block the primary transaction.

10. CQRS and Specialized Read Models

For systems with extremely different read and write requirements, Command Query Responsibility Segregation (CQRS) takes this idea further.

Instead of forcing one data model to serve every use case:

                Application
                     │
              ┌──────┴──────┐
              ▼             ▼
           Commands       Queries
              │             │
              ▼             ▼
         Write Model     Read Model

The write model can be optimized for transactional correctness.

The read model can be shaped around how users actually query the data.

For example:

Order Service
     │
     ├── Write → Relational Database
     │
     └── Read  → Optimized Read Model

The read model might use a relational replica, cache, search engine, or another specialized datastore depending on the requirements.

CQRS is powerful, but it also introduces synchronization and consistency concerns.

It should therefore solve a demonstrated workload problem rather than become architectural decoration.

11. Kubernetes Doesn't Automatically Solve Database Scaling

This distinction is especially important in cloud-native environments.

Kubernetes makes it easy to scale stateless services:

Deployment
    │
    ├── Pod
    ├── Pod
    ├── Pod
    └── Pod

But databases have state.

They require careful handling of:

persistent storage
replication
failover
consistency
backups
recovery
leader election
data distribution

Adding more application pods can actually increase database pressure:

             10 API Pods
                  │
                  ▼
             Database
                  ▲
                  │
             50 API Pods

If the database is already saturated, scaling the application from 10 to 50 pods may simply create more concurrent database requests.

Autoscaling the application does not automatically mean the data layer can scale with it.

12. Capacity Planning: Know When the Architecture Will Break

Database scaling should ideally happen before an outage forces the decision.

Suppose current capacity is:

20,000 queries/sec

and traffic grows by 20% per year.

Without intervention, the system eventually approaches its capacity ceiling:

Queries/sec

40k |                         /
35k |                       /
30k |                    /
25k |                 /
20k |--------------/---------- Capacity
15k |           /
10k |       /
 5k |    /
    +----------------------------
       Time →

Capacity planning combines:

historical traffic
expected growth
seasonal peaks
business projections
resource utilization
query volume
storage growth

The goal isn't to predict the exact future.

It is to identify architectural limits early enough to act before the system reaches them.

13. Protect the Database With SLOs

Database performance should ultimately be connected to user-facing objectives.

Instead of:

"The database should be fast."

define measurable targets.

For example:

Order API

Availability       99.95%
P95 latency        < 300 ms
P99 latency        < 800 ms
Replication lag    < 5 sec

These targets provide a basis for evaluating architectural changes.

If a new cache reduces database CPU but causes unacceptable stale data, the trade-off becomes visible.

If read replicas increase throughput but replication lag violates the application's consistency requirements, that matters too.

Scaling decisions should therefore be driven by service requirements, not infrastructure metrics alone.

14. Backups and Recovery Are Part of Scaling

A highly available database is not automatically a recoverable database.

A production data strategy should account for:

                    Database
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Backups       Replicas      Archive
          │            │            │
          ▼            ▼            ▼
      Recovery       Failover    Retention

Important considerations include:

Recovery Point Objective (RPO)
Recovery Time Objective (RTO)
automated backups
point-in-time recovery
replication
failover
restore testing

A backup strategy should be tested regularly.

A backup that cannot be restored when needed is not a reliable disaster-recovery mechanism.

15. A Practical Scaling Path

There is no universal sequence for every system, but a useful decision model is:

                  Database Problem
                         │
                         ▼
                  Measure the Cause
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
        Query / Workload       Capacity Limit
             │                       │
             ▼                       ▼
        Optimize Work            Add Capacity
             │                       │
      ┌──────┼──────┐          ┌─────┼─────┐
      ▼      ▼      ▼          ▼     ▼     ▼
   Index   Cache   Pool      Replicas Partition Sharding
      │      │      │
      └──────┴──────┘
             │
             ▼
       Re-measure
             │
             ▼
      Still insufficient?
             │
             ▼
      Re-architect workload

The important part is the feedback loop:

Measure
   ↓
Change
   ↓
Observe
   ↓
Measure again

Each architectural change should have a measurable reason behind it.

16. The Mature Data Architecture

A large production system may eventually look like this:

                           Users
                             │
                             ▼
                       ┌───────────┐
                       │ API Layer │
                       └─────┬─────┘
                             │
             ┌───────────────┼────────────────┐
             │               │                │
             ▼               ▼                ▼
          Cache           Search            Queue
             │               │                │
             │               │                ▼
             │               │             Workers
             │               │                │
             │               │                ▼
             │               │             Database
             │               │                │
             │               │        ┌───────┼───────┐
             │               │        ▼       ▼       ▼
             │               │     Replica Replica Replica
             │               │
             │               └── Specialized search
             │
             └── Frequently accessed data

Behind the scenes:

                   Primary Database
                          │
                 ┌────────┴────────┐
                 ▼                 ▼
                CDC              Backup
                 │                 │
                 ▼                 ▼
          Analytics Platform    Object Storage

Each component has a specific responsibility.

The transactional database is no longer expected to handle every type of workload.

17. The Real Lesson

Database scaling is not simply a matter of buying a larger machine.

It is about understanding where the work is coming from and deciding which work should happen where.

A useful progression is:

Understand
    ↓
Optimize
    ↓
Control
    ↓
Cache
    ↓
Replicate
    ↓
Separate
    ↓
Partition
    ↓
Shard

But this is not a checklist where every system must eventually reach the final step.

A small system may only need good indexes and connection pooling.

A read-heavy application may benefit greatly from replicas and caching.

A large analytics platform may need to separate transactional and analytical workloads.

A globally distributed platform may eventually require sharding or a distributed database.

The correct architecture depends on the workload.

Conclusion

When an application grows, the database often becomes the hidden constraint behind everything else.

The API can scale.

Kubernetes can scale.

Load balancers can scale.

But if every request ultimately depends on a database that cannot keep up, the entire system eventually reaches the same wall.

The solution is not to immediately introduce more databases.

It is to progressively remove unnecessary work, control concurrency, cache repeated reads, distribute appropriate workloads, and only introduce more complex data architectures when the measurements justify them.

The most important progression is therefore:

measure → optimize → isolate → distribute → scale.

And throughout the process, keep asking one question:

What work is the database doing that it doesn't actually need to do?

That question often leads to a simpler and more scalable architecture than simply throwing more hardware at the problem.

At scale, database performance is no longer just a database concern.

It becomes an architecture, reliability, and workload-management problem.

Spooky Haunted House: CSS & JS Halloween Art

Gilbert Ngeno — Wed, 29 Oct 2025 11:06:47 +0000

This is a submission for Frontend Challenge - Halloween Edition, CSS Art.

Inspiration

I was inspired by classic haunted house scenes from Halloween movies and stories. My CSS art features a spooky haunted house, glowing moon, flickering windows, bats, ghosts, zombies, pumpkins, and interactive elements like thunder, fog, and falling leaves—all designed to evoke the playful yet eerie spirit of Halloween night.

Demo

You can view the live demo here:
Halloween Haunted House Demo

Github repo

Journey

This project was a fun exploration of CSS art and interactive frontend features. I learned how to combine CSS animations with JavaScript to create dynamic effects, such as flickering lights, moving zombies, and sound triggers for thunder, witch cackles, and more.
I’m proud of the way the scene comes alive with user interaction—hovering, clicking, and toggling music and themes. Next, I’d like to add more accessibility features and polish the mobile responsiveness.

If you’d like to use or remix this, feel free—credit me!

Part 2: Deploying Your FastAPI and React.js CRUD App on Render.com

Gilbert Ngeno — Wed, 03 Sep 2025 21:10:47 +0000

In Part 1, we built a full-stack CRUD (Create, Read, Update, Delete) application using FastAPI for the backend and React.js for the frontend. Now, let’s make it live on Render.com, a free and beginner-friendly platform!
This guide will walk you through deploying the FastAPI backend as a Web Service and the React frontend as a Static Site.
We’ll also fix common errors (like CORS and import issues) and share best practices to ensure a smooth deployment.

This article is for absolute beginners. We assume you’ve completed the tutorial, have your project in a Git repository (e.g., GitHub), and are ready to deploy.
Don’t worry—we’ll explain every step clearly!

Prerequisites
Before starting, ensure you have:

A Render.com account (sign up at render.com).
Your project pushed to a Git repository (GitHub, GitLab, or Bitbucket). Your project structure should look like:

my-crud-app/
├── backend/
│   ├── main.py
│   ├── models.py
│   ├── schemas.py
│   ├── database.py
│   ├── requirements.txt
├── frontend/
│   ├── src/
│   │   ├── App.js
│   │   ├── App.css
│   ├── package.json
│   ├── public/

Basic Git commands (e.g., git add, git commit, git push).
The backend dependencies listed in requirements.txt (see below).

If you don’t have requirements.txt, create it in backend:

cd backend
pip install fastapi uvicorn sqlalchemy databases aiosqlite python-dotenv
pip freeze > requirements.txt

This generates a file like:

fastapi==0.111.1
uvicorn==0.30.6
sqlalchemy==2.0.31
databases==0.9.0
aiosqlite==0.20.0
python-dotenv==1.0.1

Step 1: Deploy the FastAPI Backend as a Web Service
The backend is the server that handles CRUD operations (e.g., storing items in a database).
Render’s Web Service runs your FastAPI app.
1.1 Prepare the Backend

1. Fix Imports in main.py:
The tutorial uses relative imports (from . import models, schemas, database), which can cause errors on Render like “ImportError: attempted relative import with no known parent package.” You have two options to fix this:
Option 1: Use Absolute Imports with backend:
Change the import line in backend/main.py:

from backend import models, schemas, database

This assumes backend/ is your module name.

Option 2: Use init.py for Package Structure:
Create an empty init.py file in backend/ to make it a Python package:bash

cd backend
touch __init__.py  # macOS/Linux (or echo. > __init__.py on Windows)

Keep the relative import in main.py:python

from . import models, schemas, database

Add an environment variable in Render (see Step 1.2) to set PYTHONPATH.

Recommendation: Use Option 1 (absolute imports) for simplicity—it works without extra files or environment variables.
If you prefer Option 2, we’ll configure it below.

Commit changes:


cd backend
git add main.py  # And __init__.py if using Option 2
git commit -m "Fix imports for deployment"
git push origin main

Verify requirements.txt:
Confirm it includes all dependencies (listed above). If missing, regenerate:


cd backend
source venv/bin/activate  # macOS/Linux (or .\venv\Scripts\activate on Windows)
pip freeze > requirements.txt
git add requirements.txt
git commit -m "Add requirements.txt"
git push origin main

Test Locally:
Run the backend:


uvicorn main:app --host 0.0.0.0 --port 8000

Visit http://localhost:8000/docs to see the FastAPI Swagger UI.
Test POST /items/ with a sample item: {"name": "Test", "description": "Test item"}. If using Option 2, set:


export PYTHONPATH=$PWD  # macOS/Linux (or set PYTHONPATH=%CD% on Windows)

1.2 Deploy on Render

(1). Create a Web Service:

Log in to Render.com
Click New > Web Service.
Connect your Git repository (containing backend/ and frontend/).
Set Root Directory to backend/ (if in a monorepo).

(2). Configure Settings:

Name: e.g., my-crud-api.
Environment: Python 3.
Branch: main.
**Build **Command: pip install -r requirements.txt.
Start Command:
For Option 1 (absolute imports): uvicorn main:app --host 0.0.0.0 --port $PORT.
For Option 2 (init.py): uvicorn backend.main:app --host 0.0.0.0 --port $PORT.
Instance Type: Free.
Environment Variables (for Option 2 only): Key: PYTHONPATH Value: /opt/render/project/src/backend
If using a database other than SQLite, add **DATABASE_URL **later (Step 4).

Deploy:

Click Create Web Service.
Check Logs for errors (e.g., missing dependencies or import issues).
Get the URL (e.g., https://my-crud-api.onrender.com).
Visit /docs to confirm the API is live.

Step 2: Deploy the React Frontend as a Static Site
The frontend is your React app, served as static files after building. Render’s Static Site hosting is ideal.

2.1 Prepare the Frontend

Update API Base URL:
In frontend/src/App.js, use an environment variable to avoid hardcoding the backend URL:


const API_BASE = (process.env.REACT_APP_API_URL || 'http://localhost:8000').replace(/\/+$/, '');

The .replace(/\/+$/, '') prevents double slashes (e.g., //items/).
Update Axios calls to use /items (no trailing slash):javascript

const response = await axios.get(`${API_BASE}/items`);
const response = await axios.post(`${API_BASE}/items`, { name, description });

Commit:


cd frontend
git add src/App.js
git commit -m "Update API base URL"
git push origin main

Test Locally:


cd frontend
export REACT_APP_API_URL=https://my-crud-api.onrender.com  # Your backend URL
npm install
npm start

Open http://localhost:3000, create an item, and check the Network tab (F12) to ensure requests go to https://my-crud-api.onrender.com/items.

2.2 Deploy on Render

Create a Static Site:

In the same Render project, click New > Static Site.
Connect the same Git repository.
Set Root Directory to ** frontend/.**

Configure Settings:

Name: e.g., my-crud-frontend.
Branch: main.
Build Command: npm install && npm run build.
Publish Directory: build.
Environment Variables: Key: REACT_APP_API_URL Value: https://my-crud-api.onrender.com (no trailing slash).

Deploy:

Click Create Static Site.
Check build logs for errors (e.g., missing react-scripts in package.json).
Get the URL (e.g., https://my-crud-frontend.onrender.com).

Step 3: Fix CORS for Frontend-Backend Communication
Since the frontend and backend are on different domains, the backend must allow the frontend’s domain via CORS.

(1).
Update main.py:
In backend/main.py, add the frontend URL to CORS:


app.add_middleware(
    CORSMiddleware,
    allow_origins=[
        "http://localhost:3000",
        "https://my-crud-frontend.onrender.com"  # Your frontend URL
    ],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

(2).
Redeploy Backend:


cd backend
git add main.py
git commit -m "Add frontend URL to CORS"
git push origin main

Redeploy in Render if auto-deploy is off.

(3).
Test CORS:
Visit https://my-crud-frontend.onrender.com.
In Developer Tools (F12) > Network tab, check that POST /items succeeds (201 Created).

Step 4: Handle Database Persistence
The tutorial uses SQLite, which loses data on Render due to its ephemeral filesystem. Use Render’s PostgreSQL for production.

(1). Create a PostgreSQL Database:
In Render, click New > PostgreSQL.
Set a name (e.g., my-crud-db) and create.
Copy the Internal Database URL from the Info tab.

(2). Update Backend:
In backend/database.py:


from sqlalchemy import create_engine
import os
DATABASE_URL = os.getenv("DATABASE_URL", "sqlite:///./sql_app.db")
engine = create_engine(DATABASE_URL)

Add to requirements.txt:

psycopg2-binary==2.9.9

In Render Web Service, add:

Key: DATABASE_URL
Value:

Redeploy backend.

Resolving Common Errors
Here are beginner-friendly fixes for issues you might face.

Error 1: CORS Policy Blocks Requests

Symptoms: Browser console shows: “Access to XMLHttpRequest at ‘https://my-crud-api.onrender.com/items’ from origin ‘https://my-crud-frontend.onrender.com’ has been blocked by CORS policy.”

Fix:

Add the frontend URL to allow_origins in main.py.
Test with allow_origins=["*"] temporarily, then revert to specific domains.
Redeploy backend and check Network tab.

Error 2: Double Slash in URL (e.g., //items/)

Symptoms: Requests fail with 404 due to https://my-crud-api.onrender.com//items/.
Fix:Ensure App.js strips trailing slashes:javascript

const API_BASE = (process.env.REACT_APP_API_URL || 'http://localhost:8000').replace(/\/+$/, '');

Set REACT_APP_API_URL without a trailing slash in Render.
Redeploy frontend.

Error 3: Backend Import Error
Symptoms: Render logs show “ImportError: attempted relative import with no known parent package.”
Fix:
Use

Option 1: Change to from backend import models, schemas, database. Or
Option 2: Add init.py to backend/ and set PYTHONPATH=/opt/render/project/src/backend in Render.
Redeploy backend.

Error 4: Data Resets on Redeploy
Symptoms: Items disappear after redeploying.
Fix: Use PostgreSQL (Step 4) instead of SQLite.

Error 5: Slow Backend Response

Symptoms: First request takes 10-30 seconds.
Fix: Normal for Render’s free tier. Upgrade to paid (~$7/month) for always-on, or warn users of delays.

Best Practices for Beginners
(1). Use Environment Variables:

Store URLs (e.g., REACT_APP_API_URL) in Render’s environment variables.

(2). Test Locally:

Run backend (uvicorn main:app) and frontend (npm start) with deployed URLs.
Check Network tab (F12) for errors.

(3). Check Logs:
Use Render’s Logs tab to debug build or runtime issues.

(4). Validate Inputs:
Prevent empty form submissions:


const createItem = async () => {
  if (!name || !description) {
    alert('Name and description are required');
    return;
  }
  // ... Axios POST
};

(5). Version Control:
Commit with clear messages: git commit -m "Fix CORS".

(6). Secure CORS:
Only allow specific origins (not ["*"]) in production.

(7). Monitor Performance:

Consider paid tiers for faster responses.

Testing Your Deployed App

Visit https://my-crud-frontend.onrender.com.
Test CRUD operations:Create, read, update, delete items.
Check Network tab (F12) for request success (200/201 status).
Debug errors using Render logs and browser console.

Congratulations!Your full-stack CRUD app is live on Render! You’ve deployed the FastAPI backend and React frontend, fixed common issues, and learned best practices. Share your app’s URL and explore adding features like custom domains or user authentication.

If you need help, check Render’s docs or comment below. Happy deploying!

Part 1: Building Your First Full-Stack CRUD App with FastAPI and React.js

Gilbert Ngeno — Wed, 03 Sep 2025 09:01:21 +0000

A Beginner's Guide to Creating, Connecting, and Deploying a Web Application
Have you ever wondered how web applications work behind the scenes? How data gets created, displayed, updated, and deleted? In this tutorial, I'll guide you through building a complete CRUD (Create, Read, Update, Delete) application using FastAPI for the backend and React.js for the frontend. We'll even deploy it to the internet so you can share it with others!

What You'll Build
You'll create a simple item management system where you can:

Add new items with names and descriptions
View all items in a list
Edit existing items
Delete items you no longer need

Prerequisites
Before we start, make sure you have:

Basic knowledge of Python and JavaScript
Python 3.7+ installed on your computer
Node.js and npm installed
A text editor (VS Code recommended)

Part 1: Setting Up the Backend with FastAPI
FastAPI is a modern, fast web framework for building APIs with Python. It's perfect for beginners because it provides automatic interactive documentation.

Step-by-Step Backend Setup

Create Project Structure

Open your terminal and run these commands:

# Create a main project directory
mkdir crud-app
# Move into the directory
cd crud-app
# Create a virtual environment (isolated Python environment)
python -m venv venv

Explanation:

mkdir creates a new directory/folder

cd changes your current directory

python -m venv venv creates a virtual environment named "venv" that keeps your project's dependencies separate from other Python projects

Activate Virtual Environment

# On macOS/Linux:
source venv/bin/activate
# On Windows:
venv\Scripts\activate

Explanation:
Activating the virtual environment ensures that any packages we install are only available for this specific project. You'll know it's activated when you see (venv) at the beginning of your terminal prompt.

Install Required Packages

pip install fastapi uvicorn sqlalchemy aiosqlite

Explanation:

fastapi: The main web framework

uvicorn: A server that will run our FastAPI application

sqlalchemy: A database toolkit that helps us work with databases

aiosqlite: Allows async database operations with SQLite

Create Backend Files

Create a backend directory and these files inside it:

crud-app/
├── backend/
│   ├── main.py
│   ├── database.py
│   ├── models.py
│   └── schemas.py

Set Up the Database (database.py)

from sqlalchemy import create_engine
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker

# Database URL for SQLite (it will create a file called test.db)
SQLALCHEMY_DATABASE_URL = "sqlite:///./test.db"

# Create the database engine
engine = create_engine(
    SQLALCHEMY_DATABASE_URL, connect_args={"check_same_thread": False}
)

# Create a SessionLocal class for database sessions
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)

# Create a Base class for our models
Base = declarative_base()

Explanation:

We're using SQLite, a simple file-based database, for simplicity

The engine is responsible for connecting to the database

SessionLocal will be used to create database sessions

Base is a class that our models will inherit from

Create the Item Model (models.py)

from sqlalchemy import Column, Integer, String
from database import Base

class Item(Base):
    __tablename__ = "items"

    id = Column(Integer, primary_key=True, index=True)
    name = Column(String, index=True)
    description = Column(String, index=True)

Explanation:

We're creating a table called "items" with three columns

id is our primary key (unique identifier for each item)

name and description will store text data

index=True makes searching faster for these columns

Create Pydantic Schemas (schemas.py)

from pydantic import BaseModel

# Base schema with common attributes
class ItemBase(BaseModel):
    name: str
    description: str = None

# Schema for creating a new item
class ItemCreate(ItemBase):
    pass

# Schema for reading/returning an item (includes id)
class Item(ItemBase):
    id: int

    class Config:
        orm_mode = True

Explanation:

Schemas define the structure of our data when sending/receiving from the API

ItemCreate is used when creating a new item (doesn't need an ID yet)

Item is used when returning data (includes the ID)

orm_mode = True allows converting from database models to Pydantic models

Create the Main FastAPI App (main.py)

from fastapi import FastAPI, Depends, HTTPException
from sqlalchemy.orm import Session
import models, schemas
from database import SessionLocal, engine
from fastapi.middleware.cors import CORSMiddleware

# Create all tables in the database
models.Base.metadata.create_all(bind=engine)

# Create the FastAPI application
app = FastAPI()

# Add CORS middleware to allow React frontend to connect
app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:3000"],  # React's default port
    allow_credentials=True,
    allow_methods=["*"],  # Allow all HTTP methods
    allow_headers=["*"],  # Allow all headers
)

# Dependency to get database session
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

# CREATE - Add a new item
@app.post("/items/", response_model=schemas.Item)
def create_item(item: schemas.ItemCreate, db: Session = Depends(get_db)):
    db_item = models.Item(**item.dict())
    db.add(db_item)
    db.commit()
    db.refresh(db_item)
    return db_item

# READ - Get all items
@app.get("/items/", response_model=list[schemas.Item])
def read_items(skip: int = 0, limit: int = 100, db: Session = Depends(get_db)):
    items = db.query(models.Item).offset(skip).limit(limit).all()
    return items

# READ - Get a single item by ID
@app.get("/items/{item_id}", response_model=schemas.Item)
def read_item(item_id: int, db: Session = Depends(get_db)):
    item = db.query(models.Item).filter(models.Item.id == item_id).first()
    if item is None:
        raise HTTPException(status_code=404, detail="Item not found")
    return item

# UPDATE - Update an existing item
@app.put("/items/{item_id}", response_model=schemas.Item)
def update_item(item_id: int, item: schemas.ItemCreate, db: Session = Depends(get_db)):
    db_item = db.query(models.Item).filter(models.Item.id == item_id).first()
    if db_item is None:
        raise HTTPException(status_code=404, detail="Item not found")

    for field, value in item.dict().items():
        setattr(db_item, field, value)

    db.commit()
    db.refresh(db_item)
    return db_item

# DELETE - Remove an item
@app.delete("/items/{item_id}")
def delete_item(item_id: int, db: Session = Depends(get_db)):
    item = db.query(models.Item).filter(models.Item.id == item_id).first()
    if item is None:
        raise HTTPException(status_code=404, detail="Item not found")

    db.delete(item)
    db.commit()
    return {"message": "Item deleted successfully"}

Explanation:

We create endpoints for all CRUD operations (Create, Read, Update, Delete)

Each endpoint has a specific HTTP method (@app.post, @app.get, etc.)

The response_model parameter ensures our responses match the expected schema

Depends(get_db) provides a database session for each request

CORS middleware allows our React frontend to communicate with the backend

Run the Backend Server

cd backend
uvicorn main:app --reload

Explanation:

uvicorn is the server that runs our FastAPI application

main:app tells uvicorn to look for the app object in the main.py file

--reload enables automatic reloading when we make code changes

Your API is now running at http://localhost:8000! Visit http://localhost:8000/docs to see the interactive documentation automatically generated by FastAPI.

Part 2: Building the Frontend with React.js
React is a popular JavaScript library for building user interfaces. We'll create a simple interface to interact with our backend API.

Step-by-Step Frontend Setup

Create React App

From the project root directory, run:

# Create a new React application called "frontend"
npx create-react-app frontend
cd frontend

Explanation:

npx runs commands from npm packages without installing them globally

create-react-app is a tool that sets up a modern React application with all the necessary configuration

Install Axios for API Calls

npm install axios

Explanation:

Axios is a library that makes it easier to send HTTP requests to our backend API

React doesn't have built-in HTTP request capabilities, so we need a library like Axios

Replace the Contents of App.js

Open src/App.js and replace its contents with:

import React, { useState, useEffect } from 'react';
import axios from 'axios';
import './App.css';

// Base URL for our backend API
const API_BASE = "http://localhost:8000";

function App() {
  // State variables to manage our data
  const [items, setItems] = useState([]);
  const [name, setName] = useState('');
  const [description, setDescription] = useState('');
  const [editingId, setEditingId] = useState(null);

  // useEffect hook runs when the component mounts
  useEffect(() => {
    fetchItems();
  }, []);

  // Function to fetch all items from the backend
  const fetchItems = async () => {
    try {
      const response = await axios.get(`${API_BASE}/items/`);
      setItems(response.data);
    } catch (error) {
      console.error("Error fetching items:", error);
    }
  };

  // Function to create a new item
  const createItem = async () => {
    try {
      const response = await axios.post(`${API_BASE}/items/`, {
        name,
        description
      });
      setItems([...items, response.data]);
      setName('');
      setDescription('');
    } catch (error) {
      console.error("Error creating item:", error);
    }
  };

  // Function to update an existing item
  const updateItem = async () => {
    try {
      const response = await axios.put(`${API_BASE}/items/${editingId}`, {
        name,
        description
      });
      setItems(items.map(item => item.id === editingId ? response.data : item));
      setEditingId(null);
      setName('');
      setDescription('');
    } catch (error) {
      console.error("Error updating item:", error);
    }
  };

  // Function to delete an item
  const deleteItem = async (id) => {
    try {
      await axios.delete(`${API_BASE}/items/${id}`);
      setItems(items.filter(item => item.id !== id));
    } catch (error) {
      console.error("Error deleting item:", error);
    }
  };

  // Function to start editing an item
  const startEdit = (item) => {
    setEditingId(item.id);
    setName(item.name);
    setDescription(item.description);
  };

  // Function to cancel editing
  const cancelEdit = () => {
    setEditingId(null);
    setName('');
    setDescription('');
  };

  return (
    <div className="App">
      <h1>CRUD App with FastAPI and React</h1>

      <div className="item-form">
        <h2>{editingId ? 'Edit Item' : 'Add New Item'}</h2>
        <input
          type="text"
          placeholder="Name"
          value={name}
          onChange={(e) => setName(e.target.value)}
        />
        <input
          type="text"
          placeholder="Description"
          value={description}
          onChange={(e) => setDescription(e.target.value)}
        />
        {editingId ? (
          <>
            <button onClick={updateItem}>Update</button>
            <button onClick={cancelEdit}>Cancel</button>
          </>
        ) : (
          <button onClick={createItem}>Create</button>
        )}
      </div>

      <div className="items-list">
        <h2>Items</h2>
        {items.length === 0 ? (
          <p>No items found</p>
        ) : (
          <ul>
            {items.map(item => (
              <li key={item.id}>
                <h3>{item.name}</h3>
                <p>{item.description}</p>
                <button onClick={() => startEdit(item)}>Edit</button>
                <button onClick={() => deleteItem(item.id)}>Delete</button>
              </li>
            ))}
          </ul>
        )}
      </div>
    </div>
  );
}

export default App;

Explanation:

We use React hooks (useState, useEffect) to manage state and side effects

*API_BASE * points to our backend server

Each function makes an API call using Axios and updates the UI accordingly

The form changes between "Create" and "Edit" mode based on whether we're editing an existing item

Update the CSS (App.css)

Replace the contents of src/App.css with:

.App {
  text-align: center;
  padding: 20px;
  font-family: Arial, sans-serif;
}

.item-form {
  margin: 20px 0;
  padding: 20px;
  border: 1px solid #ccc;
  border-radius: 5px;
  max-width: 500px;
  margin-left: auto;
  margin-right: auto;
  background-color: #f9f9f9;
}

.item-form input {
  display: block;
  margin: 10px auto;
  padding: 10px;
  width: 80%;
  border: 1px solid #ddd;
  border-radius: 4px;
}

.item-form button {
  margin: 5px;
  padding: 10px 15px;
  border: none;
  border-radius: 4px;
  cursor: pointer;
  background-color: #4CAF50;
  color: white;
}

.item-form button:hover {
  background-color: #45a049;
}

.items-list ul {
  list-style-type: none;
  padding: 0;
  max-width: 600px;
  margin: 0 auto;
}

.items-list li {
  border: 1px solid #eee;
  margin: 10px 0;
  padding: 15px;
  border-radius: 5px;
  background-color: #fff;
  box-shadow: 0 2px 4px rgba(0,0,0,0.1);
}

.items-list button {
  margin: 0 5px;
  padding: 5px 10px;
  border: none;
  border-radius: 3px;
  cursor: pointer;
}

.items-list button:first-child {
  background-color: #2196F3;
  color: white;
}

.items-list button:last-child {
  background-color: #f44336;
  color: white;
}

.items-list button:hover {
  opacity: 0.8;
}

Run the React Application

npm start

Your React app will open at http://localhost:3000. You should now be able to add, view, edit, and delete items!

Part 3: Connecting Backend and Frontend
The magic happens through HTTP requests between the frontend and backend:

Frontend (React): Makes requests using Axios to specific URLs

Backend (FastAPI): Listens for these requests, processes them, and returns responses

Frontend (React): Updates the UI based on the responses

Key Connection Points:

API_BASE Constant: const API_BASE = "http://localhost:8000"; tells the frontend where to find the backend

CORS Middleware: The CORSMiddleware in FastAPI allows the frontend to make requests from a different domain (localhost:3000) to the backend (localhost:8000)

HTTP Methods:

axios.get() → @app.get() (Read)
axios.post() → @app.post() (Create)
axios.put() → @app.put() (Update)
axios.delete() → @app.delete() (Delete)

Data Flow:

User interacts with React UI
React sends HTTP request to FastAPI
FastAPI processes request (reads/writes to database)
FastAPI sends response back to React
React updates UI based on response

Part 4: Deploying to the Internet
Now let's make your application accessible to anyone on the internet! We'll use Heroku, a platform that makes deployment easy.

Backend Deployment

Install Heroku CLI

Download and install from heroku.com

heroku login

Create requirements.txt

cd backend
pip freeze > requirements.txt

Explanation: This file lists all Python packages needed for your application. Heroku uses it to install dependencies.

Create Procfile

Create a file named Procfile (no extension) in the backend directory with:

web: uvicorn main:app --host=0.0.0.0 --port=$PORT

Explanation: Tells Heroku how to start your application. The $PORT is provided by Heroku.

Initialize Git and Deploy

# Initialize git repository
git init
# Add all files to git
git add .
# Commit files
git commit -m "Initial commit"
# Create Heroku app
heroku create your-app-name-backend
# Deploy to Heroku
git push heroku main

Explanation:

Git is a version control system that Heroku uses to deploy your code

Replace your-app-name-backend with a unique name for your backend

Frontend Deployment

Create Production Build

cd frontend
npm run build

Explanation: Creates optimized production files in the build folder.

Install Serve Package

npm install -g serve

Explanation: serve is a simple static file server for production builds.

Create Procfile

Create a Procfile in the frontend directory with:

web: serve -s build

Explanation: Tells Heroku to serve the built React application.

Update API_BASE

Change the API_BASE in your React app to point to your deployed backend:

const API_BASE = "https://your-app-name-backend.herokuapp.com";

Deploy to Heroku

# Initialize git
git init
git add .
git commit -m "Initial commit"
# Create Heroku app
heroku create your-app-name-frontend
# Deploy
git push heroku main

Replace your-app-name-frontend with a unique name for your frontend.

Alternative: Deploy with Netlify (Easier for Frontend)
For the frontend, Netlify is often easier than Heroku:

Build your React app: npm run build

Drag and drop the build folder to netlify.com

Update API_BASE to point to your deployed backend

Best Practices for Beginners

Code Organization: Keep your backend and frontend in separate directories
Environment Variables: Use environment variables for configuration (like API URLs)
Error Handling: Always add try-catch blocks around API calls
Code Comments: Comment your code to explain complex logic
Version Control: Use Git regularly to track changes
Incremental Development: Build and test one feature at a time
Troubleshooting Common Issues
CORS Errors: Make sure your backend allows your frontend domain
API Connection Issues: Check if your backend is running and the URL is correct
Database Problems: For production, consider using PostgreSQL instead of SQLite
Build Failures: Check that all dependencies are correctly listed

Next Steps
Now that you have a working CRUD application, you can:

Add user authentication
Implement more complex data relationships
Add image upload functionality
Improve the UI with a CSS framework like Bootstrap or Material-UI
Add form validation

Congratulations! You've built and deployed a full-stack web application. The skills you've learned form the foundation of modern web development. Keep experimenting and building—the best way to learn is by doing!

Remember, every developer started where you are now. With practice and persistence, you'll continue to grow your skills and build even more amazing applications. Happy coding!

Animating the Modern Workspace with Pure CSS

Gilbert Ngeno — Sun, 27 Jul 2025 13:22:22 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, CSS Art: Office Culture.

Inspiration

When I think of modern office culture, I immediately picture the hybrid work environment we've all adapted to - that perfect blend of traditional office elements with the new reality of video calls and remote collaboration. I wanted to capture that "lived-in" feeling of a real workspace: the essential coffee that keeps us going, the satisfying click of a mechanical keyboard, the desk plant that makes us feel more human, and those ever-present sticky notes trying to keep our chaotic work lives organized.

The scene tells the story of someone mid-video call, surrounded by all the little details that make up our daily work ritual. It's both nostalgic for the classic office elements and contemporary with the video conferencing that's become central to how we work.

Demo

codesandbox.io

gilly7 / office-culture-css-art

An interactive and visually rich CSS art project that recreates a modern office desk scene using only HTML and CSS. This project demonstrates advanced CSS techniques, creative use of gradients, flexbox, grid, and keyframe animations to bring an office environment to life.

Office Culture CSS Art

An interactive and visually rich CSS art project that recreates a modern office desk scene using only HTML and CSS. This project demonstrates advanced CSS techniques, creative use of gradients, flexbox, grid, and keyframe animations to bring an office environment to life—no images or SVGs, just pure CSS and HTML.

Features

Fully CSS-based Art: All elements (desk, monitor, keyboard, coffee mug, plant, sticky notes, lamp, stress ball, papers, pen holder, and more) are created using HTML and styled with CSS.
Animated Details: Includes animated steam from the coffee mug, blinking avatars in a video call, pulsing mouse light, swaying plant leaves, flickering lamp, and more.
Responsive Layout: The scene is centered and adapts to different screen sizes for a pleasant viewing experience.
No Images or SVGs: 100% CSS and HTML—great for learning and inspiration.

Preview

Open index.html in your browser to view…

View on GitHub

Journey

This project was a deep dive into advanced CSS techniques. I started by sketching out the desk layout and then built each element layer by layer, focusing on creating depth through CSS transforms and perspective.

What I'm particularly proud of:

The 3D perspective effect - Using transform: perspective(1000px) rotateX(10deg) to give the entire scene depth
Complex layered animations - Multiple elements animating independently but harmoniously (steam rising, keys typing, leaves swaying)
Realistic materials - Achieving wood grain, metal surfaces, and liquid effects purely through CSS gradients
Attention to detail - From the glowing mouse sensor to the different colored pens, every element tells part of the office story

Technical challenges I overcame:

Coordinating multiple animation timelines to feel natural
Creating realistic steam effects using opacity and transform animations
Building a convincing video call interface with CSS grid
Achieving proper layering and depth with z-index management

What I learned:

CSS keyframes can create incredibly sophisticated animations when layered thoughtfully.
The power of CSS gradients for creating realistic textures and lighting.
How perspective and transform can turn flat CSS into dimensional art.

This piece captures not just what an office looks like, but what it feels like - the energy, the routine, the small moments that make up our work lives. It's a love letter to the spaces where we spend so much of our time, rendered entirely in the web's most fundamental styling language.

Next steps: I'd love to explore adding seasonal variations (holiday decorations, different lighting) or creating an interactive version where elements respond to user interaction while maintaining the pure CSS approach.

License: MIT - Feel free to use and modify!

TemplateSyntaxError: 'with' expected with atleast one variable assignment

Gilbert Ngeno — Sun, 28 May 2023 11:28:31 +0000

Mar 26 '16 Comments: 1 Answers: 1

I am trying to send the data of a meeting object from template to view via GET method. To give the attribute meeting.date a simpler alias i.e date I am using the with template tag. But it ends up with a TemplateSyntaxError.

urls.py

url(r'^meeting/$', meeting_display, name="meeting"),

views.py

def meeting_display(request):
    date

…

Open Full Question

How to reset Django admin password

Gilbert Ngeno — Sat, 29 Apr 2023 09:07:30 +0000

python manage.py createsuperuser will create another superuser, you will be able to log into admin and remember your username.

To give a normal user privileges, open a shell with python manage.py shell and try:

from django.contrib.auth.models import User user = User.objects.get(username='normaluser') user.is_superuser = True user.save()

Spring Framework Practice Questions [Free Sample Copy]

Gilbert Ngeno — Wed, 05 Oct 2022 07:53:59 +0000

Get a sample copy of Spring Framework Practice Questions for Spring developer and Spring Professional interviews. It contains the first chapter and TOC, which will give you a quick overview of what you will get in the full book.

If you like the sample copy and all the Java questions, you can buy the full book here on Gumroad.

You can also use my code friends20 to get a 20% discount for a limited time.

Click here to get your 20% Discount now - 20% OFF on Spring Framework Practice Questions

250+ Spring Framework Practice Questions

Gilbert Ngeno — Fri, 02 Sep 2022 06:29:35 +0000

If you are preparing for Spring Professional certification, a Java interview with Spring Boot skills, or just want to test your Spring Framework skills, then these Practice questions are perfect for you. There are 250+ Questions on different spring topics, which will test your knowledge in depth. Get it here

Answer: Error: Cannot find module '@vue/cli-service/generator/template/src/App.vue' with vite

Gilbert Ngeno — Thu, 23 Jun 2022 09:59:00 +0000

PowerShell says "execution of scripts is disabled on this system."

Gilbert Ngeno — Thu, 23 Jun 2022 07:52:29 +0000

https://stackoverflow.com/q/4037939/12174468

How fix Jmeter on a Mac ? Could not initialize class org.apache.jmeter.gui.util.FileDialoger

Gilbert Ngeno — Wed, 18 May 2022 09:14:38 +0000