DEV Community: Darsh Ayde

DiagramFlow: Turning Whiteboard Sketches into Deterministic Mermaid Diagrams with Gemma 4

Darsh Ayde — Sun, 18 Oct 2026 13:35:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Every engineering team has experienced this: you spend an hour in an energetic whiteboard session designing a microservice architecture, a distributed auth flow, or a database schema. At the end of the meeting, someone takes a smartphone photo of the whiteboard with glare, uneven fluorescent lighting, and faint dry-erase markers.

Then comes the painful part: the post-meeting tax.

Someone—usually a senior developer or solutions architect—spends 45 to 60 minutes manually transcribing boxes, diamonds, and arrow labels into Draw.io, Lucidchart, or Mermaid syntax so the architecture can be documented in Git and Confluence. Alternatively, the photo gets tossed into a Slack thread and is forgotten forever.

DiagramFlow turns whiteboard photos, hand-drawn paper sketches, and architecture drafts into clean, editable, and deterministic Mermaid.js diagrams in seconds.

flowchart LR
    A["Whiteboard / Sketch Image"] --> B["In-Memory Preprocessing\n(Auto-contrast & Grayscale)"]
    B --> C["Vision AI (Gemma 4)\nGemini API / OpenRouter"]
    C --> D["Intermediate Graph JSON\n(Strict Pydantic Schema + Confidence)"]
    D --> E["Deterministic Compiler\n(Pure Python Function)"]
    E --> F["Rendered Mermaid Diagram\n(Interactive Canvas · SVG · PNG)"]

Who Would Pay For It? (The Side Hustle Thesis)

Target Customers: Solutions architects, freelance technical consultants, engineering managers, dev agencies, and developer relations teams who produce system architecture documentation weekly.
The ROI Calculation: Senior engineers cost \$80–\$150/hour. If a consultant runs 3–4 architecture design sessions a month, they burn 3+ billable hours just redrawing boxes and arrows. DiagramFlow cuts that to 10 seconds.
Pricing & Monetization Model:
1. Freelancer / Pro Tier (\$12 / month): Unlimited whiteboard-to-Mermaid conversions, high-resolution SVG and 2x crisp PNG exports, and 1-click Markdown copying.
2. Agency & Team Tier (\$29 / seat / month): Shared team diagram workspaces, custom company Mermaid styling themes, and direct GitHub/GitLab PR integration for living documentation.
3. Pay-as-you-go API (\$0.05 / diagram): Headless extraction endpoint for Obsidian plugins, Notion integrations, and internal Slack bots.

Saving just 30 minutes of a developer's time pays for the tool for an entire month.

Demo

Experience DiagramFlow in action:

Live URL: https://diagramflow-okft.vercel.app/
Local Quickstart:

  # 1. Clone & setup backend
  git clone https://github.com/Pixie2468/diagramflow.git
  cd diagramflow/backend
  pip install -r requirements.txt
  uvicorn src.backend.main:app --port 8000

  # 2. Launch React 19 Frontend
  cd ../frontend && npm install && npm run dev

What the User Experience Looks Like:

Drop Any Image: Drag and drop a phone photo of a whiteboard flowchart, sequence diagram, database ER schema, or UML class diagram (PNG, JPEG, WebP up to 10 MB).
Instant Vision Perception: Gemma 4 identifies nodes, shapes, connectors, and directionality.
Interactive Workspace: Pan, zoom, and inspect your diagram rendered live via Mermaid.js 12.
Local Ambiguity Resolution: If an arrow in your sketch was smudged, DiagramFlow flags it with candidate alternative connections that you can toggle locally in 0ms without re-running the AI model.
Export Ready: 1-click copy of standard Mermaid markdown, or direct download as scalable SVG or crisp 2x PNG.

Code

Pixie2468 / diagramflow

DiagramFlow

Turn whiteboard photos, hand-drawn sketches, and architecture drafts into clean, editable, and deterministic Mermaid diagrams.

Overview

