DEV Community: ROBERTO CARLOS HUAMAN RIVERA

🚀 Building and Deploying an Interactive Data Dashboard with Streamlit, Plotly and GitHub Actions

ROBERTO CARLOS HUAMAN RIVERA — Tue, 29 Sep 2026 13:28:21 +0000

Have you ever created a data analysis in Python, generated some charts, and then realized that the only way to show the results was by sending screenshots or a Jupyter Notebook?

For data analysts and developers, visualizing information is only part of the challenge. A good data project should also be interactive, accessible, reproducible, and easy to deploy.

This is where Streamlit becomes extremely useful.

Streamlit is a Python framework that allows developers to transform Python scripts into interactive web applications without needing to build a separate frontend using HTML, CSS, or JavaScript.

In this article, we will build a Sales Analytics Dashboard using Python, Pandas, Plotly, and Streamlit. We will then publish the source code on GitHub, implement automation with GitHub Actions, and deploy the application publicly using Streamlit Community Cloud.

📊 The Project: Sales Analytics Dashboard

Imagine that a company wants to analyze its sales performance.

The company needs a dashboard where users can quickly see:

Total revenue
Total orders
Average order value
Revenue by product category
Monthly sales trends
Sales by region

Instead of generating static charts, we will create an interactive dashboard where users can filter the information and see the visualizations update automatically.

Our technology stack will be:

Python – Programming language
Pandas – Data processing
Plotly – Interactive charts
Streamlit – Dashboard interface
GitHub – Version control and public repository
GitHub Actions – Automation and validation
Streamlit Community Cloud – Public deployment

Step 1: Project Structure

Before writing the dashboard, we organize the project.

sales-dashboard/
│
├── .github/
│   └── workflows/
│       └── python-app.yml
│
├── data/
│   └── sales.csv
│
├── app.py
├── requirements.txt
└── README.md

The most important file is app.py, which contains our Streamlit application.

The requirements.txt file contains all Python dependencies required to run the project.

Our requirements.txt looks like this:

streamlit
pandas
plotly

Step 2: Creating the Dataset

For this example, imagine that our sales.csv file contains the following information:

Date,Product,Category,Region,Quantity,Revenue
2026-01-05,Laptop,Technology,North,2,2400
2026-01-10,Headphones,Technology,South,5,750
2026-02-03,Office Chair,Furniture,West,3,900
2026-02-15,Desk,Furniture,East,2,1200
2026-03-01,Smartphone,Technology,North,4,3200
2026-03-20,Notebook,Office Supplies,South,20,200
2026-04-10,Monitor,Technology,West,3,1050
2026-04-22,Printer,Office Supplies,East,2,700

In a real-world project, this dataset could come from a database, API, Excel file, cloud storage service, or business information system.

For this dashboard, we will load the CSV file using Pandas.

Step 3: Building the Streamlit Application

Now we can create the main application.

Create a file named:

app.py

First, import the required libraries:

import streamlit as st
import pandas as pd
import plotly.express as px

Next, configure the Streamlit page:

st.set_page_config(
    page_title="Sales Analytics Dashboard",
    page_icon="📊",
    layout="wide"
)

st.title("📊 Sales Analytics Dashboard")

st.write(
    "Interactive dashboard for analyzing sales performance "
    "by category, region and time."
)

The layout="wide" configuration gives us more horizontal space, which is particularly useful for dashboards.

Step 4: Loading and Preparing the Data

We can load our dataset with Pandas:

@st.cache_data
def load_data():
    df = pd.read_csv("data/sales.csv")
    df["Date"] = pd.to_datetime(df["Date"])
    return df

df = load_data()

The dataset contains sales transactions with information such as date, category, region, quantity, and revenue.

After converting the Date column into a datetime value, we can also create a month field:

df["Month"] = df["Date"].dt.to_period("M").astype(str)

This will allow us to analyze monthly sales trends.

Step 5: Adding Interactive Filters

One of the main advantages of Streamlit is that we can easily add interactive widgets.

For example, users can filter the dashboard by region and product category.

st.sidebar.header("Dashboard Filters")

selected_region = st.sidebar.multiselect(
    "Select Region",
    options=df["Region"].unique(),
    default=df["Region"].unique()
)

selected_category = st.sidebar.multiselect(
    "Select Category",
    options=df["Category"].unique(),
    default=df["Category"].unique()
)

Now we apply these filters to our dataset:

filtered_df = df[
    (df["Region"].isin(selected_region)) &
    (df["Category"].isin(selected_category))
]

Every visualization that uses filtered_df will automatically update when the user changes the filters.

Step 6: Creating KPI Metrics

A dashboard should provide important information immediately.

For this project, we will calculate three Key Performance Indicators:

Total Revenue
Total Orders
Average Order Value

total_revenue = filtered_df["Revenue"].sum()

total_orders = len(filtered_df)

average_order_value = (
    total_revenue / total_orders
    if total_orders > 0
    else 0
)

Then we display them using Streamlit metrics:

col1, col2, col3 = st.columns(3)

col1.metric(
    "💰 Total Revenue",
    f"${total_revenue:,.2f}"
)

