DEV Community: jfeliu007

Tying It All Together: Your Map to Better Go Architecture

jfeliu007 — Thu, 09 Oct 2025 15:45:00 +0000

Gin Full Project Diagram — Everything at Once

Above: The full Gin project diagram, generated with Dumels. This image shows every type and relationship in the codebase. It's the ultimate map for understanding how everything fits together.

The Meta-Insight: Seeing the Architecture's Story

Throughout this series, we've used diagrams to uncover hidden patterns, extension points, and surprising connections in Gin. Each post built on the last, turning abstract code into a visual story. Now, let's step back and see what these visualizations reveal about the architecture as a whole—and how you can use the same approach for any project.

What Different Views Reveal (and Why They're Useful)

The Core and Middleware Chain

Gin Core and Middleware

Above: A focused view of Gin's core types and middleware system. Notice how HandlerFunc and HandlersChain connect everything.

Here we see:

The "spine" of Gin: Engine, RouterGroup, and Context
How middleware slots into the request flow
The elegant simplicity of the HandlerFunc type

The Request Journey

This view reveals:

How requests enter through the Engine
The role of IRouter and IRoutes
Where your handlers plug in

Extension Points

Gin Extension Points

Above: Where and how you can extend Gin. The interfaces in binding and rendering make it pluggable.

Notice:

Common interfaces for binding and rendering
How new formats can be added
The separation between core and extensions

Finding Your Way Around Large Codebases

The techniques we've used to explore Gin can be applied to any Go project:

Start with the Big Picture
- Generate a full diagram first
- Look for clusters and central types
- Identify the "spine" of the system
Zoom In Strategically
- Focus on one subsystem at a time
- Use interface relationships as guides
- Follow the flow of data or requests
Spot Patterns and Problems
- Look for repeated structures
- Find highly coupled areas
- Identify extension points

Filtering for Clarity

Different views serve different purposes:

Architecture Overview

Architecture Overview
Perfect for:

First look at a project
Architecture discussions
Documentation

Focused Investigation

Core Details

Great for:

Learning specific subsystems
Debugging issues
Planning changes

Real-World Applications

Here's how different teams might use these diagrams:

Product Teams: Plan new features by seeing where they fit
New Developers: Get up to speed quickly on project structure
Architects: Evaluate and improve the system design
Maintainers: Spot refactoring opportunities
Documentation Writers: Create clear, accurate technical docs

Beyond Gin: Your Turn to Explore

The insights we've gained from Gin's architecture apply broadly:

Clear Core Types: Like Gin's Engine, Context, and RouterGroup
Plugin Systems: Similar to Gin's binders and renderers
Interface Webs: For flexibility and extension
Middleware Chains: For modular behavior

Try generating diagrams for your own projects:

Start with the full view
Filter down to specific areas
Look for patterns and opportunities
Share insights with your team

Taking Action

For Your Current Project
- Generate a full diagram
- Look for clusters and patterns
- Share insights with your team
For Learning
- Pick a Go project you want to understand
- Create different views with filters
- Follow the patterns you discover
For Documentation
- Add filtered diagrams to your docs
- Show different perspectives
- Keep diagrams up to date with code

Remember: A good diagram doesn't just show structure—it tells a story.

Thanks for joining me on this journey through Gin's architecture. Now it's your turn to start mapping your Go adventures!

Rendering in Gin: Modularity, Extensibility, and Diagram Insights

jfeliu007 — Thu, 02 Oct 2025 17:03:48 +0000

Let’s talk about output—the part your users actually see! Gin’s rendering system is a masterclass in modularity, and the class diagram makes it obvious. If you’ve ever wanted to add a new response format or tweak output for your Go APIs, this is your roadmap.

Above: A focused diagram of Gin’s render package, generated with Dumels. Implements and uses connections reveal the plugin-like architecture and extension points at a glance. See full interactive diagram here

What the Diagram Reveals: Plugin Architecture and Extension Points

The diagram shows a set of renderers for different formats—JSON, XML, HTML, data, and more—all connected by “implements” arrows to a common renderer interface. This is a classic “plugin” architecture: you can add new renderers or swap out existing ones without touching the rest of the system. “Uses” connections show how renderers may depend on helpers or templates via fields.

This structure is much easier to see in the diagram than in code, where interface satisfaction and field composition are implicit and scattered.

Why This Matters for Go Devs

Extensibility: You can add support for new formats (CSV, YAML, etc.) by implementing the renderer interface. The diagram shows you exactly where to plug in.
Separation of Concerns: Each renderer is responsible for a single format, making the codebase easier to maintain and extend.
Debugging: The diagram lets you trace the flow from handler to renderer to output, so you can quickly spot where things might go wrong.

Practical Example: How Rendering Works in Gin

Here’s a typical handler using rendering:

func helloHandler(c *gin.Context) {
    c.JSON(200, gin.H{"message": "hello, world"})
}

func htmlHandler(c *gin.Context) {
    c.HTML(200, "index.tmpl", gin.H{"title": "Home"})
}

Gin provides methods like JSON, XML, HTML, and Data on the Context object. Under the hood, these all use the render package to format and send the response. The diagram’s “implements” arrows show which concrete renderer is used for each format, and “uses” connections show any dependencies (like templates).

How to Read the Diagram for Rendering

Implements arrows: Show which renderers satisfy the common interface. Look for all the built-in formats, and see how you could add your own.
Uses connections: Show how renderers may depend on other types (like templates or helpers) via fields.
Clusters: Group together all the renderers, making it easy to see the full set of supported formats.

Pro tip: If you want to add a new renderer, follow the “implements” arrows to see which interface you need to satisfy.

Real-World Scenarios

APIs: Return JSON or XML for clients and mobile apps.
Web Apps: Serve HTML templates for browsers.
File Downloads: Use Data or File renderers for binary content.
Custom Formats: Implement your own renderer for CSV, YAML, or anything else.

Takeaway: Diagrams Reveal Plugin Architectures

This is the kind of insight that’s hard to spot in code, but jumps out in a diagram. By visualizing the rendering system, you can see where to extend, debug, or customize Gin’s response formatting—and understand the plugin-like structure at a glance.

Tips for Using Rendering Effectively

Use the right renderer for your content type.
Set headers (like Content-Type) as needed before rendering.
For HTML, pre-parse templates at startup for performance.
Combine rendering with middleware for logging, compression, etc.
For advanced cases, implement your own renderer and register it.

Next up: We’ll tie everything together and show how these diagrams reveal the “spine” of Gin’s architecture—and how you can use the same approach to master any Go project.

Stay tuned for Part 5: Surprising Connections & Internal Utilities!

Binding in Gin: Pluggability, Validation, and What the Diagram Really Shows

jfeliu007 — Thu, 25 Sep 2025 15:54:44 +0000

Ready for a real Go power move? Let’s see how Gin makes it almost effortless to handle any kind of input—while keeping your code clean and testable. This is where class diagrams turn “huh?” into “aha!”

Above: A focused diagram of Gin’s binding package, generated with Dumels. Implements, uses, and extends connections reveal the real structure at a glance. See the full interactive diagram generated by dumels.com here

What the Diagram Reveals: Interface Nuance and Extension Points

At first glance, the diagram shows a set of binders for different formats—JSON, XML, form, query, URI, and more. But the real insight comes from the arrows:

Implements arrows (with arrowheads) show which interfaces each binder satisfies. For example, you’ll see that some binders (like formBinding or headerBinding) implement only the Binding interface, while others (like jsonBinding, xmlBinding, yamlBinding) implement both Binding and BindingBody.

This distinction is crucial:

Binders that implement only Binding (e.g., formBinding, headerBinding) are used for formats that don’t require reading the request body (like query parameters or headers).
Binders that implement BindingBody (e.g., jsonBinding, xmlBinding, yamlBinding) are for formats that require reading and parsing the request body.
Some binders (like jsonBinding) implement both—meaning they can be used in both contexts, and Gin’s dispatch logic can select them appropriately.

This is much easier to see in the diagram than in code, where interface satisfaction is implicit and scattered.

Why This Matters for Go Devs

Extensibility: You can add new binders (for YAML, Protobuf, etc.) by implementing the right interface(s). The diagram shows you exactly which interface to target.
Correct Usage: When writing handlers, knowing which binder implements which interface helps you understand what kinds of requests it can handle. For example, if you want to bind from the request body, you need a binder that implements BindingBody.
Debugging: The diagram makes it easy to trace the flow from HTTP request, through the binder, to your struct and the validator.

Practical Example: How This Shows Up in Code

Here’s a typical handler using binding:

type Login struct {
    User     string `form:"user" json:"user" binding:"required"`
    Password string `form:"password" json:"password" binding:"required"`
}

func loginHandler(c *gin.Context) {
    var json Login
    if err := c.ShouldBind(&json); err != nil {
        c.JSON(400, gin.H{"error": err.Error()})
        return
    }
    c.JSON(200, gin.H{"status": "logged in"})
}

Gin figures out the content type, picks the right binder (using the diagram’s “implements” arrows as a guide), parses the request, and fills in your struct. If anything is missing or invalid, you get an error you can handle gracefully.

How to Read the Diagram for Binding

Implements arrows: Show which binders satisfy which interfaces. Look for binders that implement both Binding and BindingBody (like jsonBinding)—these are the most flexible.
Uses connections: Show how the validator is plugged in, but not tightly coupled.
Clusters: Group together all the binders, making it easy to see the full set of supported formats.

Pro tip: If you want to add a new binder, follow the “implements” arrows to see which interface you need to satisfy for your use case.

Real-World Scenarios

Building APIs: Quickly accept and validate complex payloads, knowing exactly which binder is in play.
Form Handling: Support both web forms and JSON APIs with the same handler, thanks to binders that implement both interfaces.
Custom Validation: Add your own rules by extending the validator, as shown by the “uses” connection.

Takeaway: Diagrams Expose the Real Extension Points

This is the kind of insight that’s hard to spot in code, but jumps out in a diagram. By visualizing the binding system, you can see where to extend, debug, or customize Gin’s request handling—and understand the subtle differences between binders at a glance.

Next up: We’ll look at Gin’s rendering system and see how diagrams reveal modularity and extensibility in response formatting. If you’ve ever wanted to add a new output format or customize responses, you’ll see exactly where to start.

Stay tuned for Part 4: Rendering — Extensibility and Separation of Concerns!

The Core of Gin: Interface Webs, API Consistency, and the Beating Heart of the Framework

jfeliu007 — Wed, 17 Sep 2025 15:30:00 +0000

Welcome back! Now that you’ve seen the big picture, let’s zoom in and get our hands dirty. This is where the magic (and a little Go trickery) happens.

Above: A focused diagram of Gin’s core, generated with Dumels. This image highlights the Engine, RouterGroup, Context, HandlerFunc, and the key interfaces that tie them together. See above interactive diagram here

What the Diagram Reveals: The Interface Web

At first glance, the diagram shows the expected core types: Engine, RouterGroup, Context, and HandlerFunc. But look closer, and you’ll spot a subtle, powerful pattern: RouterGroup implements both IRouter and IRoutes, and IRouter itself extends IRoutes. In the diagram, “implements” arrows (with arrowheads) show these interface relationships explicitly—something that’s easy to miss in Go code, since interface satisfaction is implicit.

This is a classic Go interface “diamond,” and the diagram makes it obvious: “implements” arrows point from RouterGroup to both IRouter and IRoutes, and from IRouter to IRoutes. You’ll also see “uses” or “extends” connections for composition and embedding, which help clarify how these types are built from one another. It’s like finding a secret passage in a familiar house.

Why does this matter for Go devs?

API Consistency: Both Engine and RouterGroup expose the same routing and middleware API, so you can use the same patterns at the root or in subgroups.
Flexibility: Functions, middleware, or helpers can accept either interface, making code more generic and reusable.
Clarity: The diagram exposes this design at a glance—no need to hunt through type definitions or comments.

Why This Is Hard to Spot in Code (and Why Diagrams Rock)

In Go, interfaces are satisfied implicitly. Unless you’re looking at both the interface definitions and the struct methods, you might never realize that RouterGroup implements both IRouter and IRoutes, or that IRouter is just IRoutes plus grouping. The diagram makes this relationship explicit and visual.

Meet the Core Types

At the center of Gin’s architecture are four key types, and the diagram shows how they’re connected:

Engine: The main entry point for your application. It holds the router, middleware stack, and configuration. When you create a Gin app, you’re working with an Engine. Think of it as the “brain” of your web server.
```
r := gin.Default() // returns an *Engine
r.GET("/ping", func(c *gin.Context) {
    c.JSON(200, gin.H{"message": "pong"})
})
r.Run()
```

RouterGroup: Lets you organize routes into groups, apply middleware to subsets of routes, and build modular APIs. Every Engine starts with a root RouterGroup, but you can nest groups as deeply as you like. This is perfect for versioning APIs or applying authentication to specific sections.
```
api := r.Group("/api")
v1 := api.Group("/v1")
v1.GET("/users", usersHandler)
```

Context: Represents a single HTTP request/response cycle. It carries request data, response writers, parameters, and more. Every handler in Gin receives a Context. This is your window into the request and your tool for crafting the response.
```
func usersHandler(c *gin.Context) {
    userID := c.Param("id")
    // ...
    c.JSON(200, gin.H{"user": userID})
}
```

HandlerFunc: The function signature for Gin handlers. It’s just func(*gin.Context), but this simplicity is what makes Gin’s middleware chain so flexible. Middleware and endpoint handlers share the same signature, making it easy to compose them.

A Request’s Journey: Step by Step

Let’s walk through what happens when a request hits your Gin server:

Engine receives the HTTP request from the Go net/http server.
The request path is matched to a route, possibly within a nested RouterGroup (e.g., /api/v1/users).
Gin builds a chain of HandlerFuncs: global middleware, group middleware, and the endpoint handler.
A new Context is created for the request and passed through the handler chain.
Each handler can read/write data, set headers, abort the chain, or render a response. The Context object is the thread that ties everything together.

This flow is what gives Gin its speed and flexibility. Middleware can be attached at any level (global, group, or route), and the Context object makes it easy to share data and control the response.

Customizing and Extending the Core

One of Gin’s strengths is how easy it is to extend. Want to add logging, authentication, or metrics? Just write a middleware (a HandlerFunc) and attach it to the Engine or a RouterGroup. Need to pass data between handlers? Use the Context’s Set and Get methods.

Example: Custom Middleware

func Logger() gin.HandlerFunc {
    return func(c *gin.Context) {
        t := time.Now()
        c.Next()
        latency := time.Since(t)
        log.Printf("%s %s %v", c.Request.Method, c.Request.URL.Path, latency)
    }
}

Reading and Using the Diagram

Gin Core - Structs

The diagram above (generated with Dumels) shows just the core types and their relationships:

Implements arrows (with arrowheads) show which types satisfy which interfaces (e.g., RouterGroup implements IRouter and IRoutes).
Uses connections indicate that a struct has a field of another type (composition by field).
Extends connections represent struct embedding or composition (Go’s way of inheriting fields and methods).
Alias of means a type is simply an alias for another.

Why is this diagram so useful?

It cuts through the noise and reveals the essential structure of Gin’s request handling.
If you’re onboarding a new team member, debugging a tricky bug, or planning a refactor, this diagram is your map.
You can use it to explain Gin’s flow to others, or to quickly orient yourself when returning to the codebase after a break.

How to use it:

Keep it open while you work on Gin projects.
Trace the path of a request visually, following “uses” and “extends” connections to see how types are composed, and “implements” arrows to see interface satisfaction.
Use it to spot where to add new features or middleware.

Common Pitfalls (and How the Core Helps)

Middleware order confusion: The diagram makes it clear how middleware chains are built.
Losing data between handlers: Remember, Context is your shared state.
Route organization: Use RouterGroup to keep things modular and maintainable.

How I Generated This Diagram (and How You Can Too)

To create this focused view, I used Dumels to filter the project down to just the core types. This makes it easy to study the most important parts of Gin without distraction. You can do the same for any project—just select the packages (or folders) you care about, and Dumels will generate a clean, focused diagram.

Above: The options used to strip the diagram down to just the core files. Notice how I ignored a set of folders and left just the root package.

Tip: Try generating diagrams for just your own application’s routes or middleware to spot hidden complexity! The diagram in this post is a direct output from Dumels, and it’s the same tool I use throughout this series to make sense of complex code. You can even create diagrams of your private repos by creating an account with dumels.com

Interpreting Relationships in the Diagram

Implements arrows: Show interface satisfaction (Go’s implicit interface implementation).
Uses connections: Indicate field composition (a struct has a field of another type).
Extends connections: Represent struct embedding or composition.
Alias of: Shows type aliases.
Clusters: Groups of types that work closely together (e.g., Engine and RouterGroup).

If you’re ever unsure how a request moves through Gin, start at Engine and follow the arrows—paying attention to the type of connection. The diagram is your visual guide to the code’s logic.

Check the full interactive Core Diagram Here in dumels.com

Next up: We’ll dive into Gin’s binding system and see how diagrams reveal pluggability and validation patterns that are easy to miss in code alone. If you’ve ever wanted to add a new data format or custom validation, you’ll love what’s coming.

Stay tuned for Part 3: Binding — Pluggability and Validation at a Glance!

Visualizing Gin: A Different Kind of Code Walkthrough

jfeliu007 — Wed, 10 Sep 2025 16:40:10 +0000

Welcome to a different kind of code walkthrough. In this series, we’re not just reading code—we’re seeing it. We’ll use real diagrams to uncover the hidden patterns, clever tricks, and “aha!” moments inside Gin, one of Go’s most popular web frameworks. If you’ve ever felt lost in a big codebase, this is for you.

Why Start with a Diagram?

When you first open a large project like Gin, it’s easy to feel lost. There are dozens of files, hundreds of types, and countless connections. But with a single diagram, you can:

See the main building blocks at a glance
Spot clusters of related types
Identify which components are most central
Get a sense of the project’s overall shape and complexity

Above: The overall Gin project diagram, generated with Dumels. This image shows the main types and their relationships, giving you a high-level map of the framework’s architecture. See the full interactive diagram in Dumels.com

What Stands Out in the Diagram?

A quick look at the diagram reveals:

Central Types: Types like Engine, Context, and RouterGroup are at the heart of the project, with many connections radiating out. In the diagram, you’ll see arrows labeled “implements” (showing interface satisfaction), “uses” (indicating a struct has a field of another type), and “extends” (for embedded structs or composition). These connections help you quickly spot which types are most influential.
Clusters: Groups of tightly connected types—linked by “uses” or “extends” connections—often represent subsystems or features (like routing, middleware, or rendering).
Peripheral Types: More isolated types, with few or no incoming or outgoing connections, are likely helpers or utilities.
Overall Shape: The “spine” of core types with feature branches (visible through a mix of “implements,” “uses,” and “extends” connections) hints at a modular, extensible design.

Why This Matters (and Why It’s Fun)

Onboarding: New contributors can use the diagram to orient themselves before diving into code.
Planning: If you’re adding a feature or fixing a bug, the diagram helps you see what might be affected.
Communication: Diagrams make it easier to explain the architecture to teammates or stakeholders.

The Challenge of Complexity

Gin’s codebase is sprawling. For anyone trying to contribute, debug, learn, or evaluate, the sheer number of types and relationships can be overwhelming. It’s easy to get lost tracing how a request moves through the framework, or to miss important connections between components.

Why Is This a Problem?

Onboarding: The learning curve can be steep.
Debugging: Tracing bugs or performance issues often requires understanding how different parts of the system interact.
Refactoring: Making improvements or adding features is risky if you don’t fully grasp the dependencies.
Documentation: Written docs can become outdated or incomplete.

Why Use Visual Diagrams?

Text-based code navigation only gets you so far. Visualizing the project structure helps you:

See the big picture instantly
Spot complexity and tightly coupled areas
Communicate your understanding
Accelerate onboarding
Plan changes with confidence

Practical Example: The "Aha!" Moment

Imagine you’re tasked with adding a new middleware feature. After an hour in the code, you’re still not sure how requests flow. But with a diagram, you can immediately see the main types, their relationships, and where your changes would fit. That “aha!” moment saves hours of frustration.

How I Visualized Gin (and Why This Diagram Matters)

I used Dumels to generate the diagram above. Dumels analyzes the codebase and produces interactive diagrams that reveal the structure and relationships between types, interfaces, and functions.

What does this diagram show? Every major type in Gin, and how they connect.
How can you use it? Spot the most important types, see which components are most interconnected, and use it as a map for onboarding, code reviews, or planning refactors.

Pro tip: Try printing the diagram or sharing it with your team. It’s a powerful conversation starter and a shared reference point.

How to Read and Use the Diagram

Boxes represent types (structs, interfaces, etc.).
Implements arrows (with arrowheads) show that a type implements an interface (Go’s implicit interface satisfaction).
Uses connections indicate that a struct has a field of another type (composition by field).
Extends connections represent struct embedding or composition (Go’s way of inheriting fields and methods).
Alias of means a type is simply an alias for another (rare, but sometimes used for clarity or API design).
Clusters of tightly connected types often indicate a subsystem or feature area.
Isolated types may be utilities or helpers.

For real work:

Start by finding the "core" types—usually the largest or most connected boxes. In Gin, Engine, Context, and RouterGroup stand out. Trace their connections: for example, follow “uses” arrows to see which types are composed together, or “implements” arrows to see which interfaces are satisfied. This helps you understand how requests might flow through the system and where extension points exist.

Real-World Scenarios for Visualization

Onboarding: Share the diagram for a visual shortcut to understanding the project.
Planning a refactor: See which types are most affected by a proposed change.
Debugging: Quickly trace the path from the entry point to the failing component.
Writing documentation: Use diagrams to supplement written docs and keep them in sync with the code.
Open source contributions: Lower the barrier for new contributors by making the architecture visible.

Takeaway: Start with the Map

Before you read a single line of code, take a look at the diagram. It’s your map to the Gin codebase—and it will help you spot patterns, plan changes, and avoid getting lost.

Next up: We’ll zoom in on Gin’s core and uncover a design pattern that’s almost invisible in code, but jumps out in a diagram. Ever wondered how Gin keeps its API so consistent? You’re about to find out.
And if you want to leave with just one thing, let it be this: open the interactive map and watch the entire framework unfold in front of you.

Stay tuned for Part 2: The Core — Interface Webs and API Consistency!

Converting your GitHub.com public GoLang repo into a class diagram

jfeliu007 — Mon, 29 Jun 2020 17:18:58 +0000

In the past few months, I have been working with a friend on a website to create UML class diagrams of public GitHub projects made in GoLang. Last year, I made a post where I showed a library I built called GoPlantUml; the response was very positive. Many provided me with issues they found and suggestions that I could include as features in the project. But the feedback that worried me more was the fact that some users didn't know about Plantuml at all. So, I spoke with a friend of mine, and we built a service that renders the diagram right from a github.com public repository.

https://www.dumels.com

We discovered that using the library manually, was very useful for us when we wanted to understand how other libraries worked. However, downloading the code, converting it to Plantuml, and rendering it was a bit slow for our liking. With www.dumels.com, we speed this process. I shared a bit more information on this blog post if you are interested in reading a bit more about the project.

I hope you guys can find it useful as well.

How to turn your golang programs into UML Class diagrams

jfeliu007 — Tue, 09 Jul 2019 21:14:54 +0000

Sometimes it helps to see a class diagram of your projects to understand the big picture. I have always been a fan of PlantUML. When it comes to drawing UML diagrams, plantUML is one of my favorites since drawings are generated out of a human-readable text file, which can be easily committed to git.

For that reason, I decided to write a Golang library to generate class diagrams from a Golang project.

Goplantuml is a Golang library with an added command that you can install if you run go already. It basically turns code like this



package goisawesome

import "strings"

type Foo struct {
    field       int
    PublicField bool
    *strings.Builder
}
type MyInterface interface {
    GetValue() bool
}

func (f *Foo) myPrivateFunction() int {
    return 3
}

func (f *Foo) GetValue() bool {
    return true
}

func (f *Foo) MyPublicFunction() bool {
    return true
}

into this



@startuml
namespace goisawesome {
    class Foo {
        - field int
        + PublicField bool
        - myPrivateFunction() 
        + GetValue() 
        + MyPublicFunction() 
    }
    interface MyInterface {
        + GetValue() 
    }
}
strings.Builder *-- goisawesome.Foo
goisawesome.MyInterface <|-- goisawesome.Foo
@enduml

which can be used with plantuml to generate a nice class diagram.

see example here

If you are interested, swing by the goplantuml repo.

jfeliu007 / goplantuml

PlantUML Class Diagram Generator for golang projects

GoPlantUML V2

GoPlantUML is an open-source tool developed to streamline the process of generating PlantUML diagrams from Go source code. With GoPlantUML, developers can effortlessly visualize the structure and relationships within their Go projects, aiding in code comprehension and documentation. By parsing Go source code and producing PlantUML diagrams, GoPlantUML empowers developers to create clear and concise visual representations of their codebase architecture, package dependencies, and function interactions. This tool simplifies the documentation process and enhances collaboration among team members by providing a visual overview of complex Go projects. GoPlantUML is actively maintained and welcomes contributions from the Go community.

Want to try it on your code?

Take a look at www.dumels.com. We have created dumels using this library.

Code of Conduct

Please, review the code of conduct here.

Prerequisites

golang 1.17 or above

Installing

go get github.com/jfeliu007/goplantuml/parser
go install github.com/jfeliu007/goplantuml/cmd/goplantuml@latest

This will install the command goplantuml in…

View on GitHub

I would love to hear you opinions. I also wrote an article about the program and how it is used if you would like more information.