Whiteboard photos and whiteboard sketches are notoriously tricky for AI vision models: uneven lighting, glare, low contrast, messy handwriting, and ambiguous connectors make directly generating raw diagram syntax error-prone and brittle.

DiagramFlow solves this with a three-stage pipeline:

flowchart LR
    A["📷 Whiteboard / Sketch Image"] --> B["⚙️ In-Memory Preprocessing\n(Auto-contrast & Grayscale)"]
    B --> C["🧠 Vision AI (Gemma 4)\nGemini API / OpenRouter"]
    C --> D["📐 Intermediate Graph JSON\n(Strict Pydantic Schema + Confidence)"]
    D --> E["⚡ Deterministic Compiler\n(Pure Function)"]
    E --> F["📊 Rendered Mermaid Diagram\n(Interactive Canvas · SVG · PNG)"]

</div>

Pre-processing: Normalizes contrast and converts to grayscale in-memory via Pillow to make faint marker strokes pop.
Intermediate Graph Extraction: Instructs vision models (Gemma 4 via Gemini or OpenRouter) to extract structured nodes, shapes, connectors, confidence scores, and alternative candidates rather than…

View on GitHub

Key Architectural Highlights:

backend/src/backend/compiler.py: Pure Python deterministic compiler converting graph data structures into valid Mermaid syntax.
backend/src/backend/models.py: Pydantic v2 discriminated union schemas guaranteeing structural validation, shape classifications, and edge confidence.
backend/src/backend/providers.py: Multi-backend driver layer integrating Google's open-weights Gemma 4 (gemma-4-26b-a4b-it and gemma-4-31b-it).
backend/src/backend/image_processing.py: In-memory Pillow contrast normalization for faint whiteboard marker strokes.
frontend/src/App.tsx: Modern React 19, Tailwind CSS v4, and Mermaid.js interactive canvas with SVG/PNG rasterization.

How I Built It

The Open-Source AI Engine: Gemma 4

DiagramFlow is powered by Google's Gemma 4 open-weights multimodal models (gemma-4-26b-a4b-it and gemma-4-31b-it).

The Core Architectural Problem: Why Direct LLM Output Fails

When developers try building diagram tools, the naive approach is: Take image -> prompt model: "Give me Mermaid markdown" -> render in browser.

This fails in production. Whiteboards have crossed lines, smudged text, and ambiguous arrowheads. When an LLM outputs raw Mermaid syntax directly:

It combines perception, syntax formatting, and error-repair into a single brittle string output.
It hallucinates syntax tokens (like mixing brackets [{"label"}] or missing end tags on subgraphs), completely crashing Mermaid's parser.
Any minor mistake requires re-running the entire multimodal model, introducing latency and billing costs.

The Three-Stage Decoupled Pipeline

To solve this, DiagramFlow decouples vision perception from syntax compilation:

Stage 1: In-Memory Preprocessing (Pillow) Whiteboard photos suffer from low contrast, phone camera glare, and washed-out dry-erase markers. Before inference, the image is contrast-stretched and normalized to grayscale purely in-memory.
Stage 2: Structured Graph Extraction (Gemma 4 + Pydantic Contract) Gemma 4 is instructed to output a strict, typed JSON intermediate schema (DiagramGraph):

   {
     "diagram_type": "flowchart",
     "direction": "TD",
     "nodes": [
       { "id": "auth", "label": "Auth Service", "shape_type": "rectangle" },
       { "id": "db", "label": "User DB", "shape_type": "cylinder" }
     ],
     "edges": [
       { "source": "auth", "target": "db", "style": "solid", "confidence": "high", "alternatives": [] }
     ]
   }

If an edge is ambiguous, Gemma 4 assigns confidence: "low" and populates alternatives. Pydantic validates the response before any syntax is created.

Stage 3: Deterministic Pure Compiler A pure-Python compiler translates the validated graph into Mermaid markdown. The compiler handles HTML escaping, node shapes (rectangles, diamonds, cylinders, hexagons), subgraphs, and connection styles. Because the compiler is a pure function, client-side edits recompile in sub-milliseconds without calling the AI model again.