col2.metric(
    "🛒 Total Orders",
    total_orders
)

col3.metric(
    "📈 Average Order Value",
    f"${average_order_value:,.2f}"
)

This gives users a quick summary of the current filtered data.

Step 7: Revenue by Category

Now we can create our first visualization.

We group the data by product category:

category_sales = (
    filtered_df.groupby("Category")["Revenue"]
    .sum()
    .reset_index()
)

Then we create an interactive bar chart using Plotly:

fig_category = px.bar(
    category_sales,
    x="Category",
    y="Revenue",
    title="Revenue by Product Category",
    text_auto=True
)

st.plotly_chart(
    fig_category,
    use_container_width=True
)

Users can interact with the Plotly visualization by hovering over bars, zooming, and inspecting individual values.

Step 8: Monthly Sales Trend

Another important business visualization is the evolution of revenue over time.

First, we calculate monthly revenue:

monthly_sales = (
    filtered_df.groupby("Month")["Revenue"]
    .sum()
    .reset_index()
)

Then we generate a line chart:

fig_month = px.line(
    monthly_sales,
    x="Month",
    y="Revenue",
    markers=True,
    title="Monthly Revenue Trend"
)

st.plotly_chart(
    fig_month,
    use_container_width=True
)

This chart helps identify sales growth, reductions, or unusual changes over time.

Step 9: Sales by Region

We can also compare revenue between different geographical regions.

region_sales = (
    filtered_df.groupby("Region")["Revenue"]
    .sum()
    .reset_index()
)

For this visualization, we can use a pie chart:

fig_region = px.pie(
    region_sales,
    names="Region",
    values="Revenue",
    title="Revenue Distribution by Region"
)

st.plotly_chart(
    fig_region,
    use_container_width=True
)

Our dashboard now contains multiple visualization techniques for understanding the same dataset from different perspectives.

Step 10: Displaying the Raw Data

Sometimes users need to inspect the original information.

At the bottom of the application, we can include an expandable section containing the filtered dataset.

with st.expander("View Dataset"):
    st.dataframe(
        filtered_df,
        use_container_width=True
    )

This allows the dashboard to work both as a visualization tool and a simple data exploration interface.

🧩 Complete Application

The final app.py file looks like this:

import streamlit as st
import pandas as pd
import plotly.express as px


st.set_page_config(
    page_title="Sales Analytics Dashboard",
    page_icon="📊",
    layout="wide"
)

st.title("📊 Sales Analytics Dashboard")

st.write(
    "Interactive dashboard for analyzing sales performance "
    "by category, region and time."
)


@st.cache_data
def load_data():
    df = pd.read_csv("data/sales.csv")
    df["Date"] = pd.to_datetime(df["Date"])
    df["Month"] = df["Date"].dt.to_period("M").astype(str)
    return df


df = load_data()


# Sidebar filters

st.sidebar.header("Dashboard Filters")

selected_region = st.sidebar.multiselect(
    "Select Region",
    options=df["Region"].unique(),
    default=df["Region"].unique()
)

selected_category = st.sidebar.multiselect(
    "Select Category",
    options=df["Category"].unique(),
    default=df["Category"].unique()
)


filtered_df = df[
    (df["Region"].isin(selected_region)) &
    (df["Category"].isin(selected_category))
]


# KPIs

total_revenue = filtered_df["Revenue"].sum()
total_orders = len(filtered_df)

average_order_value = (
    total_revenue / total_orders
    if total_orders > 0
    else 0
)

col1, col2, col3 = st.columns(3)

col1.metric(
    "💰 Total Revenue",
    f"${total_revenue:,.2f}"
)

col2.metric(
    "🛒 Total Orders",
    total_orders
)

col3.metric(
    "📈 Average Order Value",
    f"${average_order_value:,.2f}"
)


# Revenue by Category

category_sales = (
    filtered_df.groupby("Category")["Revenue"]
    .sum()
    .reset_index()
)

fig_category = px.bar(
    category_sales,
    x="Category",
    y="Revenue",
    title="Revenue by Product Category",
    text_auto=True
)

st.plotly_chart(
    fig_category,
    use_container_width=True
)


# Monthly Revenue

monthly_sales = (
    filtered_df.groupby("Month")["Revenue"]
    .sum()
    .reset_index()
)

fig_month = px.line(
    monthly_sales,
    x="Month",
    y="Revenue",
    markers=True,
    title="Monthly Revenue Trend"
)

st.plotly_chart(
    fig_month,
    use_container_width=True
)


# Revenue by Region

region_sales = (
    filtered_df.groupby("Region")["Revenue"]
    .sum()
    .reset_index()
)

fig_region = px.pie(
    region_sales,
    names="Region",
    values="Revenue",
    title="Revenue Distribution by Region"
)

st.plotly_chart(
    fig_region,
    use_container_width=True
)


# Dataset

with st.expander("View Dataset"):
    st.dataframe(
        filtered_df,
        use_container_width=True
    )

Running the application locally is extremely simple:

streamlit run app.py

After executing the command, Streamlit starts a local web server where we can test and interact with the dashboard.

