DEV Community: Emidowojo

Building a Reliable Payment Tracker with Daya's API and AWS

Emidowojo — Sun, 21 Jun 2026 21:49:00 +0000

One thing I have learned from working around payment systems is that collecting money is usually the easy part.

The harder problem is knowing, with confidence, that the money arrived and that your system accounted for it correctly.

At first glance, the flow seems straightforward:

Generate payment details.
Give those details to a customer.
Wait for payment.
Update your records.

In reality, payment systems operate in a world of retries, network failures, duplicate events, and downstream services that occasionally decide today is not their day.

That was the problem I wanted to explore when I built this payment tracker.

Instead of focusing only on payment collection, I wanted to build something that could safely handle the full lifecycle of a payment event, from payment creation to reconciliation, while remaining reliable when parts of the system fail.

For payment collection, I used Daya. For reliability and operational infrastructure, I used AWS.

Daya provides the payment infrastructure: funding accounts, bank-transfer collection, crypto-address collection, and deposit webhook events. AWS provides the backbone that lets the application process those events reliably: webhook endpoints, queues, workers, durable storage, secrets management, monitoring, and alerts.

The result is a simple payment tracker that can:

Create NGN bank-transfer payment details.
Create crypto deposit addresses.
Receive and verify signed Daya webhooks.
Queue payment events before processing them.
Process Daya deposit events asynchronously.
Reconcile those events into application payment records.
Run entirely on AWS serverless infrastructure.

More importantly, it demonstrates a pattern that shows up in many real-world fintech systems: collect payment events quickly, process them safely, and ensure every payment is accounted for.

Live Demo

I deployed the application publicly so you can explore the flow yourself:

Live Application: http://bit.ly/3Qzpd7G

Source Code: https://github.com/Emidowojo/Daya-Payments-Tracker

The public deployment runs in a safe demonstration mode and showcases the payment lifecycle, webhook handling, event processing, and reconciliation workflow described throughout this article.

The Problem

Imagine a customer pays into your application.

What happens next?

Many first implementations look something like this:

Webhook arrives
↓
Process payment immediately
↓
Update database
↓
Return success

It works until something goes wrong.

What if:

Your database is temporarily unavailable?
A downstream API times out?
The webhook gets delivered twice?
Processing takes longer than the provider expects?

Now you're dealing with failed reconciliations, duplicate records, and support tickets.

The goal of this project was to avoid those problems from the beginning.

The Architecture

The architecture separates payment collection from payment processing.

Browser Payment Tracker
        |
        v
Lambda Function URL  <--------  Daya Webhook
        |
        v
Amazon SQS Queue
        |
        v
Worker Lambda
        |
        v
DynamoDB

Secrets Manager -> API Lambda and Worker Lambda

SQS Dead-Letter Queue -> CloudWatch Alarm

The core idea is simple:

The webhook endpoint should acknowledge events quickly.

Actual reconciliation happens later.

In this architecture, Daya is the source of payment events. AWS is the reliability layer that helps the application process those events safely.

Why Daya?

I chose Daya because this project needed a payment layer that could support both local currency and stablecoin collection through an API.

Daya Funding Accounts make that possible.

A funding account represents payment details a business can give to a customer to receive funds. Depending on the rail, that could be an NGN virtual account for bank-transfer collection or a crypto deposit address for stablecoin deposits.

For this project, Daya provides the collection infrastructure and deposit events that make reconciliation possible. The application then uses AWS to process those events safely and turn them into durable payment records.

For this implementation, I used:

Resource	Purpose
`NGN_VIRTUAL_ACCOUNT`	Bank-transfer collection
`CRYPTO_ADDRESS`	Stablecoin deposits
`deposit.completed`	Payment notification
`X-Daya-Signature`	Webhook verification

The flow begins by creating payment details through Daya.

Customers receive those payment details and make deposits through their preferred payment rail.

Once funds arrive, Daya emits a webhook event.

That event becomes the starting point for the application's reconciliation workflow.

Relevant Documentation

Creating Payment Details

The application supports both bank-transfer collection and crypto collection.

For bank transfers:

Create Funding Account
↓
NGN_VIRTUAL_ACCOUNT
↓
Receive account number
↓
Display to customer

For crypto deposits:

Create Funding Account
↓
CRYPTO_ADDRESS
↓
Receive deposit address
↓
Display to customer

At this stage, no money has moved yet.

The application is simply preparing a destination where funds can be received.

Receiving Webhooks

When a customer completes a payment, Daya sends a webhook event.

One mistake I see often is treating webhooks as workflows.

They are not.

Webhooks are notifications.

If there is one lesson I would carry into any payment integration, it is this:

Never make the webhook handler do too much.

The webhook endpoint should:

Verify authenticity.
Persist the event.
Return success.

Everything else can happen later.

For this project, the webhook handler follows this flow:

Receive webhook
↓
Verify X-Daya-Signature
↓
Push event to SQS
↓
Return HTTP 200

That's it.

No reconciliation.

No heavy database operations.

No external calls.

Just verification and persistence.

A simplified version of the webhook handler looks like this:

app.post("/webhooks/daya", async (request, response) => {
  const signature = request.header("X-Daya-Signature");
  const rawBody = JSON.stringify(request.body);

  const isValid = verifyDayaSignature(rawBody, signature, webhookSecret);

  if (!isValid) {
    return response.status(401).json({ error: "Invalid webhook signature" });
  }

  await queue.send({
    id: request.body.id,
    type: request.body.type,
    payload: request.body,
  });

  return response.status(200).json({ received: true });
});

In the real application, the queue is backed by Amazon SQS in AWS and by a local queue during development.

Why Queue the Webhook?

Once a webhook has been verified, the event is pushed into Amazon SQS.

This provides several benefits.

Faster Responses

Webhook providers expect a quick response.

The API no longer waits for reconciliation logic to finish.

Retryability

If processing fails, SQS can retry automatically.

Failure Isolation

A temporary database issue should not cause webhook delivery failures.

Traffic Buffering

Large bursts of payment activity can be absorbed without overwhelming workers.

Dead-Letter Queues

Failed events can be isolated and investigated later.

The queue acts as a safety layer between incoming payment events and business logic.

Processing Payments Safely

A worker Lambda consumes events from SQS.

This is where the application reconciliation happens.

SQS Event
↓
Validate payload
↓
Check idempotency
↓
Store payment record
↓
Mark event processed

The worker becomes responsible for turning Daya payment notifications into durable application records.

This separation makes the system significantly easier to reason about.

Handling Duplicate Events

Payment systems should assume every event can arrive more than once.

Not because something is broken.

Because retries are a feature of reliable systems.

To avoid duplicate processing, the worker stores processed webhook IDs.