Multi-Diagram Support Out of the Box

Flowcharts & Architecture (flowchart TD | LR): VPCs, subgraphs, edge labels, and 6 node shapes.
Sequence Diagrams (sequenceDiagram): Lifelines, synchronous calls, asynchronous replies, and autonumbering.
Entity-Relationship Diagrams (erDiagram): Database tables, typed fields, Primary/Foreign keys (PK, FK), and cardinalities (1:1, 1:N, M:N).
UML Class Diagrams (classDiagram): Classes, methods, attributes, and relationships (inheritance <|--, composition *--, aggregation o--).

Why Does Open Innovation Matter?

Open innovation and open-weight models like Gemma 4 are not just an alternative to closed APIs—they are the fundamental requirement that makes DiagramFlow viable as a privacy-respecting, profitable business:

Architecture Confidentiality & Data Sovereignty: Whiteboards contain sensitive intellectual property: proprietary authentication logic, internal microservice topographies, and database schemas. Enterprises and engineering consultancies often have strict compliance policies prohibiting internal architecture diagrams from being sent to closed, third-party proprietary APIs that may retain data for model training. Because Gemma 4 is open-weights, DiagramFlow can run inside private customer VPCs, air-gapped on-premise servers, or locally via Ollama/vLLM without a single byte of confidential architectural design leaving the company firewall.
Predictable Unit Economics for a Micro-SaaS: Proprietary vision APIs with fluctuating token pricing create unpredictable cost structures. A single complex high-resolution image can cost \$0.02–\$0.05 on closed multimodal endpoints, eliminating profit margins on an unlimited \$12/mo subscription. With open weights, inference can be hosted on fixed-cost GPU infrastructure (or run directly on developer machines), making unit economics predictable and scalable.
Freedom from API Deprecation and Lock-in: Building on open weights means no sudden vendor deprecations, unexpected pricing hikes, or forced API schema changes. Furthermore, open weights give us the future ability to fine-tune Gemma on domain-specific sketching datasets (like AWS/GCP cloud icon doodles or specialized electrical diagrams)—something closed APIs cannot offer.

My Agent Session

Developing DiagramFlow involved pairing with AI to design the intermediate graph contract, refine Pydantic validation rules, and build out deterministic compiler tests across four diagram specifications.

You can inspect the full curated agent session transcript on DEV:

Building DiagramFlow: Gemma 4 Vision Pipeline & Deterministic Mermaid Compiler

You

We need to turn messy whiteboard diagrams into clean Mermaid syntax using open-weight Gemma 4 vision models. Asking the model to output raw Mermaid directly produces syntax hallucinations and broken syntax on complex connections. How should we structure the architecture?

Agent

Let's decouple perception from syntax generation using a three-stage pipeline:\n1. In-memory image preprocessing (auto-contrast & grayscale via Pillow) to sharpen faint whiteboard strokes.\n2. Open-weight vision extraction (Gemma 4) targeting a strict Pydantic JSON contract (DiagramGraph) with nodes, shapes, connectors, confidence scores, and alternative candidates.\n3. A deterministic pure-Python compiler (compiler.py) that translates the validated graph into guaranteed error-free Mermaid syntax in milliseconds. This also allows the frontend to resolve ambiguous connections locally without re-running inference.

You

Let's implement the deterministic compiler and Pydantic schema supporting Flowcharts, Sequence Diagrams, ER Diagrams, and UML Class Diagrams.

Agent

Implemented the pure-Python deterministic compiler in backend/src/backend/compiler.py and models in backend/src/backend/models.py. Validated with comprehensive unit tests for all diagram types, escaping HTML/special characters, and ensuring privacy-first in-memory processing.

Direct Session Link: View Agent Session on DEV

My First User

To test whether real developers would actually find this valuable, I shared DiagramFlow with Aryan.