Step 11: Publishing the Project on GitHub

A public repository is important because it allows other developers to inspect, reproduce, and improve the project.

After creating a new GitHub repository, we can upload the project using Git:

git init
git add .
git commit -m "Initial Streamlit dashboard"
git branch -M main
git remote add origin https://github.com/YOUR-USERNAME/sales-dashboard.git
git push -u origin main

Step 12: Automation with GitHub Actions

Publishing code is not enough.

We also want an automated process that verifies that the application can be installed and that the Python code is valid whenever changes are pushed to the repository.

For this purpose, we can use GitHub Actions.

Create the following file:

.github/workflows/python-app.yml

Add:

name: Streamlit Dashboard CI

on:
  push:
    branches: ["main"]

  pull_request:
    branches: ["main"]

jobs:

  test-dashboard:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Check Python syntax
        run: |
          python -m py_compile app.py

Now every push or Pull Request to the main branch automatically executes the workflow.

The workflow performs three important tasks:

Downloads the repository.
Creates the Python environment and installs the dependencies.
Checks that the application does not contain Python syntax errors.

If something is wrong, GitHub Actions marks the workflow as failed.

This provides a simple Continuous Integration (CI) process for our dashboard.

Step 13: Deploying to Streamlit Community Cloud

Now comes the most important part: making the dashboard publicly accessible.

Streamlit Community Cloud can deploy Streamlit applications directly from GitHub.

The deployment process is:

Push the complete application to GitHub.
Sign in to Streamlit Community Cloud.
Connect the GitHub account.
Select the dashboard repository.
Select the main branch.
Specify app.py as the application entry point.
Deploy the application.

The platform installs the dependencies contained in requirements.txt and starts the Streamlit application.

Once deployed, the dashboard receives a public address similar to:

https://your-dashboard.streamlit.app

Step 14: Continuous Deployment

Our development workflow now becomes:

Developer
    ↓
Git Push
    ↓
GitHub Repository
    ↓
GitHub Actions
    ↓
Validation
    ↓
Streamlit Community Cloud
    ↓
Public Dashboard

GitHub acts as the source of truth for the application.

When we update the project and push the changes to GitHub, our automated GitHub Actions workflow validates the application.

The deployed Streamlit application can then reflect the new version stored in the repository.

This approach gives us a simple CI/CD workflow without needing to manually upload application files every time we make a change.

Conclusion

Building a dashboard is not only about creating charts.

A complete modern data project also involves version control, automation, deployment, and accessibility.

Using Pandas and Plotly, we transformed raw sales information into meaningful visualizations. Streamlit allowed us to transform those visualizations into an interactive web application without developing a traditional frontend.

GitHub provided version control and a public repository, while GitHub Actions added automated validation to the development process.

Finally, Streamlit Community Cloud allowed us to transform a local Python project into a publicly accessible web application.

The complete workflow demonstrates how modern development and data visualization tools can work together:

Data → Analysis → Visualization → Application → Automation → Cloud Deployment

Instead of sharing static screenshots or notebooks, we now have a real interactive dashboard that anyone can access from a browser.

👁️ Stop Flying Blind: Implementing Observability Practices in Production (Python, Prometheus & Grafana)

ROBERTO CARLOS HUAMAN RIVERA — Sun, 05 Jul 2026 14:37:43 +0000

Have you ever been woken up at 3:00 AM because "the server is down," only to spend the next four hours grepping through messy text files trying to figure out why?

In modern distributed systems, traditional monitoring (asking "Is the system working?") is no longer enough. We need Observability (asking "Why is the system not working, and where exactly is the bottleneck?").

In this article, we will break down the core practices of Observability and implement a real-world, automated solution using Python (FastAPI), Prometheus, and Grafana.

🏛️ The Three Pillars of Observability

To achieve true observability, your system must emit three types of telemetry data:

Metrics: Numeric representations of data measured over time (e.g., CPU usage, request latency, error rates). They tell you that something is wrong.
Logs: Immutable, timestamped records of discrete events (e.g., "User 123 failed authentication"). They tell you what went wrong.
Traces: A representation of a series of casually related distributed events that encode the end-to-end request flow. They tell you where it went wrong.

💡 Best Practice: The RED Method for Metrics

When instrumenting web services, always follow the RED method for your metrics:

Rate: The number of requests per second.
Errors: The number of those requests that are failing.
Duration: The amount of time those requests take.

🚀 Real-World Example: Instrumenting a FastAPI Application

Let's build a simple e-commerce checkout API and instrument it to expose metrics to Prometheus.

1. The Application Code (`main.py`)

We will use the prometheus_client library to create custom metrics for our API.

# main.py
import time
import random
from fastapi import FastAPI, HTTPException
from prometheus_client import make_asgi_app, Counter, Histogram
import uvicorn

app = FastAPI(title="E-Commerce Checkout API")

# Add Prometheus ASGI middleware to expose /metrics endpoint
metrics_app = make_asgi_app()
app.mount("/metrics", metrics_app)

