DEV Community: Divyanshu Deepam

Documentation is Debt: Why Your Class Diagrams Should Be Executable

Divyanshu Deepam — Mon, 27 Apr 2026 16:40:35 +0000

In high-stakes system design sessions or SDE-2 interview prep, the "Class Diagram" is the hero of the hour. We map out domain logic, define inheritance hierarchies, and establish access modifiers.
Then the meeting ends.

The diagram is pasted into a Confluence page or a README, and there it sits—a static relic of a moment in time. As implementation begins, the developer is forced to pay the "Manual Translation Tax": manually creating files, defining boilerplate fields, implementing getters/setters, and ensuring the inheritance links match the drawing.

This is where architectural entropy starts. The moment code diverges from the diagram, the documentation becomes debt.

I wanted to change that. I wanted the diagram to be the Single Source of Truth for the initial implementation.

Introducing: Executable Architecture in Dev Suite

I’ve integrated a Mermaid Class Diagram to Code Generator into Dev Suite.
The philosophy is simple: If the structure is already defined, the code should be a byproduct, not a chore.

Why Mermaid?

Mermaid has become the industry standard for "Diagrams as Code" because it is:

Versionable: It lives in Git alongside your source code.
Text-Based: No proprietary binary files or drag-and-drop UI lag.
Ubiquitous: Native support in GitHub, GitLab, and most modern wikis.

The Real Friction: Moving Beyond Visualization

Imagine this Mermaid snippet:

classDiagram
    class User {
        +String name
        +int age
        +login() bool
    }
    class Admin {
        +String role
        +deleteUser(User u)
    }
    User <|-- Admin

Most tools simply render a pretty SVG. But for a developer, the "real work" is just starting. You still have to write:

User.java with private fields and public accessors.

Admin.java with the extends keyword.

Method stubs that match the diagram signatures.

Dev Suite automates this transition. You paste the Mermaid syntax and instantly get a production-ready project skeleton.

Under the Hood: Building a Compiler Pipeline

As an engineer, I knew that simple string replacement wouldn't scale. To support the nuances of different languages, I built the generator as a mini-compiler pipeline:
1. The Parser Layer
We use a robust parser to transform the Mermaid string into an Abstract Syntax Tree (AST). This allows the tool to understand relationships like Composition, Inheritance, and Visibility without getting tripped up by formatting or whitespace.

2. The Intermediate Representation (IR)
The AST is converted into a language-agnostic class model. This "source of truth" represents the classes, their members, and their connections.

3. The Language-Specific Emitter
The Intermediate Representation (IR) is piped into specialized emitters. This decoupled architecture ensures that adding support for Python, TypeScript, or C# is a simple matter of writing a new emitter, not rebuilding the core engine.

Why This Matters for Your Workflow

Faster Prototyping: Go from a whiteboard sketch to a compilable project structure in seconds.
Reduced Cognitive Load: Spend your energy on solving business logic, not typing public String getUsername().
Architectural Parity: Ensure the code actually reflects the design approved during the review phase.
Learning Tool: For students and junior devs, seeing the immediate translation of visual OOP concepts into code is a powerful educational feedback loop.

I want to hear from you:
What is the most tedious part of your design-to-dev workflow? What "mechanical" task do you wish was automated?

Try the generator now:
Mermaid Class Diagram to Java
Mermaid Class Diagram to C++

How I Built a React JSON Tool That Handles 150k+ Lines Without Freezing the Browser

Divyanshu Deepam — Thu, 23 Apr 2026 19:13:27 +0000

Most JSON tools work fine… until they meet real-world production data.

We’ve all been there: You paste a massive payload into a web-based formatter, and suddenly:

The page stops responding.
Scrolling becomes a stuttering mess.
The "Page Unresponsive" popup appears.
I encountered this while debugging complex automation flows and deeply nested configurations. I needed a tool that could handle 150k+ lines of JSON without falling apart, but I didn't want to compromise on privacy by sending that data to a backend.

So I built Dev Suite - a client-side toolkit designed for performance-first JSON manipulation.

Why Large JSON is a "Systems Engineering" Challenge

Performance in the browser isn't just about a fast for loop. It’s a multi-layered bottleneck involving:

Parsing Cost: Converting a 10MB+ string into a JavaScript object.
Memory Pressure: Storing that object and its associated metadata.
DOM Complexity: The browser struggling to calculate layout for 5,000+ nodes.
React Overhead: Re-renders triggered by state changes during heavy interactions. Here is how I tackled the specific challenges of scaling the tool from 50k to 150k+ lines.

1. JSON Path Finder: Reducing the Noise

The Path Finder returns dot-notation paths (e.g., payment.gateway.retry.maxAttempts). While the logic seems simple, iterating through a massive tree structure can generate significant "noise."

The Challenge: Array Explosion
If you search for a key like feeTypesand it’s an array of 1,000 objects, a naive search might return: feeTypes[0], feeTypes[1], feeTypes[2]...

The Fix: AST-Based Traversing
I implemented a search algorithm that walks the Abstract Syntax Tree (AST) of the JSON. Instead of a flat search, I added conditional result filtering. This ensures users see the meaningful parent matches first. By intelligently pruning the traversal, we keep the UI clean and the search execution time sub-millisecond.

2. Solving the "5,000 Element" Freeze

If a search returns 5,000 matches, and React tries to render 5,000 buttons (each with icons, hover states, and tooltips), the main thread will lock up for several seconds while the browser paints.

The Solution: Virtualization
I implemented DOM Virtualization. Instead of rendering all 5,000 results, the tool only renders the ~20 items currently in the user's viewport. As the user scrolls, DOM nodes are recycled and updated with new data.

3. Bypassing the React Render Cycle

React is amazing for state management, but it can be a bottleneck for text editors. If every keystroke in a 100k-line file triggers a React state update and a virtual DOM diff, the latency (typing lag) becomes unbearable.

The Fix: Decoupling the Editor Engine
I moved the "hot path" away from React's state. By using an uncontrolled component approach with the underlying editor engine (CodeMirror/Monaco), I severed the connection between the typing engine and React’s render cycle.

4. JSON Diffing

A standard text diff is useless for JSON because key order often doesn't matter. JSON Diff Checker helps to check differences between two JSONs semantically.

The Solution: Order-Invariant Comparison
I built a recursive diffing algorithm using Map and Set data structures.

It identifies Added, Removed, keys with modified value and keys with value type changed.
It ignores object key order (semantic equality).
It handles nested structures recursively.

Navigating the Diffs
In a 150k line file, you can't just "jump" the user around. I implemented Binary Search over the sorted array of diff locations. This allows the "Next" and "Previous" buttons to find the closest difference relative to the user's current scroll position instantly.

The Result

Dev Suite now handles 150k+ lines of JSON with ease. It’s been an insightful journey into the limits of browser performance and the importance of choosing the right tool for the right job (even if that tool is "Not React" for certain specific tasks).

There are more tools at Dev Suite , you can explore
👉 https://devsuite.tools/mermaid-class-diagram-to-java
👉 https://devsuite.tools/mermaid-class-diagram-to-cpp
👉 https://devsuite.tools/yaml-diff
👉 https://devsuite.tools/yaml-pathfinder

I'd love to hear from you:
What’s the largest JSON payload you’ve had to debug in a browser? Did your existing tools survive, or did you have to reach for the terminal?

Let's discuss in the comments!