Alex had just wrapped up a 45-minute discovery call where he sketched an event-driven payment reconciliation pipeline on an office whiteboard. Normally, he spends his Friday afternoons manually redrawing these diagrams in Draw.io before submitting formal client architecture proposals.

The Test

We fed his phone snapshot into DiagramFlow. Within 4 seconds, DiagramFlow recognized the 7 microservice nodes, classified the message queues as cylinder shapes, mapped the payment gateway as an external subgraph, and produced a pristine Mermaid flowchart.

What Alex Said:

"I usually block out 45 minutes after every client workshop just to redraw whiteboard sketches so they look professional in proposal decks. DiagramFlow gave me clean Mermaid code that I dropped directly into my markdown deliverables and rendered as high-res SVGs in under a minute. If you charge \$15 a month for this, I'm buying it today—it pays for itself in the first hour of every sprint."

Prize Categories

Featured Category: Best Use of Gemma

DiagramFlow is built from the ground up around Google's Gemma 4 open-weight multimodal vision models (gemma-4-26b-a4b-it and gemma-4-31b-it). We leverage Gemma 4's spatial perception and structural reasoning to extract complex topological graphs from real-world, hand-drawn sketches, turning messy ink into deterministic, compile-ready code.

Community Wisdom

As highlighted by Eme Gug in Diagrams as Code and Agasta in I got tired of AI diagram slop, raw image diagrams in repositories quickly rot, while prompting LLMs directly for syntax yields broken diagrams. By bridging physical whiteboard sketches with text-based Mermaid code through an intermediate validated graph, DiagramFlow solves both problems simultaneously.

Building KNN from Scratch (Because import sklearn Feels Like Cheating)

Darsh Ayde — Sun, 14 Jun 2026 07:02:50 +0000

Building K-Nearest Neighbors (KNN) From Scratch

Let's be real: in a production machine learning environment, we all just import scikit-learn and call it a day. But treating algorithms like black boxes can come back to bite you when those abstractions leak. Building K-Nearest Neighbors (KNN) from scratch is a fantastic exercise to actually understand the mechanics working under the hood.

At its core, KNN relies on a surprisingly simple geometric premise: a data point probably belongs to the same category as its closest spatial neighbors. Rebuilding this classifier from the ground up forces you to tackle some critical engineering challenges, such as:

Computing spatial geometry efficiently
Managing state during the voting process
Handling edge cases and algorithmic ties deterministically

In this post, we'll walk through the architectural decisions behind a pure Python implementation of KNN, translating textbook math into functional code.

1. The Distance Metric

import math

def _check_length(x, y):
    """Ensure both vectors have the same length."""
    if len(x) != len(y):
        raise ValueError("Vectors must be of same length")

def euclidean_distance(x, y):
    """Compute Euclidean distance between two vectors."""
    _check_length(x, y)

    sum_of_sq = sum(
        (i - j) ** 2
        for i, j in zip(x, y)
    )

    return math.sqrt(sum_of_sq)

The Goal

Calculate spatial similarity between vectors using Euclidean distance.

How It Works

KNN is fundamentally a geometry problem. The entire algorithm hinges on quantifying exactly how far apart points are in a given space.

If we're looking at a 2D plane, Euclidean distance comes straight from the Pythagorean theorem:

d = (x_{1} - x_{2})^{2} + (y_{1} - y_{2})^{2}

In machine learning, however, we're rarely dealing with just two dimensions. Fortunately, the formula generalizes neatly to an arbitrary number of dimensions:

d (x, y) = i = 1 \sum n (x_{i} - y_{i})^{2}

Where:

$n$ is the total number of dimensions.
$x_{i}$ and $y_{i}$ are the coordinates of vectors $x$ and $y$ along dimension $i$ .

In the euclidean_distance() function above, notice the generator expression inside sum(). It evaluates lazily, meaning we avoid constructing an intermediate list of squared differences in memory. This is a deliberate design choice that scales well when working with high-dimensional data.

