Go Project Scaffolding Guide: A Choice That Earned My Team's Rave Reviews

When developing with Go, who hasn't been through the wringer with frameworks like the standard library's HTTP, Gin, Echo, Iris, Fiber, Beego, GoFrame, gRPC, Go-Micro, Go-Zero, or Kratos? They all claim to have great performance and powerful features, but in practice, there are always those "not-so-great" moments, right?

It's like dating. At first, everyone seems wonderful, but over time, little frictions and pain points start to surface. Today, I'm going to share how, after trying them all, I finally found my "dream framework" — Sponge — and just how much of a game-changer it is!

The Pains We've All Endured

Before I found Sponge, my Go development life was a mix of pain and pleasure.

Gin, Echo: Freedom is Great, But You Have to Build Everything from Scratch

Gin and Echo are old friends to us Gophers—lightweight, fast, and easy to get started with. But the price of freedom is that you have to build a lot of things yourself.

Want to write a simple CRUD? Okay, start by defining a struct, writing the handler, service, and model, then registering the routes. After all that "grunt work," half the day is gone. It's manageable for small projects, but as projects grow, the code structure starts to become a "wild west," with different people writing in wildly different styles.

Let me show you a "familiar" scene. Writing a user creation endpoint with Gin, does it feel like you're copy-pasting this in every project?

// main.go
package main

import (
    "github.com/gin-gonic/gin"
    "net/http"
)

type User struct {
    Name  string `json:"name"`
    Email string `json:"email"`
}

func main() {
    r := gin.Default()

    r.POST("/users", func(c *gin.Context) {
        var user User
        if err := c.ShouldBindJSON(&user); err != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }
        // ... service and model layer calls omitted here ...
        // Let's "pretend" we saved the user here
        c.JSON(http.StatusOK, gin.H{"status": "user created"})
    })

    r.Run()
}

This is just the simplest example. If you add database operations, logging, parameter validation, and error handling... you can imagine the amount of code and repetitive labor involved. Every time I started a new project, it felt like reinventing the wheel. It was exhausting.

Go-Micro, Go-Zero, Kratos: Microservices are Great, But a Bit "Heavy"

To solve the problems above, a batch of excellent "heavyweight" contenders emerged in the community, like go-micro, go-zero, and kratos. They provide comprehensive microservice governance capabilities, including everything from RPC, service discovery, and configuration centers to distributed tracing.

But their "pain" lies here as well:

• Steep learning curve: To use them effectively, you have to spend a lot of time learning the framework's philosophy and its various components. For projects that need to get started and iterate quickly, this is a bit too "heavy."

• "Black box" code generation: Although they offer code generation tools, the generated code can sometimes be too "magical." When a problem occurs, it's hard to know where to start debugging. And for developers like us who are code purists, the feeling of not having full control over the code... you get it.

• Bloated project structure: A simple service might generate a huge pile of files and directories. Sometimes it feels like using a sledgehammer to crack a nut.

Discovering Sponge: My "Game-Changer" Moment!

Just when I was about to lose my mind oscillating between "reinventing the wheel" and "being held hostage by a framework," I discovered Sponge.

Sponge perfectly balances development efficiency and code controllability, solving all the pain points mentioned above.

1. "Idiot-Proof" Code Generation, Say Goodbye to Repetitive Labor

What amazed me most about Sponge is its powerful code generation capability. It doesn't just generate some template code; it's truly one-click generation of a complete project!

All you need to do is:

• Define your database table structure (e.g., in an SQL file).

• Or define your API interface (in a Protobuf file).

Then, with just a few clicks on Sponge's provided web interface, a complete, production-ready backend service code is generated!

Let's take the same user creation example. How do you do it with Sponge?

Step 1: Using MySQL as an example, write a user.sql file and import it into your MySQL service. The process is similar for other databases (like PostgreSQL, MongoDB, etc.).

CREATE TABLE `user` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  `email` varchar(100) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_email` (`email`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Step 2: In Sponge's web interface, select "Generate Web Service from SQL," enter your MySQL DSN address, and choose the table name user.

Step 3: Click "Generate Code" and download the zip file.

After unzipping, you get a complete, runnable project! It includes:

• API Endpoints (/api/v1/user)

• Swagger Docs (auto-generated, for direct online debugging)

• Handler Layer (request handling)

• Service Layer (business logic)

• DAO Layer (database CRUD operations, based on GORM)

• A complete project structure, Makefile, Dockerfile...

You read that right. Without writing a single line of Go code, a fully functional CRUD service is ready! The development efficiency is off the charts!

2. Modular, "Lego-like" Architecture: Flexible and Decoupled

The code generated by Sponge is not a pile of "spaghetti code." It adopts a very clear layered and decoupled design.

Each module is like a Lego block that you can freely combine and extend. For example:

• Don't want to use GORM? No problem. The DAO layer is interface-based, so you can easily replace it with any ORM you like.

• Want to add custom logic? The Service layer has already left a "template" for you. You just need to fill in the core business logic, without worrying about framework chores.

• Want to migrate from a monolith to microservices? A Sponge-generated project is naturally a microservice architecture, making it easy to split and combine services.

This design ensures development efficiency while giving developers immense freedom and a sense of control. The code is "your" code, not the "framework's" code.

3. Rich Built-in Components, Out of the Box

Sponge is more than just a code generator; it's an "all-in-one suite."

• Web Framework: Built on Gin, allowing you to seamlessly use all of Gin's middleware and ecosystem.

• RPC Framework: Supports gRPC and can generate a gRPC Gateway with one click, enabling your gRPC service to support HTTP calls simultaneously.

• Service Governance: Integrates essential microservice components like service discovery, circuit breaking, rate limiting, distributed tracing, and monitoring.

• Common Libraries: Redis, MongoDB, Kafka, RabbitMQ... they're all pre-packaged and ready to use out of the box.

With Gin, I used to have to find, integrate, and wrap each of these libraries myself. Now with Sponge, I just enable them in the configuration file. It's incredibly convenient!

Conclusion

Returning to the original question, after looking at so many Go frameworks, why did I ultimately choose Sponge?

• For individual developers and startups: In the world of software, speed is king. Sponge lets you build product prototypes and validate ideas at maximum speed, allowing you to focus on core business logic instead of repetitive grunt work.

• For medium to large teams: Sponge unifies project structure and development standards, lowering the learning curve for new members and improving team collaboration. Its high-cohesion, low-coupling design also makes projects easier to maintain and extend.

• For Gophers who strive for excellence: Sponge has no "black magic." The generated code is clean and standardized, allowing you to enjoy high-efficiency development while still having complete control over your code and learning excellent architectural design principles from it.

Of course, no framework is a perfect silver bullet. But Sponge truly won me over. It's like an experienced senior developer who takes care of all the dirty work for you, so you can focus on the creative tasks.

If you, like me, are tired of wavering between different frameworks and fed up with day-to-day repetitive labor, I highly recommend giving Sponge a try. Head over to its GitHub repository, run the examples, and trust me, you'll find yourself shouting the same thing I did: This is a game-changer!

Sponge Project Link: https://github.com/go-dev-frame/sponge