# Define our Metrics (Following the RED method)
REQUEST_COUNT = Counter(
    'checkout_requests_total', 
    'Total number of checkout requests',
    ['method', 'endpoint', 'status']
)
REQUEST_LATENCY = Histogram(
    'checkout_request_latency_seconds', 
    'Latency of checkout requests in seconds',
    ['endpoint']
)

@app.post("/checkout")
def process_checkout():
    start_time = time.time()

    # Simulate processing time (Duration)
    time.sleep(random.uniform(0.1, 0.5))

    # Simulate a random failure (Errors)
    if random.random() < 0.2:  # 20% failure rate
        REQUEST_COUNT.labels(method='POST', endpoint='/checkout', status='500').inc()
        REQUEST_LATENCY.labels(endpoint='/checkout').observe(time.time() - start_time)
        raise HTTPException(status_code=500, detail="Payment gateway timeout")

    # Success (Rate)
    REQUEST_COUNT.labels(method='POST', endpoint='/checkout', status='200').inc()
    REQUEST_LATENCY.labels(endpoint='/checkout').observe(time.time() - start_time)

    return {"status": "success", "message": "Checkout complete"}

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8000)

2. The Requirements (`requirements.txt`)

fastapi==0.103.1
uvicorn==0.23.2
prometheus-client==0.17.1

🐳 Infrastructure & Orchestration (Docker Compose)

To see our metrics, we need Prometheus to scrape our app, and Grafana to visualize it. We can spin up the entire observability stack locally using docker-compose.yaml.

# docker-compose.yaml
version: '3.8'

services:
  api:
    build: .
    ports:
      - "8000:8000"

  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    depends_on:
      - prometheus

Prometheus Config (prometheus.yml):

scrape_configs:
  - job_name: 'fastapi_app'
    scrape_interval: 5s
    static_configs:
      - targets: ['api:8000']

When you run docker-compose up, Prometheus will automatically hit http://api:8000/metrics every 5 seconds, and you can build beautiful dashboards in Grafana (http://localhost:3000) showing your exact API error rates and latency!

☁️ Automation: Enforcing Code Quality with CI/CD

Observability starts with good code. Let's ensure our instrumented app builds correctly before merging. Here is our GitHub Actions pipeline (.github/workflows/ci.yml):

name: CI/CD Observability API

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
          pip install flake8

      - name: Lint Code
        run: flake8 main.py --count --select=E9,F63,F7,F82 --show-source --statistics

      - name: Build Docker Image
        run: docker build -t my-observable-api:latest .

🎯 Conclusion

By instrumenting our code from day one, we transition from reactive firefighting to proactive engineering. Using the RED method alongside Prometheus and Grafana ensures that when our API starts slowing down or failing, we don't have to guess why—the dashboard will tell us exactly what is happening.

How do you handle observability in your projects? Let me know in the comments! 👇

📊 Beyond the Basics: Building and Deploying Interactive Python Dashboards (Streamlit, Dash, & Bokeh)

ROBERTO CARLOS HUAMAN RIVERA — Sun, 03 May 2026 00:34:12 +0000

When we talk about Data Visualization and Dashboards, enterprise tools like Tableau or PowerBI often dominate the conversation. However, for Data Scientists and Developers, these GUI-based tools can feel restrictive. What if you need complex machine learning integration, custom UI logic, or automated CI/CD deployments?

Enter the holy trinity of Python visualization tools: Streamlit, Dash, and Bokeh.

In this article, we will explore the differences between these powerful frameworks, build a real-world financial dashboard, and completely automate its deployment to the Cloud using Docker and GitHub Actions.

🛠️ The Contenders: Streamlit vs. Dash vs. Bokeh

Before writing code, let's understand which tool fits your use case:

1. Streamlit (The Sprinter) 🏃‍♂️

Streamlit turns data scripts into shareable web apps in minutes. All in pure Python. No frontend experience required.

Best for: Rapid prototyping, internal tools, and quick data exploration.
Pros: Incredibly low learning curve, fully reactive script execution.

2. Plotly Dash (The Architect) 🏢

Dash is written on top of Flask, Plotly.js, and React.js. It requires more boilerplate than Streamlit but offers enterprise-grade customization.

Best for: Production-grade analytics dashboards with complex layouts and interactivity.
Pros: Highly customizable UI, stateless callback architecture perfect for scaling.

3. Bokeh (The Artist) 🎨

Bokeh targets modern web browsers for presentation, providing elegant, concise construction of versatile graphics.

Best for: Massive datasets, streaming data, and highly custom interactive plots.
Pros: Incredible granularity over how visualizations render in the DOM.

🚀 Building a Real-World Example: A Stock Market Dashboard with Streamlit

Because we want to move from zero to deployed as fast as possible, we will use Streamlit to build a dynamic Stock Price Explorer.

The Application Code (`app.py`)

This simple script downloads historical financial data, visualizes it, and calculates moving averages interactively.

# app.py
import streamlit as st
import pandas as pd
import numpy as np

# Page configuration
st.set_page_config(page_title="Financial Dashboard", page_icon="📈", layout="wide")

st.title("📈 Interactive Financial Explorer")
st.markdown("Built with **Streamlit** to demonstrate rapid dashboard development.")