Also, don't overlook the _check_length() guard—it is structurally critical. Comparing vectors of different dimensions is mathematically invalid. Since Python's zip() function silently truncates to the shortest iterable, omitting this check could allow the function to fail silently and return incorrect results.

2. The Voting Mechanism and Tie-Breakers

def _get_majority_vote(neighbors):
    # ... early-exit validation skipped ...

    vote_count = {}
    min_distance_per_label = {}

    for neighbor in neighbors:
        label = neighbor["label"]
        distance = neighbor["distance"]

        vote_count[label] = vote_count.get(label, 0) + 1

        min_distance_per_label[label] = min(
            distance,
            min_distance_per_label.get(label, float("inf"))
        )

    best_label = None
    best_vote = -1
    best_distance = float("inf")

    for label in vote_count:
        votes = vote_count[label]
        dist = min_distance_per_label[label]

        if votes > best_vote or (
            votes == best_vote and dist < best_distance
        ):
            best_label = label
            best_vote = votes
            best_distance = dist

    return best_label

The Goal

Tally the neighbors' labels to determine the final classification while using spatial proximity as a deterministic tie-breaker.

How It Works

Counting votes is straightforward with a hash map, but robust edge-case management is what separates a demo implementation from production-ready code.

Imagine a scenario where $k = 4$ and your query point sits exactly halfway between two Class A neighbors and two Class B neighbors. A naive implementation might simply choose whichever label appears first. That makes the classifier non-deterministic and biased by data ordering.

To address this, the implementation maintains a secondary dictionary:

min_distance_per_label

As the algorithm iterates through the neighbors, it tracks the minimum distance observed for each class label. If a voting tie occurs,

votes_{A} = votes_{B}

the algorithm chooses the class whose nearest representative is closest to the query point.

Mathematically:

ar g c min (x \in c min d (x, q))

Where:

$c$ is a class label.
$q$ is the query point.
$d (x, q)$ is the distance between a training sample and the query point.

This approach anchors tie-breaking in actual spatial proximity rather than arbitrary ordering or randomness.

3. The Orchestrator

import numpy as np

def knn_predict(training_data, labels, query_point, k):
    # ... input validation skipped ...

    distances = [
        euclidean_distance(sample, query_point)
        for sample in training_data
    ]

    nearest_idx = np.argsort(distances)[:k]

    neighbors = [
        {
            "distance": distances[i],
            "label": labels[i]
        }
        for i in nearest_idx
    ]

    return _get_majority_vote(neighbors)

The Goal

Create a controller function that computes distances, isolates the top $k$ candidates, and delegates classification to the voting logic.

How It Works

Although a production implementation would include comprehensive validation and optimization, the core algorithm relies on one key operation:

np.argsort(distances)[:k]

Keeping multiple arrays synchronized during sorting can quickly become messy. Rather than zipping distances and labels together, sorting them, and then unpacking them again, we sort only the distance values and retrieve the corresponding indices.

numpy.argsort() returns the indices that would sort an array. This allows us to select the nearest neighbors without mutating the original data structures.

Mathematically, we're selecting:

argsort (D)_{1}

where $D$ is the vector of computed distances.

This is a common scientific-computing pattern because it preserves the relationship between distances and labels while avoiding unnecessary data transformations.

After selecting the nearest indices, we package the neighbors into lightweight dictionaries and pass them directly to the voting mechanism.

Final Thoughts

K-Nearest Neighbors is a unique machine learning algorithm because it behaves less like a traditional parameter-learning model and more like a combination of geometric reasoning and voting heuristics.

Unlike algorithms such as linear regression or neural networks, KNN performs no explicit training. It simply stores the dataset and uses distance as a proxy for similarity during prediction.

Building algorithms from scratch is one of the fastest ways to demystify machine learning. You quickly discover that much of the perceived complexity comes from standard software engineering concerns:

Performance optimization
State management
Data validation
Numerical stability

The mathematics matters, but so does thoughtful implementation.

Stop Trusting Every JWT: How I Handle OIDC Claims in My Go Gateway