Before handling an event, it checks whether that ID already exists.

Webhook Event
↓
Has event been processed?
 ├─ Yes → Skip
 └─ No → Process

This property is known as idempotency.

Without it, duplicate webhook deliveries could create duplicate payment records.

With it, the same event can safely be delivered multiple times.

That is the difference between:

"We received a webhook"

and

"We safely reconciled a payment."

Storing Payment State

DynamoDB serves as the application's reconciliation store, not as a replacement for Daya's payment records.

The application stores:

Funding accounts
Payment records
Processed webhook IDs

Having a dedicated record of processed events makes idempotent processing straightforward.

It also provides a clear audit trail when troubleshooting payment issues.

Managing Secrets

Payment systems inevitably require credentials.

For this build, I used AWS Secrets Manager to store:

Daya API keys
Daya webhook secrets

Neither the application code nor deployment artifacts contain sensitive values.

Both the API Lambda and worker Lambda retrieve secrets at runtime.

Monitoring and Operations

Reliable systems need visibility.

CloudWatch provides:

Application logs
Worker logs
Error tracking
Dead-letter queue alarms

If events begin accumulating in the dead-letter queue, CloudWatch can raise an alert so operators know reconciliation requires attention.

This is one of those operational details that rarely appears in architecture diagrams but becomes invaluable in production.

Deployment

The project is deployed using AWS CDK and a serverless architecture built around Lambda, SQS, DynamoDB, Secrets Manager, and CloudWatch.

The deployment process provisions:

Application endpoints
Webhook endpoints
Event queues
Dead-letter queues
DynamoDB tables
Secrets storage
Monitoring resources

One of the goals of the project was to demonstrate that reliable payment processing does not require managing servers. By combining event-driven AWS services, the operational burden remains low while reliability remains high.

What About Containers?

Because I am also active in the AWS Containers community, I included an ECS Fargate deployment path in the project as well.

Functionally, both deployments achieve the same outcome.

The difference is operational.

The serverless version is cheaper and simpler to maintain.

The ECS version provides a stronger container-focused architecture and may fit teams already standardizing on containers.

For educational projects, I would start with serverless and treat the container deployment as an advanced follow-up.

Lessons Learned

Building this project reinforced a few lessons that apply far beyond this payment tracker.

1. Webhook Handlers Should Be Boring

When I first started working with event-driven systems, I was tempted to do all the work inside the webhook handler.

That approach works until something downstream becomes unavailable.

The more responsibility a webhook endpoint has, the more opportunities it has to fail.

In this project, the webhook handler has one job:

Verify the request.
Persist the event.
Return success.

Everything else happens asynchronously.

Keeping the handler simple makes the system more reliable and easier to troubleshoot.

2. Queues Are an Investment in Reliability

It's easy to look at SQS and think it adds complexity.

In reality, it removes complexity from the parts of the system that matter most.

The queue absorbs traffic spikes, handles retries, and creates a buffer between incoming payment events and business logic.

Without the queue, every temporary downstream failure becomes a payment-processing problem.

With the queue, failures become manageable.

3. Idempotency Is Not Optional

One of the most important lessons in payment systems is that duplicate events are normal.

Providers retry webhooks.

Networks fail.

Clients reconnect.

The question is not whether duplicates will happen.

The question is whether your system can handle them safely.

Designing for idempotency from the start is much easier than trying to retrofit it later.

4. Reliability Is an Architecture Decision

Reliable systems are rarely the result of a single service or framework.

Reliability comes from the choices made between components.

The queue, the worker, the dead-letter queue, the monitoring, and the idempotency checks all contribute to a system that can recover gracefully when things go wrong.

5. Observability Matters More Than Expected

One thing that became clear while building this project is that debugging payment systems without visibility is frustrating.

Logs, metrics, and alerts are not features users see, but they are often the difference between quickly resolving an issue and spending hours trying to understand what happened.

CloudWatch ended up being just as important as the business logic itself because it provided confidence that payment events were flowing through the system correctly.

Before Production

Before adapting this pattern for a real customer-facing product, I would recommend adding:

Authentication and authorization
Custom domains and TLS management
Structured tracing
CI/CD pipelines
Alarm notifications
Production reconciliation queries
Rate limiting
Audit logging
Separation of testing and production environments

The architecture is intentionally simple, but the reliability patterns scale well beyond this example.

Final Thoughts

Building payment systems taught me that reliability rarely comes from a single API call.

It comes from the decisions made around that call.

How events are received.

How failures are handled.

How retries are processed.

How operators gain confidence that the system reflects reality.

Daya makes it possible to create payment destinations and receive deposit events.

AWS helps the application process those events reliably and reconcile them into its own records.

Together, they provide a practical blueprint for building payment systems that users and operators can trust.

Building a Student REST API with Flask and Docker

Emidowojo — Wed, 16 Apr 2025 22:46:57 +0000

Hey there! I recently built a REST API to manage student records using Flask, Flask-SQLAlchemy, and SQLite, and shared it in my last post. Now, I have taken it to the next level by containerizing it with Docker, making it portable and consistent across machines.

In this post, I will walk you through how I Dockerized my API, including the mistakes I made and how I fixed them, so you can follow along or avoid my pitfalls.

Why Docker?

Docker packages your app with its dependencies into a container, ensuring it runs the same everywhere, your laptop, a server, or the cloud. For my Student API, this meant no more “it works on my machine” excuses.

Let’s dive into the steps I took, bugs and all.

Step 1: Writing the Dockerfile

I started by creating a Dockerfile in my project folder (student-api-new/) to define how to build the Docker image. I used a multi-stage build to keep the image small: one stage for installing dependencies, another for running the app.

Stage 1: Build dependencies

# Use the slim version of Python 3.13 as base image
FROM python:3.13-slim AS builder

# Set working directory in the container
WORKDIR /app

# Update package list
RUN apt-get update