# Sidebar for user inputs
st.sidebar.header("User Parameters")
ticker = st.sidebar.selectbox("Select Asset", ("AAPL", "GOOGL", "MSFT", "BTC-USD"))
days = st.sidebar.slider("Number of days", 10, 365, 100)
ma_window = st.sidebar.number_input("Moving Average Window", 5, 50, 20)

# Simulate fetching data (Replacing heavy API calls for this demo)
@st.cache_data
def get_data(ticker, days):
    dates = pd.date_range(end=pd.Timestamp.today(), periods=days)
    prices = np.random.normal(loc=150, scale=10, size=days)
    df = pd.DataFrame({'Date': dates, 'Price': prices})
    df.set_index('Date', inplace=True)
    return df

data = get_data(ticker, days)
data['Moving Average'] = data['Price'].rolling(window=ma_window).mean()

# Visualization
st.subheader(f"Price History for {ticker}")
st.line_chart(data[['Price', 'Moving Average']])

# Raw Data Table
with st.expander("Show Raw Data"):
    st.dataframe(data.tail(10))

The Dependencies (`requirements.txt`)

streamlit==1.31.0
pandas==2.2.0
numpy==1.26.3

☁️ Deployment & Automation (CI/CD)

To make this a professional-grade project, we won't just run it on localhost. We will containerize it with Docker and automate its deployment using GitHub Actions.

Step 1: Containerizing the App (`Dockerfile`)

Create a file named Dockerfile in the root directory:

FROM python:3.10-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 8501

HEALTHCHECK CMD curl --fail http://localhost:8501/_stcore/health

ENTRYPOINT ["streamlit", "run", "app.py", "--server.port=8501", "--server.address=0.0.0.0"]

Step 2: GitHub Actions Automation (`.github/workflows/deploy.yml`)

We will set up a pipeline that lints our Python code and pushes the Docker container to GitHub Packages (which can then be pulled by any cloud provider like AWS, Render, or DigitalOcean).

name: Deploy Streamlit Dashboard

on:
  push:
    branches: [ "main" ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

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

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies and Lint
        run: |
          pip install flake8
          flake8 app.py --count --select=E9,F63,F7,F82 --show-source --statistics

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository_owner }}/financial-dashboard:latest

Every time you push to the main branch, GitHub Actions will automatically check your code for errors, build the Docker container, and host it on the cloud!

🎯 Conclusion

While Tableau and PowerBI are fantastic, code-based visualization tools like Streamlit, Dash, and Bokeh unlock infinite potential for data scientists. By leveraging Python, we can integrate machine learning models, build custom UIs, and seamlessly deploy our applications into modern DevOps pipelines.

🚀 Spec-Driven Development (SDD): Building Robust Software Before Writing a Single Line of Logic

ROBERTO CARLOS HUAMAN RIVERA — Sun, 03 May 2026 00:28:32 +0000

Have you ever spent weeks building a backend API, only to have the frontend team tell you, "Wait, this isn't the data format we agreed on"?

In traditional "code-first" development, developers jump straight into writing logic. The documentation and contracts are treated as an afterthought. This leads to broken integrations, endless debugging, and frustrated teams. Enter Spec-Driven Development (SDD) (also known as API-First Design).

In SDD, you write the Specification (the contract) before you write any code. This spec becomes the single source of truth for your backend, frontend, and QA teams.

In this article, we will explore SDD using a real-world example: building a Task Management API using OpenAPI (Swagger), Node.js, and automating the validation process using GitHub Actions.

🏗️ The Real-World Example: A Task Management API

Imagine we are building a simple system to manage daily tasks. Instead of opening index.js and writing Express routes, we start by writing an OpenAPI specification.

Step 1: Writing the Specification (The Contract)

We define our API contract in a file called openapi.yaml. This file dictates exactly what the endpoints are, what data they require, and what they will return.

# openapi.yaml
openapi: 3.0.0
info:
  title: "Task Management API"
  version: 1.0.0
  description: "A simple API to manage tasks, built with Spec-Driven Development."
paths:
  /tasks:
    get:
      summary: Get all tasks
      responses:
        '200':
          description: "A list of tasks"
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Task'
    post:
      summary: Create a new task
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/NewTask'
      responses:
        '201':
          description: "Task created successfully"

components:
  schemas:
    Task:
      type: object
      required: [id, title, completed]
      properties:
        id:
          type: string
          format: uuid
        title: ""
          type: string
        completed:
          type: boolean
    NewTask:
      type: object
      required: [title]
      properties:
        title: ""
          type: string
          minLength: 3

By writing this first, the frontend team can immediately start building the UI using mock servers, while the backend team starts implementing the logic.

Step 2: Implementation (The Code)

Now that we have our contract, we will write our backend. To make this truly Spec-Driven, we won't just write code that hopefully matches the spec; we will use a library called express-openapi-validator to force our code to obey the spec.

Here is the Node.js implementation:

// index.js
const express = require('express');
const path = require('path');
const OpenApiValidator = require('express-openapi-validator');