Darsh Ayde — Thu, 11 Jun 2026 10:06:22 +0000

Building a Secure OIDC Verification Layer in Go

Authentication is one of those things every backend engineer eventually has to build—and secretly dreads getting wrong. When I started architecting the auth layer for my Go API gateway, I naturally reached for OpenID Connect (OIDC). It’s the industry standard, so how hard could it be?

As it turns out, parsing a JWT is trivial. Trusting a JWT is where the trapdoors hide. If you blindly decode a token and trust the payload, you are exactly one spoofed signature away from a major security incident. I needed a way to dynamically discover my identity provider’s keys, cryptographically verify incoming requests, and strictly enforce the claims my backend actually cares about (like ensuring a user actually owns the email address they claim to).

In this post, I’ll walk you through how I built the OIDC verification layer for my gateway. We won't just look at the happy path; we’ll look at why I used interfaces to keep the auth logic mockable, how to avoid network traps during startup, and why an unassuming email_verified pointer is your gateway’s best friend.

High-Level Flow

Before we dive into the Go code, here is the basic verification flow this architecture follows:

Client
  |
  | ID Token (JWT)
  v
API Gateway
  |
  | 1. Discover OIDC provider metadata
  | 2. Verify JWT signature (via JWKS)
  | 3. Validate issuer and audience
  | 4. Extract strongly-typed claims
  | 5. Enforce application-specific rules (e.g., email verification)
  v
Authenticated User

(Note: The complete source code for this example is available on my GitHub: dearai-backend)

Breaking Down the Implementation

Let's look at how this breaks down in Go, starting from the core domain types and moving into runtime validation.

1. Designing for Testability

package auth

import (
    "context"
    "errors"
    "fmt"

    "github.com/coreos/go-oidc/v3/oidc"
)

type TokenVerifier interface {
    Verify(ctx context.Context, tokenString string) (*ExternalClaims, error)
}

Notice that the package exports a TokenVerifier interface rather than forcing consumers to use a concrete struct. This is classic dependency inversion.

When you're writing unit tests for your HTTP handlers or middleware, you really don't want them making live network calls to Google, Okta, or Auth0. By depending on this interface, you can easily inject a mock verifier that simply returns dummy claims for testing, keeping your test suite fast, offline, and deterministic.

2. Defining Expected Claims

type ExternalClaims struct {
    Subject       string `json:"sub"`
    Email         string `json:"email"`
    EmailVerified *bool  `json:"email_verified"`
}

type OIDCVerifier struct {
    verifier *oidc.IDTokenVerifier
}

We map the JWT payload into an ExternalClaims struct. The sub (subject) claim should always be treated as your primary user identifier. It is immutable and stable, making it the perfect key to link to your internal user records. While it's tempting to use the user's email as a unique identifier, emails change, which can break data relationships later.

You'll also notice EmailVerified is defined as a *bool (a pointer to a boolean) rather than a primitive bool. This is a deliberate choice. It allows us to differentiate between a claim that is explicitly set to false and a claim that is completely missing from the token payload (which evaluates to nil). Both scenarios should result in a rejected token, and a pointer allows us to catch both cleanly.

3. Discovery and the Network Trap

func NewOIDCVerifier(ctx context.Context, issuer, clientID string) (TokenVerifier, error) {
    if issuer == "" || clientID == "" {
        return nil, errors.New("issuer and clientID are required")
    }

    provider, err := oidc.NewProvider(ctx, issuer)
    if err != nil {
        return nil, fmt.Errorf("failed to discover OIDC configuration: %w", err)
    }

    return &OIDCVerifier{
        verifier: provider.Verifier(&oidc.Config{ClientID: clientID}),
    }, nil
}

Before any network activity occurs, the constructor validates its inputs to fail fast. Then, we call oidc.NewProvider. This is where OIDC discovery happens. The library hits the issuer's .well-known/openid-configuration endpoint to fetch metadata, including the JWKS (JSON Web Key Set) URL which contains the public keys needed to verify token signatures.