# Install build tools like gcc, then clean up
RUN apt-get install -y --no-install-recommends gcc && \
    apt-get autoremove -y && \
    rm -rf /var/lib/apt/lists/*

# Copy the requirements file into the container
COPY requirements.txt .

# Install required Python packages without caching
RUN pip install --no-cache-dir -r requirements.txt

# Install Gunicorn explicitly for running the app
RUN pip install --no-cache-dir gunicorn==23.0.0

Stage 2: Runtime image

# Start again from a clean slim Python image
FROM python:3.13-slim

# Set working directory again for final image
WORKDIR /app

# Copy installed Python packages from the builder stage
COPY --from=builder /usr/local/lib/python3.13/site-packages /usr/local/lib/python3.13/site-packages

# Copy Gunicorn from builder stage
COPY --from=builder /usr/local/bin/gunicorn /usr/local/bin/gunicorn

# Copy your actual Flask app code
COPY app/ ./app/

# Create non-root user for better security
RUN useradd -m appuser && chown -R appuser:appuser /app

# Switch to the new user
USER appuser

# Expose the port the app runs on
EXPOSE 5000

# Set the Flask app environment variable
ENV FLASK_APP=app

# Command to run the Flask app with Gunicorn
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:create_app()"]

What I Learned

Multi-Stage Builds: The builder stage handles heavy lifting (like installing gcc), but the final image only includes essentials, keeping it around 235MB.
Slim Base Image: python:3.13-slim is lighter than the full Python image.
Non-Root User: Using appuser improves security for production.

Step 2: Adding a `.dockerignore`

To reduce the image size, I created a .dockerignore file to exclude unnecessary files, like my virtual environment and test folder:

.venv/
.env
__pycache__/
*.pyc
students.db
.git/
.gitignore
tests/
README.md
Makefile

This ensured only the app code and dependencies went into the container, saving space.

Step 3: Building the Docker Image

I built the image with a semantic version tag (avoiding latest, which I learned is a no-no for reproducibility):

# Build the Docker image and tag it
docker build -t student-api:1.0.0 .

Step 4: Running the Container

To run the API, I used a command that maps port 5000 and loads environment variables from a .env file:

# Run the container in detached mode and pass in environment variables
docker run -d -p 5000:5000 --env-file .env student-api:1.0.0

Contents of my .env file:

FLASK_ENV=development
DATABASE_URL=sqlite:///students.db
SECRET_KEY=mysecretkey

Step 5: Testing the API

With the container running, I tested it using curl:

# Check if the API is healthy
curl http://localhost:5000/api/v1/healthcheck

Output:

## Output: {"status":"healthy"}

# Add a student record
curl -X POST http://localhost:5000/api/v1/students \
-H "Content-Type: application/json" \
-d '{"name": "Alice", "age": 20}'

Output:

{"id":1,"name":"Alice","age":20}

Seeing those responses felt like such a huge win considering all the errors I encountered 🥲 My API was finally alive in Docker.

Step 6: Updating Documentation

I updated my README.md to include Docker instructions, so anyone could try it.

Setup (Docker)

Prerequisites

Docker installed (docker --version)

Build the Image

make docker-build

Run the Container

make docker-run

I also added Makefile targets to simplify things:

# Makefile for building and running Docker image

docker-build:
    docker build -t student-api:1.0.0 .

docker-run:
    docker run -d -p 5000:5000 --env-file .env student-api:1.0.0

What I Learned: Good docs make your project accessible. The Makefile was a lifesaver for quick commands.

Step 7: Committing to GitHub

I wanted to share my Docker setup on GitHub, so I committed the Dockerfile and other files:

# Add Docker setup files to Git
git add Dockerfile .gitignore

# Commit with message
git commit -m "Add Docker setup for Student API"

# Push to GitHub
git push origin main

Errors I Ran Into (and How I Fixed Them)

1. Slow Build Time (17+ Minutes)

Error:

[+] Building 1050.2s (8/12)
=> [builder 4/4] RUN apt-get update && apt-get install ... 970.8s

Why: My internet connection was slow, which bogged down apt-get.

Fix:

# Check network speed
curl -o /dev/null http://deb.debian.org/debian/dists/bookworm/InRelease

# Clear Docker build cache
docker builder prune

Also split apt-get update into a separate RUN to cache it better. My build time dropped to ~1–2 minutes afterwards.

2. Gunicorn Not Found

Error:

docker: Error response from daemon: ... exec: "gunicorn": executable file not found in $PATH

Why: I forgot to add gunicorn to requirements.txt, and didn’t rebuild properly.

Fix:

# requirements.txt
Flask==3.1.0
Flask-SQLAlchemy==3.1.1
gunicorn==23.0.0

Then in Dockerfile:

RUN pip install --no-cache-dir gunicorn==23.0.0
COPY --from=builder /usr/local/bin/gunicorn /usr/local/bin/gunicorn

Rebuild clean:

docker build --no-cache -t student-api:1.0.0 .

3. Container Conflict When Rebuilding

Error:

Error response from daemon: conflict: unable to delete student-api:1.0.0 ... container 25ae709a77aa is using it

Fix:

# List all containers (even stopped)
docker ps -a

# Remove the stopped container
docker rm 25ae709a77aa

# Remove the image
docker rmi student-api:1.0.0

4. Git Ignoring Dockerfile

Error:

The following paths are ignored by one of your .gitignore files: Dockerfile

Fix: Removed Dockerfile* from .gitignore:

.venv/
.env
__pycache__/
*.pyc
students.db
.git/
.gitignore
tests/
docker-compose*
*.dockerignore

Then committed successfully.

5. VS Code Warning About Gunicorn

Error:

Package gunicorn is not installed in the selected environment

Why: I hadn't installed gunicorn in my local .venv/.

Fix:

# Activate virtual environment
source .venv/bin/activate

# Install dependencies locally
pip install -r requirements.txt

What I Learned Overall

These errors taught me to:

Rebuild Images: Always rebuild after changing requirements.txt or Dockerfile.
Check Logs: docker logs <container-id> is your best debugging buddy.
Clean Up: Remove old containers/images to avoid conflicts.
Document Everything: Clear steps save time later.

What’s Next?

Dockerizing my API was a huge win, as it is now portable and production-ready. My next steps are:

Pushing student-api:1.0.0 to Docker Hub to share with others.
Adding endpoints like GET /students or DELETE.
Writing more tests to ensure reliability.

Thanks for reading! If you’re Dockerizing your own project, I hope my mistakes save you some headaches. Drop a comment with your tips or questions, I’d love to hear them ✨

💡 Build Along with Me: A Beginner’s Guide to Creating a Student API Using Flask

Emidowojo — Sat, 12 Apr 2025 00:20:35 +0000

Today on my journey to gaining DevOps Mastery, I Built a Student REST API with Flask. In this guide, I’ll walk you through how I created a REST API from scratch. No fancy frameworks or prior knowledge is required—just some curiosity and a willingness to debug. Let’s build it together, step-by-step, with all the highs and lows I hit along the way.

Pre-requisites

Before we start, here’s what you’ll need:

A Computer: Any machine with Python 3 (Windows, Linux, or Mac) works fine.
Basic Terminal Skills: If you can type commands like cd or mkdir, you’re set.
Python Installed: I had Python 3.13—check with python3 --version in your terminal.
VS Code (Optional): It’s my editor of choice, but any text editor (like Notepad) will do.
Patience: I ran into errors (like “db not defined”), but I’ll show you how to fix them!

Introduction to REST APIs
Step-by-Step Guide to Building the Student API
Key Concepts: Flask, SQLAlchemy, and Testing
Troubleshooting Common Issues
Conclusion

Introduction to REST APIs

What is a REST API?

Think of a REST API as a librarian for a student database. You can ask it to add a student, list all students, update a record, or delete one—all through web commands. It’s like a website, but instead of pages, it gives you data (like {"name": "Alice", "age": 20}).

Why is this useful?

Flexibility: Use it from a browser, app, or script.
Learning: Teaches you web basics in a fun way.
Real-World Skills: APIs power tons of apps—like your favorite social media.

In this post, I’ll show you how I built the API to handle CRUD (Create, Read, Update, Delete) operations.

Step-by-Step Implementation

Here’s how I built my API, command by command.

Part 1: Setting Up the Project

Creating the Folder and Virtual Environment

On my terminal:

# Create a new folder for the project
mkdir student-api-new
# Move into the folder
cd student-api-new
# Create a virtual environment (a "toolbox" for project tools)
python3 -m venv .venv
# Activate the virtual environment to use its tools
source .venv/bin/activate

What it does: Makes a folder and a “toolbox” (virtual environment) to keep my project’s tools separate. Activating it with source puts me in the toolbox.

Installing Tools

# Install Flask (web framework), Flask-SQLAlchemy (database), python-dotenv (settings), and pytest (testing)
pip install flask flask-sqlalchemy python-dotenv pytest
# Save the installed tools to a list for others to use
pip freeze > requirements.txt

What it does: Adds Flask (web framework), Flask-SQLAlchemy (database helper), python-dotenv (settings loader), and pytest (testing tool). requirements.txt lists them for later.

Part 2: Building the Structure

Setting Up Files

I used VS Code to create this structure:

student-api-new/
├── Makefile          # Instructions for running the app
├── README.md         # Project guide
├── requirements.txt  # List of tools
├── .env              # Secret settings
├── .gitignore        # Files to ignore in Git
├── app/              # Main app code
│   ├── __init__.py   # App setup
│   ├── models.py     # Student definition
│   ├── routes.py     # Web commands
│   └── config.py     # App settings
├── tests/            # Test code
│   └── test_api.py   # Tests for the API
└── .venv/            # Virtual environment

How: Right-click in VS Code’s Explorer, pick “New File” or “New Folder,” and name them.

Part 3: Coding the API

Configuration (`app/config.py` and `.env`)

.env:

# Set Flask to development mode for easier debugging
FLASK_ENV=development
# Define the database location (SQLite file)
DATABASE_URL=sqlite:///students.db
# A secret key for security
SECRET_KEY=mysecretkey

app/config.py:

# Import os to access environment variables
import os
# Import dotenv to load .env file
from dotenv import load_dotenv

# Load environment variables from .env
load_dotenv()

# Define configuration settings for the app
class Config:
    # Set database location from .env
    SQLALCHEMY_DATABASE_URI = os.getenv("DATABASE_URL")
    # Disable a warning for performance
    SQLALCHEMY_TRACK_MODIFICATIONS = False
    # Set secret key from .env for security
    SECRET_KEY = os.getenv("SECRET_KEY")

Why: Keeps secrets (like the database location) safe and separate.

The App Setup (`app/init.py`)

# Import logging to track app events
import logging
# Import Flask to create the web app
from flask import Flask
# Import Config for settings
from .config import Config
# Import db for the database
from .models import db

# Set up logging to show info messages
logging.basicConfig(level=logging.INFO)
# Create a logger for this module
logger = logging.getLogger(__name__)

# Function to create and configure the Flask app
def create_app():
    # Initialize Flask app
    app = Flask(__name__)
    # Load settings from Config
    app.config.from_object(Config)
    # Connect database to app
    db.init_app(app)
    # Create database tables
    with app.app_context():
        db.create_all()
        # Log that tables were created
        logger.info("Database tables created")
    # Import and set up routes
    from .routes import init_routes
    init_routes(app)
    # Return the configured app
    return app

What it does: Starts the Flask app and sets up the database.

Student Model (`app/models.py`)

# Import SQLAlchemy for database management
from flask_sqlalchemy import SQLAlchemy

# Create database object
db = SQLAlchemy()

# Define Student table structure
class Student(db.Model):
    # Primary key column for unique IDs
    id = db.Column(db.Integer, primary_key=True)
    # Name column, can't be empty
    name = db.Column(db.String(100), nullable=False)
    # Age column, can't be empty
    age = db.Column(db.Integer, nullable=False)

    # Convert student data to a dictionary for API responses
    def to_dict(self):
        return {"id": self.id, "name": self.name, "age": self.age}

What it does: Defines what a “student” looks like in the database.

API Routes (`app/routes.py`)

# Import logging for tracking events
import logging
# Import Flask tools for handling requests
from flask import request, jsonify
# Import database and Student model
from .models import db, Student

# Create a logger for this module
logger = logging.getLogger(__name__)

# Function to define all API routes
def init_routes(app):
    # Healthcheck endpoint to test if API is running
    @app.route('/api/v1/healthcheck', methods=['GET'])
    def healthcheck():
        # Return a JSON response with status
        return jsonify({"status": "healthy"}), 200

    # Endpoint to add a new student
    @app.route('/api/v1/students', methods=['POST'])
    def add_student():
        # Get JSON data from request
        data = request.get_json()
        # Create a new student object
        student = Student(name=data['name'], age=data['age'])
        # Add student to database
        db.session.add(student)
        # Save changes to database
        db.session.commit()
        # Log the addition
        logger.info(f"Student {student.name} added with ID {student.id}")
        # Return student data as JSON with status 201 (created)
        return jsonify(student.to_dict()), 201
    # More routes for GET, PUT, DELETE...

What it does: Adds web commands like “add a student.”

Makefile

# Define targets that aren't files
.PHONY: install run test

# Target to install dependencies
install:
    # Install tools listed in requirements.txt
    .venv/bin/pip install -r requirements.txt

# Target to run the app
run:
    # Start Flask server
    flask run

# Target to run tests
test:
    # Run pytest with verbose output
    .venv/bin/pytest -v

Pitfall: Use tabs before commands, not spaces or it fails

Part 4: Testing the API

Manual Testing

# Tell Flask where the app is
export FLASK_APP=app
# Start the app
make run

Then, in another terminal:

# Send a POST request to add a student
curl -X POST http://127.0.0.1:5000/api/v1/students -H "Content-Type: application/json" -d '{"name": "Alice", "age": 20}'

Output: {"id": 1, "name": "Alice", "age": 20}

Automated Testing (`tests/test_api.py`)

# Import pytest for testing
import pytest
# Import sys and os for path adjustments
import sys
import os
# Add project root to Python path
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))
# Import app setup function
from app import create_app
# Import database object
from app.models import db

# Define a fixture to set up test client
@pytest.fixture
def client():
    # Create app instance
    app = create_app()
    # Enable testing mode
    app.config['TESTING'] = True
    # Create a test client
    with app.test_client() as client:
        # Use app context for database operations
        with app.app_context():
            # Create database tables
            db.create_all()
        # Yield client for tests
        yield client

# Test adding a student
def test_add_student(client):
    # Send POST request with student data
    response = client.post('/api/v1/students', json={"name": "Alice", "age": 20})
    # Check if status code is 201 (created)
    assert response.status_code == 201
    # Check if response name matches input
    assert response.json['name'] == "Alice"

Run: make test
Pitfall: Forgot to import db—fixed it and it passed!

API Documentation

Now that we've built and tested our API, here's a complete reference of all available endpoints and how to use them.

🩺 Health Check

GET /api/v1/healthcheck Checks if the API is running.

Response:

{ "status": "healthy" }

🎓 Create a New Student

POST /api/v1/students Adds a student to the database.

Request Body:

{
  "name": "Alice",
  "age": 20
}

Success Response (201):

{
  "id": 1,
  "name": "Alice",
  "age": 20
}

Error (400):

{
  "error": "Invalid input"
}

📋 Get All Students

GET /api/v1/students Retrieves all students.

Response:

[
  {
    "id": 1,
    "name": "Alice",
    "age": 20
  }
]

🔍 Get a Student by ID

GET /api/v1/students/<id> Fetches a student using their ID.

Success (200):

{
  "id": 1,
  "name": "Alice",
  "age": 20
}

Error (404):

{
  "error": "Student not found"
}

📝 Update a Student

PUT /api/v1/students/<id> Updates a student's details.

Request Body:

{
  "name": "Alicia",
  "age": 21
}

Success (200):

{
  "id": 1,
  "name": "Alicia",
  "age": 21
}

Error (404):

{
  "error": "Student not found"
}

❌ Delete a Student

DELETE /api/v1/students/<id> Deletes a student record.

Success (204): No content returned.

Error (404):

{
  "error": "Student not found"
}

✅ Common Status Codes

Code	Description
200	OK
201	Created
204	No Content
400	Bad Request
404	Not Found

💡 Tip: You can test all these endpoints using Postman or cURL.

Key Concepts: Flask, SQLAlchemy, and Testing

Flask: A lightweight tool to build web apps. It’s like the frame of our “student library.”
SQLAlchemy: Manages the database, like a filing cabinet for student records.
Testing with pytest: Checks if the app works without manual effort.

Together, they make a simple, working API.

Troubleshooting Common Issues

Makefile Error (“missing separator”):
- Issue: Used spaces instead of tabs.
- Solution: Retyped with tabs—worked like magic!
“Not Found” on Healthcheck:
- Issue: App wasn’t running or routes weren’t loaded.
- Solution: Checked make run and routes.py.
“db not defined” in Tests:
- Issue: Missed importing db in test_api.py.
- Solution: Added from app.models import db.

Conclusion

I built a Student REST API from nothing—adding students, and testing it. It’s not perfect, but it works, and I learned so much. From “missing separator” to “db not defined,” every error taught me something new. I hope you learnt something insightful from this. Happy coding!

Shhh, It's a Secret! Using Pulumi ESC & AWS Lambda for Secure Secrets Management

Emidowojo — Thu, 03 Apr 2025 02:09:49 +0000

This is a submission for the Pulumi Deploy and Document Challenge: Shhh, It's a Secret!

What I Built

Hey there! I'm excited to share Shhh, It's a Secret!, a beginner-friendly project where I built an AWS Lambda function using Pulumi. This Lambda grabs a secret (in my case, fake-api-key-xyz123) from Pulumi ESC (Environments, Secrets, and Configuration)—a super cool tool for keeping sensitive stuff safe. While it's not a static website itself, imagine it as a helper for one: it could securely pass secrets to a fast static site without exposing them in the code. I used Pulumi to set up everything, ESC to manage the secret, and Node.js to make the Lambda work—all wrapped up in a GitHub repo with a clear README for anyone to follow along.

Here's what's inside:

Pulumi Stack: Sets up an IAM role and the Lambda function.
ESC Environment: Holds my secret, myApiKey.
Lambda Function: Pulls the secret using the @pulumi/esc-sdk and logs it.

Don't worry if this sounds complex—I'll walk you through every step so you can build it too.

Live Demo Link

Since this is a Lambda (a serverless function) and not a website with a URL, there's no "live demo" to click. But you can try it yourself in your AWS account! Here's how:

Grab the code from my repo (see below).
Run pulumi up to deploy it.
Head to AWS Console > Lambda > secretFetcher > Test, and run a test event (just use {}).
Check CloudWatch logs—you should see "Secret fetched: fake-api-key-xyz123".

Project Repo

Check out my GitHub repo: Emidowojo/pulumi-secret-demo. It's got all the code and a README.md. Here's a peek:

# Pulumi Secret Demo
This project shows you how to fetch a secret from Pulumi ESC with an AWS Lambda.
## Setup
1. Install Pulumi and AWS CLI (don't worry, I'll explain how below!).
2. Run `pulumi login` and `aws configure`.
3. Clone this: `git clone https://github.com/Emidowojo/pulumi-secret-demo`.
4. Go in: `cd pulumi-secret-demo && npm install`.
5. Set up ESC: Make an environment `Emidowojo/pulumi-secret-demo/my-secrets` with `myApiKey: fake-api-key-xyz123`.
6. Add your token: `pulumi config set pulumiAccessToken <your-token> --secret`.
7. Deploy: `pulumi up`.
## Testing
- Go to AWS Console > Lambda > `secretFetcher` > Test.
- Look in CloudWatch logs for "Secret fetched: fake-api-key-xyz123".

My Journey

While building it, I hit bumps, learned so much, and came out with a working project. Let me take you through it step-by-step, so you can follow along (and avoid my mistakes).

Day 1: Getting Started with Pulumi and ESC

What I Did:

Tools First: I installed Pulumi with npm install -g @pulumi/pulumi (it's a command-line tool for cloud stuff) and AWS CLI via Homebrew (brew install awscli) on my MacBook.
Logging In: Ran pulumi login to connect to app.pulumi.com (you'll need an account—free to sign up!). Then aws configure to add my AWS Access Key, Secret Key, and region (us-east-1).
New Project: Made a folder with mkdir pulumi-secret-demo && cd pulumi-secret-demo, then started a Pulumi project with pulumi new aws-typescript. This gave me a starter index.ts file.
ESC Setup: Went to app.pulumi.com, clicked ESC > New Environment, named it Emidowojo/pulumi-secret-demo/my-secrets, and added:

values:
  myApiKey: fake-api-key-xyz123

Token Time: Got my Pulumi access token from User Settings and ran:

export PULUMI_ACCESS_TOKEN=pul-**************************************************************

What Went Wrong:

I forgot the token at first—pulumi up failed with "Not authenticated." Setting the token fixed it fast.

Takeaway: ESC is awesome for secrets—it's like a safe for your API keys. If you're new, try to double-check your logins.

Day 2: Making the Lambda and Fixing Bugs

What I Did:

Pulumi Code (index.ts): Wrote this to create a Lambda and IAM role:

import * as pulumi from "@pulumi/pulumi"; // Import Pulumi for coding cloud stuff
import * as aws from "@pulumi/aws"; // Import AWS tools for Lambda and IAM
// Create an IAM role so Lambda can run
const lambdaRole = new aws.iam.Role("lambdaRole", {
    assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal({ Service: "lambda.amazonaws.com" }),
});
// Attach a basic policy to the role
new aws.iam.RolePolicyAttachment("lambdaPolicy", {
    role: lambdaRole, // Link to our role
    policyArn: aws.iam.ManagedPolicy.AWSLambdaBasicExecutionRole,// Gives Lambda permission to log
});
// Define the Lambda function
const lambda = new aws.lambda.Function("secretFetcher", {
    runtime: "nodejs18.x",     // Use Node.js 18
    handler: "index.handler", // Points to lambda/index.js’s handler function
    role: lambdaRole.arn,   // Use our role’s ARN (unique ID)
    code: new pulumi.asset.AssetArchive({ // Bundle our Lambda code
        ".": new pulumi.asset.FileArchive("./lambda"), // Grab everything in the lambda folder
    }),
    environment: {     // Set environment variables
        variables: {
            PULUMI_ACCESS_TOKEN: pulumi.output(process.env.PULUMI_ACCESS_TOKEN).apply(t => t || ""),
        },
    },
});

export const lambdaArn = lambda.arn; // Share the Lambda’s ARN for later use

Lambda Code: Made a lambda folder:

mkdir lambda && cd lambda && npm init -y && npm install @pulumi/esc-sdk

First try at lambda/index.js:

const { EscClient } = require("@pulumi/esc-sdk"); // Import the ESC library (first version I tried)
exports.handler = async () => {   // Lambda’s main function
    const client = new EscClient({ accessToken: process.env.PULUMI_ACCESS_TOKEN }); // Connect to ESC with token
    const env = await client.getEnvironment("my-secrets"); // Try to fetch the secret
    console.log("Secret fetched:", env.values.myApiKey); // Log the secret
    return { statusCode: 200, body: "Secret retrieved!" }; // Sends a successful response
};

Deployed: Ran pulumi up—it showed "+ 4 to create" and set up my stack.

What Went Wrong: Read the "Challenges I Faced" section below

Takeaway: Don't panic when things break—logs and patience will save you.

Day 3: Winning and Sharing

What I Did:

Final Deploy: After fixing bugs, ran pulumi up again to update the Lambda.
Testing: Went to AWS Console > Lambda > secretFetcher > Test, created a New1 event ({}), and ran it. Checked CloudWatch logs—bam, "Secret fetched: fake-api-key-xyz123"!
GitHub: Pushed everything:

git add . && git commit -m "Finished Lambda with ESC" && git push --force

What Went Wrong: Just making sure the token worked after moving it to config—easy check with pulumi config get pulumiAccessToken.

Takeaway: Seeing it work feels amazing, and sharing it makes it even better!

Challenges I Faced

Here's where I stumbled—and how I got back up. If you hit these, you'll know what to do!

"Cannot find name 'pulumi'" in index.ts
- Problem: TypeScript didn't recognize pulumi.
- Fix: Added import * as pulumi from "@pulumi/pulumi"; at the top. Simple miss!
"Type 'string | undefined'" for PULUMI_ACCESS_TOKEN
- Problem: TypeScript complained about my env var.
- Fix: Wrapped it: pulumi.output(process.env.PULUMI_ACCESS_TOKEN).apply(t => t || "").
Lambda Not in AWS
- Problem: Deployed, but couldn't find secretFetcher in us-east-1.
- Fix: My AWS CLI region didn't match Pulumi's—set it in Pulumi.dev.yaml or CLI.
"EscClient is not a constructor"
- Problem: Lambda failed with this error.
- Fix: The SDK changed—updated to const { EscApi } = require("@pulumi/esc-sdk/esc"). Checked node_modules/@pulumi/esc-sdk/esc/index.js to confirm.
"401 Unauthorized" Errors
- Problem: Lambda kept failing—logs showed "undefined pul-..." in the Authorization header.
- Fix: Added Configuration:

   const { EscApi, Configuration } = require("@pulumi/esc-sdk/esc"); // Import both classes
   const config = new Configuration({ accessToken: process.env.PULUMI_ACCESS_TOKEN }); // Set up token properly
   const client = new EscApi(config); // Create client with config

Also switched to openAndReadEnvironment("Emidowojo", "pulumi-secret-demo", "my-secrets"). // Fetch secret

GitHub Push Blocked

Problem: Hardcoded token in index.ts—GitHub refused to.
Fix: Moved it to config:

   pulumi config set pulumiAccessToken pul-************************************************************** --secret

Updated index.ts:

   const config = new pulumi.Config(); // Use Pulumi’s config system
   const pulumiAccessToken = config.require("pulumiAccessToken"); // Get token securely
   environment: { variables: { PULUMI_ACCESS_TOKEN: pulumiAccessToken } }

Amended commit: git commit --amend --no-edit && git push --force.

Using Pulumi ESC

Pulumi made this project so much easier—here's how it helped me (and can help you too!):

What It Did: I used Pulumi to write index.ts, setting up my Lambda and IAM role in TypeScript. It's like coding your cloud instead of clicking around!
Example: new aws.lambda.Function("secretFetcher", {...}) built my Lambda in one go.
How It Worked: Ran pulumi up—it showed me what it'd create (4 resources) and deployed them fast. Later updates were just ~ 1 to update.
Why I Loved It: No confusing YAML—TypeScript felt natural. Plus, pulumi up previews caught mistakes before they happened (like missing imports).

Pulumi ESC kept my secrets safe! —here's the rundown:

What It Did: I stored myApiKey: fake-api-key-xyz123 in an ESC environment called Emidowojo/pulumi-secret-demo/my-secrets. My Lambda grabs it securely.
Setup: Added it in app.pulumi.com under ESC.
Code: Used openAndReadEnvironment to fetch it.
How I Set It Up: Kept my ESC token safe with:

pulumi config set pulumiAccessToken <your-token> --secret

Passed it to Lambda in index.ts's environment.
Why It's Great: No secrets in my code—ESC encrypts them and ties right into Pulumi. Perfect for a static site needing secure API keys without the hassle of AWS Secrets Manager.

Conclusion

And there you have it—Shhh, It’s a Secret! is live! We’ve built an AWS Lambda that securely fetches a secret from Pulumi ESC, ready to support a static site without ever risking sensitive data in the code. From setting up Pulumi and ESC to wrestling bugs and pushing to GitHub, this journey taught me how powerful (and fun) infrastructure-as-code can be. Now that it’s working, I’m hooked on exploring more—maybe pairing this Lambda with an S3 static site next! Want to try it? Grab the repo, run pulumi up, and see the magic for yourself. Happy coding!

From Classroom to Command Line: Building My First Live Server with AWS EC2 and NGINX

Emidowojo — Thu, 30 Jan 2025 21:39:43 +0000

Five years after my first attempt, I rejoined the HNG internship program—this time choosing the DevOps track. While I had explored DevOps through LinkedIn Learning courses, I remained trapped in tutorial hell, never quite taking the leap into practical application. The HNG internship presented the perfect opportunity to change that.

My journey began on a Tuesday with the first task landing in my inbox. Despite feeling daunted and exhausted from my day job, I was determined to succeed. After some initial research, I tackled the project head-on the next morning, temporarily setting aside my work responsibilities.

What I thought would be a quick task turned into an adventure through multiple cloud platforms. I started with Digital Ocean, where I successfully connected to SSH and installed NGINX. However, I hit a wall when trying to edit the HTML file—a mysterious password requirement that no combination of credentials could satisfy.

Frustrated but undeterred, I pivoted to AWS. While the experience was somewhat better, I still faced permission issues when trying to edit the HTML page. A brief attempt with Azure proved equally challenging. Through all this, I juggled work responsibilities and an empty stomach, but my determination never wavered.

After nearly giving up—and reminding myself that quitting wasn't in my nature—I made one final attempt with AWS. Success finally came the following day around 3 PM.

The Winning Process

Here's how I ultimately succeeded:

Created an AWS EC2 Instance (Ubuntu Server 22.04 LTS) using the free tier t3.micro
Generated a key pair named DevOpsKey (.pem file)
Configured the security group to allow SSH (Port 22) from my IP and HTTP (Port 80) from anywhere
Connected to the EC2 instance via SSH using:

cd ~/Desktop/projects
chmod 400 DevOpsKey.pem
ssh -i "DevOpsKey.pem" ubuntu@16.171.194.50

Installed and configured NGINX:

sudo apt update && sudo apt upgrade -y
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx

Created a custom HTML page:

sudo nano /var/www/html/index.html

Added my custom HTML:

<!DOCTYPE html>
<html>
<head>
    <title>DevOps Stage 0</title>
</head>
<body>
    <h1>Welcome to DevOps Stage 0 - [Emidowojo Opaluwa]/[Emidowojo]</h1>
</body>
</html>

After saving the file (Ctrl + O, Enter, Ctrl + X), I visited http://16.171.194.50 and saw my custom message displayed proudly in the browser. Below is a screenshot of my custom message

While the journey was frustrating at times, it was incredibly rewarding. The hands-on experience taught me more than any tutorial could have. Here's to the remaining nine stages of this adventure! ✨

Debugging Authorization: How Cerbos Makes Troubleshooting Access Issues a Breeze

Emidowojo — Wed, 15 Jan 2025 10:46:13 +0000

When you hear the word "authorization," what comes to your mind? Before I learned about it properly, I thought it was just about checking if someone was allowed to do something - like a simple yes or no gate. While that basic idea isn't wrong, there's so much more beneath the surface. Authorization is really about creating an intricate web of trust and permissions that determines not just who can access what, but how different parts of a system interact with each other.

And that's where tools like Cerbos come into play. Just like how we evolved from using simple keys to sophisticated access control systems, we have moved beyond basic allow/deny rules to powerful policy-based authorization. Cerbos lets you define these complex permission rules in a way that's both powerful and elegant - think of it as the master conductor orchestrating who gets to do what across your entire system, making sure every access request follows the exact rules you've set up, without missing a beat.

Pre-requisites

To get the most out of this article, readers should have a foundational understanding of the following:

Basic Authorization Concepts: Authentication vs. authorization, roles, permissions, and access control.
IAM Systems: Role-based or attribute-based access control models.
YAML Configuration: Syntax and editing basics.
Distributed Systems: Managing access in microservices/cloud setups.
Cerbos Basics: Overview of Cerbos and its role in simplifying authorization.
Debugging Tools: Experience with logs and troubleshooting.

Introduction
Understanding Common Authorization Debugging Challenges
Cerbos Debugging Tools and Features
Step-by-Step Debugging with Cerbos
Benefits of Using Cerbos for Debugging
Conclusion

Introduction

Debugging authorization can feel like solving a puzzle with missing pieces, especially when users are denied access despite having the right permissions. In this article, we explore common authorization issues and how Cerbos simplifies debugging access problems.

The Pain of Debugging Authorization

Misconfigured roles/permissions.
Lack of visibility into access decisions.
Complexities in distributed systems.

Traditional debugging approaches often rely on guesswork, leading to time-consuming and error-prone processes. Cerbos, on the other hand, offers clear insights and simplifies access troubleshooting.

How Cerbos Simplifies the Process

Enter Cerbos—a policy-based authorization tool that’s designed to make debugging access issues not just easier, but almost enjoyable. With Cerbos, you get:

Clear Audit Logs: Understand every access decision at a glance.
Readable Policies: No more struggling with cryptic configuration files.
Policy Testing Tools: Validate changes before they go live, saving you from future headaches.

In the sections ahead, we’ll break down how Cerbos addresses the pain points of traditional debugging and gives you the tools to resolve access issues efficiently and with confidence.

Understanding Common Authorization Debugging Challenges

When it comes to debugging authorization, things can get tricky fast. It’s not just about getting a simple "yes" or "no" on access; there are layers of complexity. Let’s explore some of the most common challenges developers face when debugging authorization issues.

Misconfigured Roles and Permissions
Permissions may not align as expected, leading to access denials despite correct roles.
Lack of Transparency
Without clear feedback on access decisions, troubleshooting can become inefficient.
Distributed Systems
Debugging becomes more complicated in environments where services and policies are spread across multiple systems.

By understanding these common challenges, you can start thinking about ways to make your authorization debugging process smoother, more efficient, and way less frustrating.

Cerbos Debugging Tools and Features
When it comes to debugging authorization issues, Cerbos is like having a clear roadmap in the middle of a foggy forest. Here’s how its tools make the journey a lot easier:

Audit Logs: Gaining Visibility into Access Decisions

Think of audit logs as your application’s diary. They track every access decision, giving you a full breakdown of who accessed what and why. Instead of guessing where things went wrong, you can dive into detailed logs and pinpoint exactly where a misstep occurred. No more blind troubleshooting—Cerbos makes it transparent.

Human-Readable Policies: Identifying Misconfigurations Easily

Configuration files can often feel like a secret code, but Cerbos’ human-readable policies cut through the complexity. Instead of struggling with cryptic rules, you can quickly scan through policies in plain language, making it easier to spot any misconfigurations. It’s like reading a map instead of a maze.

Testing Policies: Validating Before Deploying

Cerbos lets you test your policies before they go live. This means you can validate your rules in a controlled environment, ensuring they work as intended without breaking anything in production. It’s like running a rehearsal before the big performance—no surprises, just smooth execution.

With these tools, debugging authorization issues becomes a breeze, and the process of fixing them is both faster and more accurate.

Step-by-Step Debugging with Cerbos

A Common Scenario: Denied Access with Correct Role

Let’s start with the problem at hand: a user is assigned the correct role, but they can’t access the resource they need. You check the permissions, and everything seems fine. But the system still won’t let them through. This is a classic case where debugging tools like Cerbos can save you time and sanity.

Using Audit Logs to Trace Issues

The first thing you’ll want to do is dig into the audit logs. Cerbos provides detailed logs of every authorization decision made. By reviewing these logs, you can quickly see what happened when the user attempted to access the resource. Was it a permissions issue? Or maybe the role didn’t get applied as expected? The logs will give you the visibility you need to start tracing the problem.

Reviewing and Adjusting YAML Policies

Next up: YAML policies. With Cerbos, you define your access control rules in YAML, making it easy to see exactly what’s happening under the hood. If the logs point to a permissions issue, it’s time to take a closer look at the policies. Was the correct role linked to the right permissions? Sometimes, a small typo or misconfiguration can cause big headaches, so give those policies a thorough review.

Testing and Deploying Fixes

Once you've tracked down the issue and adjusted the policies, it’s time to test. Cerbos lets you simulate access control decisions, so you can ensure that everything works as expected before pushing changes live. Run a few tests to confirm that the denied user can now access the resource. If everything checks out, deploy the fix to production with confidence.

By following these steps, you’ll not only resolve the access issue but also build a better understanding of how Cerbos helps streamline authorization debugging.

Benefits of Using Cerbos for Debugging

Time Savings with Clear Insights

With Cerbos, debugging authorization issues no longer feels like searching for a needle in a haystack. The clear, human-readable audit logs provide instant insights into access decisions, saving you valuable time. Instead of diving into complex logs or running endless tests, you can quickly pinpoint what went wrong and get back to business.

Improved Accuracy with Readable and Testable Policies

Cerbos doesn’t just make debugging easier—it makes your policies more reliable. Its readable policy language and built-in testing tools allow you to validate changes before they go live, ensuring you catch potential issues early. No more guessing if a policy change will work as expected—Cerbos gives you the confidence that everything is set up correctly.

Enhanced Collaboration Between Teams

Debugging authorization often requires input from multiple teams—security, development, operations. Cerbos simplifies collaboration by making policies transparent and easy to understand. With the ability to test policies together and see who has access to what, everyone can stay on the same page and solve problems faster.

Conclusion
In a nutshell, Cerbos makes debugging authorization a whole lot easier. With features like detailed audit logs, human-readable policies, and testing tools, Cerbos helps you quickly identify and fix access issues. Gone are the days of sifting through endless lines of code or grappling with confusing configurations.

If you’re tired of the headache that comes with troubleshooting access problems, it’s time to give Cerbos a try. Its simple, powerful approach can save you time, boost your confidence in your authorization setup, and make collaboration with your team smoother than ever. So, take the plunge and see how Cerbos can make your life easier—and your access control, a breeze!

DEV Community: Emidowojo

Building a Reliable Payment Tracker with Daya's API and AWS

Live Demo

The Problem

The Architecture

Why Daya?

Relevant Documentation

Creating Payment Details

Receiving Webhooks

Why Queue the Webhook?

Faster Responses

Retryability

Failure Isolation

Traffic Buffering

Dead-Letter Queues

Processing Payments Safely

Handling Duplicate Events

Storing Payment State

Managing Secrets

Monitoring and Operations

Deployment

What About Containers?

Lessons Learned

1. Webhook Handlers Should Be Boring

2. Queues Are an Investment in Reliability

3. Idempotency Is Not Optional

4. Reliability Is an Architecture Decision

5. Observability Matters More Than Expected

Before Production

Final Thoughts

Building a Student REST API with Flask and Docker

Why Docker?

Step 1: Writing the Dockerfile

Stage 1: Build dependencies

Stage 2: Runtime image

What I Learned

Step 2: Adding a .dockerignore

Step 3: Building the Docker Image

Step 4: Running the Container

Step 5: Testing the API

Output:

Output:

Step 6: Updating Documentation

Setup (Docker)

Prerequisites

Build the Image

Run the Container

Step 7: Committing to GitHub

Errors I Ran Into (and How I Fixed Them)

1. Slow Build Time (17+ Minutes)

2. Gunicorn Not Found

3. Container Conflict When Rebuilding

4. Git Ignoring Dockerfile

5. VS Code Warning About Gunicorn

What I Learned Overall

What’s Next?

💡 Build Along with Me: A Beginner’s Guide to Creating a Student API Using Flask

Pre-requisites

Table of Contents

Introduction to REST APIs

What is a REST API?

Why is this useful?

Step-by-Step Implementation

Part 1: Setting Up the Project

Creating the Folder and Virtual Environment

Installing Tools

Part 2: Building the Structure

Setting Up Files

Part 3: Coding the API

Configuration (app/config.py and .env)

The App Setup (app/__init__.py)

Student Model (app/models.py)

API Routes (app/routes.py)

Makefile

Part 4: Testing the API

Manual Testing

Automated Testing (tests/test_api.py)

API Documentation

🩺 Health Check

🎓 Create a New Student

Step 2: Adding a `.dockerignore`

Configuration (`app/config.py` and `.env`)

The App Setup (`app/init.py`)

Student Model (`app/models.py`)

API Routes (`app/routes.py`)

Automated Testing (`tests/test_api.py`)