const app = express();
app.use(express.json());

// 1. Install the OpenAPI Validator middleware
// This automatically reads our openapi.yaml and validates all incoming requests
app.use(
  OpenApiValidator.middleware({
    apiSpec: path.join(__dirname, 'openapi.yaml'),
    validateRequests: true, // Fail if request doesn't match spec
    validateResponses: true // Fail if our server sends a bad response
  })
);

// 2. Dummy Database
let tasks = [
    { id: "123e4567-e89b-12d3-a456-426614174000", title: "Learn SDD", completed: false }
];

// 3. Define Routes
app.get('/tasks', (req, res) => {
  res.status(200).json(tasks);
});

app.post('/tasks', (req, res) => {
  // We don't need to write validation logic like `if(!req.body.title)`!
  // The OpenAPI validator already checked it against the YAML spec.
  const newTask = {
      id: "987e6543-e21b-34d3-b123-426614174111", // In reality, generate a UUID
      title: req.body.title,
      completed: false
  };
  tasks.push(newTask);
  res.status(201).json(newTask);
});

// 4. Error Handler for Validation Errors
app.use((err, req, res, next) => {
  res.status(err.status || 500).json({
    message: err.message,
    errors: err.errors,
  });
});

app.listen(3000, () => {
  console.log('Server running on port 3000. Protected by OpenAPI!');
});

Because of SDD, if a client tries to send {"title": "ab"} (which violates the minLength: 3 rule in our YAML), the server will automatically reject it with a 400 Bad Request. No extra code required!

Step 3: GitHub Version Control & Automation (CI/CD)

To achieve maximum efficiency (and max points for your assignment!), your code must live in a Version Control System (GitHub) with Automation.

The Repository Structure:

my-sdd-project/
├── .github/
│   └── workflows/
│       └── lint-spec.yml   <-- CI/CD Automation
├── package.json
├── index.js                <-- Application Code
└── openapi.yaml            <-- The Specification

The Automation:
We want to ensure that nobody merges a broken API specification into the main branch. We can automate this using GitHub Actions and a tool called Spectral (a JSON/YAML linter for APIs).

Create a file at .github/workflows/lint-spec.yml:

name: Lint OpenAPI Spec

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  validate-spec:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install Spectral
        run: npm install -g @stoplight/spectral-cli

      - name: Lint OpenAPI Document
        run: spectral lint openapi.yaml --ruleset spectral:oas

What does this automation do?
Every time a developer makes a Pull Request, GitHub Actions will spin up a server, read the openapi.yaml file, and check it for errors, missing descriptions, or bad formatting. If the spec is broken, the code cannot be merged.

Conclusion

Spec-Driven Development shifts the focus from writing code to designing architecture. By treating the Specification as a first-class citizen and automating its validation via CI/CD pipelines, teams can eliminate miscommunications, reduce bugs, and deliver higher-quality software significantly faster.

Remember: Design first, code second.

Code That Lasts: Mastering Software Design Principles (with Golang)

ROBERTO CARLOS HUAMAN RIVERA — Sun, 03 May 2026 00:21:09 +0000

Have you ever looked at code you wrote six months ago and thought: "Who wrote this monster?"? Relax, it happens to all of us.

In software engineering, writing code that a machine understands is the easy part. The real challenge is writing code that other humans (including your future self) can understand, maintain, and scale. This is exactly where Software Design Principles come into play.

In this extensive article, we are going to break down the fundamental design principles (SOLID, DRY, KISS, YAGNI) and apply them to a real-world scenario using Golang.

Grab your cup of coffee ☕, open your favorite editor, and let's get to it!

🧭 1. The Three Musketeers of Clean Code: KISS, YAGNI, and DRY

Before diving into complex architectures, we need to master the baseline philosophy. These three acronyms are your first line of defense against "spaghetti code."

💋 KISS: Keep It Simple, Stupid

Complexity is the enemy of maintainability. If you have to read a function five times to understand what it does, it's not clever; it's unnecessarily complex.

Symptom of violation: 300-line functions, multiple nested loops, variables with cryptic names (x, val, data2).
The solution: Divide and conquer. Write declarative code whenever possible.

🔮 YAGNI: You Aren't Gonna Need It

Developers are often frustrated fortune tellers. We frequently build abstractions for use cases that might happen in the future. 99% of the time, those cases never arrive, and we are left with dead, abstract code that only causes confusion.

Golden rule: Implement things when you actually need them, never when you just foresee needing them.

🌵 DRY: Don't Repeat Yourself

Every piece of knowledge or logic must have a single, unambiguous representation within a system.

Watch out for "False Duplication": Not all code that looks the same violates DRY. If two identical blocks of code change for entirely different reasons (they belong to different business domains), merging them can accidentally couple the system.

🏛️ 2. The Heart of Design: The S.O.L.I.D. Principles