This is the only place in the setup phase where network I/O occurs. Because of this, it is critical to pass a context.Context with a reasonable timeout into this function. If the identity provider goes down during a deployment and you don't have a timeout, your application startup will block indefinitely.

4. The Verification Pipeline

func (v *OIDCVerifier) Verify(ctx context.Context, tokenString string) (*ExternalClaims, error) {
    idToken, err := v.verifier.Verify(ctx, tokenString)
    if err != nil {
        return nil, fmt.Errorf("cryptographic token verification failed: %w", err)
    }

    var claims ExternalClaims
    if err := idToken.Claims(&claims); err != nil {
        return nil, fmt.Errorf("failed to unmarshal token claims: %w", err)
    }

    if claims.Subject == "" {
        return nil, errors.New("invalid token: missing 'sub' claim")
    }

    if claims.Email == "" {
        return nil, errors.New("invalid token: missing 'email' claim")
    }

    if claims.EmailVerified == nil || !*claims.EmailVerified {
        return nil, errors.New("invalid token: email address is unverified")
    }

    return &claims, nil
}

The Verify method acts as our gatekeeper, enforcing rules in a very specific order.

First, we establish cryptographic trust by passing the raw token to v.verifier.Verify(). This leverages the provider's public keys to ensure the signature is mathematically valid, checks that the token hasn't expired, and verifies that the ClientID (Audience) matches your app. This last part is crucial—it prevents your gateway from accepting valid tokens that were actually minted for an entirely different application.

Once we trust the signature, we unmarshal the payload into our ExternalClaims struct to get strongly-typed Go values. Finally, we enforce our business logic trust. We ensure the sub and email aren't blank, and we evaluate that *bool to guarantee the identity provider has verified the user's email. If a token fails any of these steps, execution halts immediately and the request is dropped.

A Quick Note on Token Types

It’s worth mentioning that this specific implementation is designed to verify OIDC ID tokens, which are meant to communicate identity information (who the user is). Access tokens, on the other hand, are meant for API authorization (what the user can do) and often follow different validation rules depending on the provider. Make sure you are verifying the right token for your specific architecture.

Wrapping Up

Verifying an OIDC token requires a lot more rigor than just base64-decoding a JSON payload. By leveraging OIDC discovery and the go-oidc library, we get automatic key rotation handling and cryptographic certainty. Combine that with strictly typed claims and interface-driven design, and you end up with an auth layer that is secure, resilient, and highly testable.

DEV Community: Darsh Ayde

DiagramFlow: Turning Whiteboard Sketches into Deterministic Mermaid Diagrams with Gemma 4

What I Built

Who Would Pay For It? (The Side Hustle Thesis)

Demo

What the User Experience Looks Like:

Code

Pixie2468 / diagramflow

DiagramFlow

Overview

Key Architectural Highlights:

How I Built It

The Open-Source AI Engine: Gemma 4

The Core Architectural Problem: Why Direct LLM Output Fails

The Three-Stage Decoupled Pipeline

Multi-Diagram Support Out of the Box

Why Does Open Innovation Matter?

My Agent Session

My First User

The Test

What Alex Said:

Prize Categories

Featured Category: Best Use of Gemma

Community Wisdom

Building KNN from Scratch (Because import sklearn Feels Like Cheating)

Building K-Nearest Neighbors (KNN) From Scratch

1. The Distance Metric

The Goal

How It Works

2. The Voting Mechanism and Tie-Breakers

The Goal

How It Works

3. The Orchestrator

The Goal

How It Works

Final Thoughts

Further Reading

Stop Trusting Every JWT: How I Handle OIDC Claims in My Go Gateway

Building a Secure OIDC Verification Layer in Go

High-Level Flow

Breaking Down the Implementation

1. Designing for Testability

2. Defining Expected Claims

3. Discovery and the Network Trap

4. The Verification Pipeline

A Quick Note on Token Types

Wrapping Up

Further Reading