Proposed by Robert C. Martin (Uncle Bob), these five principles are the compass for object-oriented programming and structured system design. Golang is not a traditional object-oriented language (it doesn't have classes or inheritance), but its use of structs and interfaces makes it a brilliant candidate for SOLID.

[S] Single Responsibility Principle (SRP)

A struct, package, or function should have one, and only one, reason to change.

❌ Bad Design: A service that calculates taxes and also sends emails.
✅ Good Design:

// 📦 package: order
type OrderProcessor struct {
    // Pure order logic
}

// 📦 package: notification
type EmailSender struct {
    // Pure email sending logic
}

[O] Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification.

Instead of modifying existing code (and risking breaking it) every time there is a new requirement, you should be able to add new behavior by extending the code. In Go, we achieve this using Interfaces.

[L] Liskov Substitution Principle (LSP)

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

In Go, this means that any type implementing an interface must fulfill the "contract" of that interface without causing hidden panics or unexpected behaviors.

[I] Interface Segregation Principle (ISP)

Clients should not be forced to depend upon interfaces that they do not use.

Visual Outline of the Principle:

[Client A] ---X---> (Giant Interface: Read(), Write(), Delete(), Audit())
                 |
[Client A] -------> (Small Interface: Read())

In Go, small interfaces (1 to 3 methods) are the norm. Think of io.Reader or io.Writer.

[D] Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Inverting the dependency means that your business logic dictates the contracts (interfaces), and the infrastructure (databases, external APIs) adapts to them.

🚀 3. Real-World Case: A Payment Processing System in Golang

Let's see all of this in action. Imagine we work at an e-commerce company and we need to process payments.

🚨 Scenario 1: Spaghetti Code (Violating the principles)

Look at this code. Changing anything here is a nightmare. If we want to add "Cryptocurrency" payments, we have to modify the main function, violating OCP and SRP.

package main

import "fmt"

type PaymentProcessor struct{}

// Massive violation of SRP and OCP
func (p *PaymentProcessor) Process(amount float64, method string) {
    if method == "credit_card" {
        fmt.Printf("Connecting to Card API... paying $%.2f\n", amount)
        // 100 lines of HTTP logic...
    } else if method == "paypal" {
        fmt.Printf("Connecting to PayPal... paying $%.2f\n", amount)
        // Another 100 lines of SDK logic...
    }

    // SRP Violation: The payment processor also saves to the DB
    fmt.Println("Saving transaction to MySQL...")
}

✨ Scenario 2: Clean Architecture using SOLID (The Golang Way)

Let's refactor this monster by applying Small Interfaces (ISP), Dependency Inversion (DIP), and keeping it Closed for modification (OCP).

Step 1: Define the Abstractions (Contracts)

We create clear interfaces. The order system doesn't need to know how the payment is processed or how it's saved.

package payment

// ISP: Small, focused interfaces
type Payer interface {
    Pay(amount float64) error
}

type TransactionRepository interface {
    Save(amount float64, status string) error
}

Step 2: Implement the Details (Low Level)

Now we create concrete structs for each payment method. If tomorrow we need Apple Pay, we just create a new struct. The existing code remains untouched! (OCP).

package payment

import "fmt"

// Credit Card Implementation
type CreditCard struct {
    Token string
}

func (cc *CreditCard) Pay(amount float64) error {
    fmt.Printf("💳 Processing $%.2f via Credit Card...\n", amount)
    return nil
}

// PayPal Implementation
type PayPal struct {
    Email string
}

func (pp *PayPal) Pay(amount float64) error {
    fmt.Printf("🅿️ Processing $%.2f via PayPal...\n", amount)
    return nil
}

// Database Implementation
type MySQLRepository struct{}

func (db *MySQLRepository) Save(amount float64, status string) error {
    fmt.Printf("💾 Saving transaction of $%.2f in the MySQL DB...\n", amount)
    return nil
}

Step 3: The High-Level Module (Dependency Inversion)

Our core service now depends on abstractions, not on concrete details.

package payment

import "fmt"

// CheckoutService coordinates the operation, but ignores the details
type CheckoutService struct {
    paymentMethod Payer                  // Injected Dependency
    repository    TransactionRepository  // Injected Dependency
}

// Constructor to ensure we inject the dependencies
func NewCheckoutService(p Payer, r TransactionRepository) *CheckoutService {
    return &CheckoutService{
        paymentMethod: p,
        repository:    r,
    }
}

func (c *CheckoutService) Checkout(amount float64) {
    err := c.paymentMethod.Pay(amount)
    if err != nil {
        fmt.Println("❌ Payment error")
        return
    }

    c.repository.Save(amount, "SUCCESS")
    fmt.Println("✅ Checkout completed successfully")
}

Step 4: Putting it all together in `main`

The "magic" happens when assembling the pieces.

package main

import (
    "example/payment" // Assuming this is the package path
    "fmt"
)

func main() {
    // 1. Instantiate the infrastructure (Low Level)
    db := &payment.MySQLRepository{}

    fmt.Println("--- Client 1 chooses Card ---")
    cc := &payment.CreditCard{Token: "tok_123"}
    checkout1 := payment.NewCheckoutService(cc, db)
    checkout1.Checkout(150.50)

    fmt.Println("\n--- Client 2 chooses PayPal ---")
    paypal := &payment.PayPal{Email: "user@test.com"}
    checkout2 := payment.NewCheckoutService(paypal, db)
    checkout2.Checkout(89.99)
}

Resulting Architecture Outline:

+-----------------------+       +-------------------+       +-----------------------+
|  High-Level Module    |       |    Abstraction    |       |   Low-Level Module    |
|-----------------------|       |-------------------|       |-----------------------|
|                       |       |                   |       |                       |
|   CheckoutService     | ----->|   Payer (Int.)    |<----- |   CreditCard (Struct) |
|                       |       |                   |       |                       |
+-----------------------+       +-------------------+       +-----------------------+

🎯 Conclusion: Why go through this trouble?

At first glance, applying these principles (especially SOLID) seems to generate more code. And technically, it's true: we went from 1 file and 20 lines to multiple files and structs.

However, the goal of Software Design is not to write less code, but to write code that is highly cohesive and loosely coupled.

Thanks to this design in Go:

Testing: We can easily mock payments and the database using interfaces, allowing for lightning-fast unit tests.
Teamwork: One developer can work on PayPal while another works on CreditCard without running into Git conflicts.
Maintainability: If there is a bug in card processing, we know exactly which file to look at, without fear of breaking the PayPal logic.

Code is like a house. If you build on mud (coupled code), any future renovation will tear down the walls. If you build on a solid foundation (design principles), you can add infinite floors to your skyscraper.

DEV Community: ROBERTO CARLOS HUAMAN RIVERA

🚀 Building and Deploying an Interactive Data Dashboard with Streamlit, Plotly and GitHub Actions

📊 The Project: Sales Analytics Dashboard

Step 1: Project Structure

Step 2: Creating the Dataset

Step 3: Building the Streamlit Application

Step 4: Loading and Preparing the Data

Step 5: Adding Interactive Filters

Step 6: Creating KPI Metrics

Step 7: Revenue by Category

Step 8: Monthly Sales Trend

Step 9: Sales by Region

Step 10: Displaying the Raw Data

🧩 Complete Application

Step 11: Publishing the Project on GitHub

Step 12: Automation with GitHub Actions

Step 13: Deploying to Streamlit Community Cloud

Step 14: Continuous Deployment

Conclusion

👁️ Stop Flying Blind: Implementing Observability Practices in Production (Python, Prometheus & Grafana)

🏛️ The Three Pillars of Observability

💡 Best Practice: The RED Method for Metrics

🚀 Real-World Example: Instrumenting a FastAPI Application

1. The Application Code (main.py)

2. The Requirements (requirements.txt)

🐳 Infrastructure & Orchestration (Docker Compose)

☁️ Automation: Enforcing Code Quality with CI/CD

🎯 Conclusion

📊 Beyond the Basics: Building and Deploying Interactive Python Dashboards (Streamlit, Dash, & Bokeh)

🛠️ The Contenders: Streamlit vs. Dash vs. Bokeh

1. Streamlit (The Sprinter) 🏃‍♂️

2. Plotly Dash (The Architect) 🏢

3. Bokeh (The Artist) 🎨

🚀 Building a Real-World Example: A Stock Market Dashboard with Streamlit

The Application Code (app.py)

The Dependencies (requirements.txt)

☁️ Deployment & Automation (CI/CD)

Step 1: Containerizing the App (Dockerfile)

Step 2: GitHub Actions Automation (.github/workflows/deploy.yml)

🎯 Conclusion

🚀 Spec-Driven Development (SDD): Building Robust Software Before Writing a Single Line of Logic

🏗️ The Real-World Example: A Task Management API

Step 1: Writing the Specification (The Contract)

Step 2: Implementation (The Code)

Step 3: GitHub Version Control & Automation (CI/CD)

Conclusion

Code That Lasts: Mastering Software Design Principles (with Golang)

🧭 1. The Three Musketeers of Clean Code: KISS, YAGNI, and DRY

💋 KISS: Keep It Simple, Stupid

🔮 YAGNI: You Aren't Gonna Need It

🌵 DRY: Don't Repeat Yourself

🏛️ 2. The Heart of Design: The S.O.L.I.D. Principles

[S] Single Responsibility Principle (SRP)

[O] Open/Closed Principle (OCP)

[L] Liskov Substitution Principle (LSP)

[I] Interface Segregation Principle (ISP)

[D] Dependency Inversion Principle (DIP)

🚀 3. Real-World Case: A Payment Processing System in Golang

🚨 Scenario 1: Spaghetti Code (Violating the principles)

✨ Scenario 2: Clean Architecture using SOLID (The Golang Way)

Step 1: Define the Abstractions (Contracts)

Step 2: Implement the Details (Low Level)

Step 3: The High-Level Module (Dependency Inversion)

Step 4: Putting it all together in main

🎯 Conclusion: Why go through this trouble?

1. The Application Code (`main.py`)

2. The Requirements (`requirements.txt`)

The Application Code (`app.py`)

The Dependencies (`requirements.txt`)

Step 1: Containerizing the App (`Dockerfile`)

Step 2: GitHub Actions Automation (`.github/workflows/deploy.yml`)

Step 4: Putting it all together in `main`