DEV Community: gvison

Go in Action: Building a Production-Grade Dynamic Reverse Proxy on Top of Gin

gvison — Thu, 20 Nov 2025 08:44:15 +0000

Foreword

As backend developers, we are certainly familiar with Nginx. It is the absolute dominator of reverse proxies and load balancing. However, have you encountered this scenario: your business is in a rapid iteration phase, backend service nodes change frequently, or you need to perform canary releases. Every time you adjust the Upstream servers, you have to modify nginx.conf and then carefully execute nginx -s reload.

Although Nginx has powerful performance, its configuration management can feel slightly "heavy" in certain dynamic scenarios (while Nginx Plus supports dynamic APIs, that is a paid feature; Lua scripts can also achieve this, but maintenance costs are high).

If you are a Go developer and are currently using the Gin framework, you can completely "embed" reverse proxy capabilities into your business code. Today, I am introducing a production-grade reverse proxy library based on Gin —— Gin Reverse Proxy. It not only replaces some Nginx functions but, more importantly: it supports dynamic management of routes and nodes via API without restarting the service.

Why Implement Reverse Proxy in Code?

Usually, we consider reverse proxies an operations matter. But in microservices or cloud-native environments, enabling the gateway layer with programmable capabilities is essential.

This library github.com/go-dev-frame/sponge/pkg/gin/proxy is actually built on the Go standard library net/http/httputil, but it adds a very practical layer of encapsulation:

Dynamic Awareness: Bring backend machines online or offline at any time via HTTP API.
Health Checks: Similar to Nginx's health_check, automatically removing bad nodes and reviving them after recovery.
Load Balancing Strategies: Built-in Round Robin, Least Connections, and IP Hash.

This means you can write a simple Go program that handles some business logic while also distributing traffic like a gateway, and it is extremely flexible.

Quick Start: Build Your Gateway

Assume we want to start a gateway locally to distribute traffic to two backend service clusters (e.g., "Transaction Service" and "User Service").

1. Basic Code Implementation

With just a few lines of code, your Gin service can transform into a reverse proxy:

package main

import (
    "fmt"
    "github.com/go-dev-frame/sponge/pkg/gin/proxy"
    "github.com/gin-gonic/gin"
)

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

    // Initialize proxy middleware; default management interface is mounted at /endpoints
    p := proxy.New(r)

    // Configure routing rules
    setupProxyRoutes(p)

    // Your Gin can still handle normal routes
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{"message": "I am the gateway itself"})
    })

    fmt.Println("Gateway started, listening on :8080")
    r.Run(":8080")
}

func setupProxyRoutes(p *proxy.Proxy) {
    // Rule 1: Dispatch requests starting with /proxy/ to cluster A
    // Defaults to Round Robin strategy, health check interval of 5 seconds
    err := p.Pass("/proxy/", []string{
        "http://localhost:8081", 
        "http://localhost:8082",
    })
    if err != nil {
        panic(err)
    }

    // Rule 2: Dispatch requests starting with /personal/ to cluster B
    err = p.Pass("/personal/", []string{
        "http://localhost:8083", 
        "http://localhost:8084",
    })
    if err != nil {
        panic(err)
    }
}

Looking at this, you will find it very similar to Nginx's proxy_pass logic, but it is compiled into the binary file.

2. Advanced Configuration: More Than Just Forwarding

Production environments often require finer control. For example, for services requiring Session persistence, we need the IP Hash strategy; for critical services, we need custom health check timings.

proxy.New and p.Pass both support Option pattern configuration, which is very "Go Style":

// Fine-grained configuration when registering routes
err := p.Pass("/proxy/", []string{"http://localhost:8081", "http://localhost:8082"}, proxy.Config{
    // Use IP Hash algorithm to ensure requests from the same user hit the same machine
    proxy.WithPassBalancer(proxy.BalancerIPHash),
    // Custom health check: once every 5 seconds, timeout 3 seconds
    proxy.WithPassHealthCheck(time.Second * 5, time.Second * 3),
    // You can even add middleware (e.g., authentication) to this proxy route individually
    proxy.WithPassMiddlewares(AuthMiddleware()),
})

This step is very powerful. In Nginx, configuring authentication is usually troublesome (requiring modules like auth_request), whereas in Go, this is just a standard Gin Middleware.

Killer Feature: Runtime Dynamic Management

This is the most attractive part of this library.

Previously, if localhost:8081 went down, or you needed to scale out to include a new machine 8085, you usually had to modify configuration and restart the gateway. But here, after the proxy service starts, it automatically exposes management APIs (default under /endpoints).

You can command your gateway directly via HTTP requests.

Scenario 1: Service Scaling

Traffic spikes during a sale, and you temporarily start a new machine http://localhost:8085. You want the gateway to distribute traffic to it immediately.

Send a POST request directly:

curl -X POST http://localhost:8080/endpoints/add \
     -H "Content-Type: application/json" \
     -d '{
           "prefixPath": "/proxy/",
           "targets": ["http://localhost:8085"]
         }'

Takes effect instantly. The new node automatically joins the load balancing pool and begins accepting health checks.

Scenario 2: Node Offline / Canary Release

If you find 8085 has a high error rate or needs an upgrade, you need to take it offline gracefully.

curl -X POST http://localhost:8080/endpoints/remove \
     -H "Content-Type: application/json" \
     -d '{
           "prefixPath": "/proxy/",
           "targets": ["http://localhost:8085"]
         }'

Scenario 3: Monitoring Dashboard

If you want to know the current health status of all backend nodes, directly call the list interface:

curl http://localhost:8080/endpoints/list?prefixPath=/proxy/

The returned result is clear:

{
  "prefixPath": "/proxy/",
  "targets": [
    {"target": "http://localhost:8081", "healthy": true},
    {"target": "http://localhost:8082", "healthy": false} 
  ]
}

Summary and Suggestions

When should you use it?

Go Tech Stack Teams: If your team primarily uses Go, maintaining a Go-based gateway is much easier than maintaining Nginx configuration files.
High Customization Logic: For example, if you need to read a blocklist from Redis before forwarding, or perform complex signature verification on the request body, writing middleware in Go is much more comfortable than writing Nginx Lua scripts.
Small/Medium Dynamic Environments: For lightweight deployments outside of k8s, or development/test environments, dynamically adjusting routing via API is very convenient.

When should you still use Nginx?

Static resource serving (CDN level).
Extremely massive concurrency (Millions of QPS), where Nginx's C-based optimizations remain the ceiling.

Overall, Gin Reverse Proxy offers a middle ground between "hard coding" and "pure operations tools." It returns control of load balancing and reverse proxying to developers, allowing the network layer to be as flexible and versatile as business logic.

If you are fed up with frequently reloading Nginx, try this solution in your next project.

proxy is a built-in library of Sponge. Sponge is a powerful and easy-to-use Go development framework that integrates code generation, Web framework (Gin), and microservice framework (gRPC), covering the full lifecycle from project generation, development, and testing to API documentation and deployment. Sponge aims to improve backend service development efficiency and code quality, eliminating tedious repetitive work and focusing on the implementation of core business logic.

Sponge's core philosophy is "Definitions as Code". By parsing SQL, Protobuf, and JSON configuration files, it generates modular service code. Developers can flexibly combine these modules to quickly build various backend systems such as RESTful APIs, gRPC, HTTP+gRPC, gRPC Gateway, or microservice clusters via a low-code approach.

Sponge Github Address: https://github.com/go-dev-frame/sponge

No More Complex Scripts! PerfTest Distributed Load Testing Uses a Single YAML to Orchestrate Massive Cluster Tests Gracefully

gvison — Tue, 14 Oct 2025 11:00:49 +0000

Preface

In the previous article, we detailed the single-machine stress testing capabilities of perftest, showcasing how it achieves high-performance testing for HTTP/1.1, HTTP/2, HTTP/3, and WebSocket with a minimalist command-line interface. However, when dealing with large-scale business systems, distributed service deployments, and complex network links, the capabilities of a single machine are clearly insufficient to simulate real-world production environments.

Fortunately, perftest goes beyond a single machine. It also supports distributed cluster stress testing. Through a Collector + Agent architecture, you can easily launch tests from multiple machines simultaneously, enabling performance assessments at the scale of millions or even tens of millions of concurrent users.

Why Choose Distributed Cluster Stress Testing?

1. Replicate Real-World Traffic Scenarios
Single-machine testing cannot simulate user access behavior from different geographical regions, network environments, and latency conditions. Distributed cluster testing allows requests to be sent from multiple geographical nodes at the same time, more closely resembling a real production environment.

2. Break Through Performance Bottlenecks
When a single machine's CPU, memory, or network bandwidth reaches its limit, the test results are no longer accurate. perftest avoids a single point of failure by distributing requests across multiple machines.

3. Validate the System's Horizontal Scaling Capabilities
When your application runs in Kubernetes, a Service Mesh, or a microservices cluster, distributed stress testing can help you verify your system's load balancing strategies and elastic scaling effectiveness under high concurrency scenarios.

4. Provide More Comprehensive Data Observation
Real-time monitoring in cluster mode not only allows you to see overall QPS and latency curves but also to break down the performance distribution of each Agent node, precisely locating performance bottlenecks.

Architecture Design: Collector and Agent

The distributed stress testing system of perftest adopts a minimalist and stable Master-Agent (Collector-Agent) architecture, as shown in the diagram below:

Collector (Master Node)
Responsible for creating test sessions, scheduling all Agents, aggregating performance metrics, and displaying overall data in real-time on a Web UI.
Agent (Execution Node)
Actually executes the stress testing tasks and periodically pushes performance metrics to the Collector. The Agent features mechanisms like automatic registration, hot-reloading of configurations, and automatic reconnection to ensure stable operation in large-scale distributed scenarios.

You can think of it as a "commander" (Collector) directing a stress testing "army" composed of multiple "soldiers" (Agents)—with a single command, all nodes open fire simultaneously.

How It Works: From Registration to Aggregation

The entire stress testing process is very clear:

Start the Collector: The Collector service starts and provides a web management interface.
Create a Test Session: In the web interface, specify the desired number of agent nodes to participate in the test, then start a new session.
Start the Agents: After each agent starts, it reads its configuration file and automatically registers with the Collector.
Start the Test: Once the preset number of agents have completed registration, the Collector notifies all agents to start the stress test simultaneously.
Aggregate Results: Agents push performance data (throughput, latency, etc.) to the Collector in real-time, which the Collector displays on a live dashboard.
Test End and Report Export: After the test is finished, the Collector automatically generates a complete report in Markdown format, which can be downloaded and saved with one click.

Tip: The Agent actively listens to its agent.yml configuration file. Any changes will be automatically hot-reloaded without restarting the agent process, making it very convenient to adjust test parameters.

Quick Start: A Simple Cluster Example

Here is a basic cluster example with 1 Collector and 3 Agents:

Role	IP Address	Description
Collector	192.168.1.20	Management Node
Agent 1	192.168.1.101	Execution Node
Agent 2	192.168.1.102	Execution Node
Agent 3	192.168.1.103	Execution Node

Step 1. Start the Collector

On machine 1 (192.168.1.20), start the Collector service:

sponge perftest collector

Access http://192.168.1.20:8888 in your browser, create a new test session, and set the number of Agents to 3.

Step 2. Start the Agents

Example agent.yml configuration file for each Agent:

# 1. Protocol Configuration (supports: http | http2 | http3)
protocol: http

# 2. Target API Configuration
testURL: "http://localhost:8080/get"
method: "GET"        # Supported methods: GET | POST | PUT | PATCH | DELETE
body: ""             # Supported data types: JSON, Form-data, Text. e.g.: "{\"key\": \"value\"}"
headers:
  - "Authorization: Bearer <token>"
  #- "Content-Type: application/json"

# 3. Stress Test Strategy (choose one: fixed duration or fixed number of requests)
duration: 10s        # e.g.: 10s, 1m, 2h
# total: 500000      # Total number of requests

# 4. Service Discovery, ensure the collector and agent services can communicate
collectorHost: "http://192.168.1.20:8888"      # Address of the Collector service
agentHost: "http://<agent-host-ip>:6601"       # The accessible IP and port of the current agent
agentPushInterval: 1s                          # Metric push frequency

Important Note:

Please replace <agent-host-ip> in agentHost with the actual IP address of each agent machine.

For the same test session, the testURL and method in all agent configuration files must be identical.

Start the agent processes on machines 2, 3, and 4 respectively:

sponge perftest agent -c agent.yml

Once all 3 Agents have successfully registered, the Collector will automatically synchronize and start the stress test, displaying real-time graphs as shown below:

After the test is complete, you can also click "Download Test Report" to get a detailed Markdown report, including all statistical metrics and chart data, for subsequent analysis or performance regression comparisons.

Automated Deployment in Kubernetes Scenarios

For large-scale testing, managing nodes manually is impractical. perftest can be easily deployed on Kubernetes, allowing you to scale your number of agents effortlessly.

A complete YAML deployment manifest and specific operational examples are provided. Please see the documentation Deploying perftest on Kubernetes.

Horizontal Comparison: The "Players" in Distributed Stress Testing

The distributed capability of perftest is also unique. Let's see how it compares to other mainstream distributed stress testing tools in the industry.

Feature / Tool	JMeter	Locust	k6 (Distributed)	perftest (Distributed)
Core Architecture	GUI Master + Agents	Code-based Master/Worker	k6 Operator / CRD	Web-UI Collector + Agents
Test Definition	GUI (XML)	Python script	JavaScript script	YAML Configuration
Resource Consumption	High (Java/GUI)	Medium (Python/gevent)	Medium (Go)	Low (Go)
K8s/Cloud-Native	Complex (requires self-containerization)	Good (provides Helm Chart)	Excellent (native Operator)	Natively Friendly (provides deployment manifest)
Ease of Use	High	Medium	Medium	Extremely Low
Dynamic Configuration	Requires restart	Requires restart	Requires restart	✅ (Hot-reloading)

JMeter (The Veteran): The most powerful and comprehensive stress testing tool, with a vast ecosystem of plugins. However, its Java and GUI-based architecture makes it resource-intensive, and its deployment and automation in cloud-native environments are relatively cumbersome.
Locust (The Coder's Choice): Defines user behavior in Python, making it very friendly for programmers and easy to write complex business logic. Its Master/Worker architecture is clear, but large-scale deployment still requires some DevOps experience.
k6 (The Modern Contender): k6 is deeply integrated with Kubernetes for distributed testing, managing tests through an Operator and CRDs (Custom Resources), making it a powerful choice for cloud-native scenarios. However, it still relies on writing JavaScript scripts to define the load.
perftest (The Pragmatist): perftest continues its "simple and pure" philosophy in distributed scenarios. It replaces scripts with configuration, greatly lowering the barrier to entry for distributed stress testing. Its Collector + Agent architecture is clear and easy to understand, allowing tests to be initiated and monitored via a Web UI, and it provides out-of-the-box Kubernetes deployment files. The hot-reloading feature makes adjusting test parameters exceptionally efficient, eliminating the need to rebuild and redeploy, perfectly fitting the needs of agile iteration.

Conclusion: From Single-Point to Cluster, Simple but Not Simplistic

perftest does not intend to replace comprehensive "Swiss Army knife" tools like k6 or JMeter. Instead, it offers developers and SRE engineers a more modern, focused, and cloud-native-friendly option.

It cleverly covers two core scenarios of performance testing:

For single-machine stress testing, it is a sharp "scalpel," allowing you to quickly validate and compare the latest network protocols, including HTTP/3 and WebSocket, with a minimal learning curve. Through seamless integration with Prometheus, it incorporates performance data into your observability system.
For distributed stress testing, it is a lightweight "command center." Through a concise Collector-Agent architecture and a configuration-driven model, it minimizes the complexity of large-scale stress testing. Its native friendliness to Kubernetes allows it to easily scale to hundreds or thousands of load-generating nodes to simulate massive concurrency.

When your needs are:

Single-machine or cluster stress testing of services or systems using http1/2/3 protocols.
Quickly validating the performance of the latest network protocols (HTTP/3, WebSocket).
Seamlessly integrating performance testing with the Prometheus monitoring system for visualized stress testing.
Performing lightweight performance regression testing in CI/CD.
Quickly setting up and executing large-scale distributed stress tests without writing complex scripts.
Easily achieving elastic scaling of stress testing capabilities in a Kubernetes environment.

Then, perftest is definitely worth a try. In an era of increasingly complex tools, such a tool that can smoothly scale from a "small and beautiful" single-machine utility to a "broad and strong" distributed platform may be the best answer you've been looking for to tackle modern web performance challenges.

perftest is a component of the Sponge ecosystem. Sponge is a powerful and easy-to-use Go development framework that adheres to the core philosophy of "Definition is Code." It enables the easy construction of stable, reliable, and high-performance backend services through a low-code approach, supporting various service types including RESTful API, gRPC, HTTP+gRPC, and gRPC Gateway. Sponge's built-in AI assistant can perceive service code files and their context, generating more suitable business logic code under precise AI constraints, significantly improving development efficiency.

Sponge Github Address: https://github.com/go-dev-frame/sponge

PerfTest: The "Swiss Army Knife" of Load Testing Tools, Natively Supporting HTTP/1/2/3 and WebSocket with Real-Time Monitoring

gvison — Fri, 12 Sep 2025 15:48:57 +0000

Preface

Every backend engineer keeps a few load testing tools handy in their toolbox. When we want to quickly check the performance of an API, ab is often the first tool we reach for. If we’re chasing maximum single-machine QPS, wrk is usually the weapon of choice. And when it comes to writing complex test scenarios, k6, with its powerful scripting capabilities and developer-friendly ecosystem, has become the go-to for many teams. Of course, there are plenty of other tools out there as well.

All of these tools are great, but technology doesn’t stand still. HTTP/3 has moved from being “the future” to “the present,” WebSocket use cases are becoming more common, and in today’s DevOps world, one-off, static performance reports are no longer enough. What we really need is real-time performance data that integrates seamlessly into our observability stack.

This naturally raises a question:
Is there a tool that’s as simple and straightforward as ab, supports modern protocols like HTTP/3 and WebSocket, and integrates with monitoring systems like Prometheus just as easily as k6?

The answer is yes. Let me introduce you to a rising star—perftest.

What is PerfTest?

perftest is a lightweight, high-performance load testing tool integrated into the Sponge Go framework. Think of it as a “special forces operator” designed for modern network protocols and cloud-native monitoring.

Its key highlights are:

Protocol versatility: Native support for HTTP/1.1, HTTP/2, HTTP/3, and WebSocket.
Flexible modes: Run a fixed number of requests (--total) or apply load continuously for a given duration (--duration).
Seamless monitoring integration: Its killer feature. perftest can stream real-time metrics (QPS, latency, etc.) directly into Prometheus or any custom HTTP endpoint—your Grafana dashboards will light up instantly.
Simplicity: Everything is controlled through clean, minimal CLI parameters, making it incredibly easy to learn.

When should you use PerfTest?

There are a few scenarios where perftest really shines:

Testing cutting-edge protocols
If your service supports HTTP/3 or gRPC-Web (built on HTTP/2+), perftest helps you measure the performance benefits without extra hassle.
Load testing real-time communication
Have a chat app, real-time trading platform, or collaborative editor using WebSockets? perftest can simulate large client loads and high-frequency message storms to validate your backend capacity.
Performance checks in CI/CD
Add perftest as a step in your pipeline. After every merge, it can benchmark critical endpoints, push metrics to Prometheus, and trigger alerts when performance regresses.
Quick and simple validation
Don’t want to write a full k6 script just to test one API? With perftest, you can run a concurrency test in seconds and get a detailed report.

Getting Started

Since perftest is built in Go, installation is as simple as:

go install github.com/go-dev-frame/sponge/cmd/sponge@latest

Once installed, you’re ready to run tests. Let’s look at some examples.

HTTP Load Testing Example

Benchmark an HTTP/1.1 endpoint with 50 workers and 1 million requests:

sponge perftest http \
    --worker=50 \
    --total=1000000 \
    --url=http://localhost:8080/user/1

Run a continuous 1-minute test instead:

sponge perftest http \
    --worker=50 \
    --duration=1m \
    --url=http://localhost:8080/user/1

Switching to HTTP/2 or HTTP/3? Just replace http with http2 or http3. Everything else stays the same.

Want live metrics in Prometheus? Add --prometheus-job-name and --push-url.

At the end, you’ll get a detailed report:

========== HTTP/1.1 Performance Test Report ==========

[Requests]
  • Total Requests:    1000000
  • Successful:        1000000 (100%)
  • Failed:            0
  • Total Duration:    8.55 s
  • Throughput (QPS):  116914.5 req/sec

[Latency]
  • Average:           0.42 ms
  • Minimum:           0 ms
  • Maximum:           22.41 ms
  • P25:               0 ms
  • P50:               0.51 ms
  • P95:               1.18 ms

[Data Transfer]
  • Sent:              25000000 Bytes
  • Received:          49000000 Bytes

[Status Codes]
  • 200:               1000000

[Push Statistics]
  • ok

Prefer a UI instead of CLI? Just run:

sponge run

Then navigate to Public → Generate Performance Test Report, fill in parameters, and start testing.

Simulating a WebSocket Message Storm

Let’s simulate 100 users chatting simultaneously, each sending 2 messages per second (every 500ms) for 5 minutes:

sponge perftest websocket \
    --worker=100 \
    --duration=5m \
    --send-interval=500ms \
    --body={\"event\":\"message\",\"payload\":\"Hello, perftest!\"} \
    --url=ws://localhost:8080/ws

At the end, you’ll see clear stats on connection success rates, messages sent/received, and throughput.

PerfTest vs. ab, wrk, k6

How does perftest compare against the classics?

Feature / Tool	ab	wrk / wrk2	k6	perftest
Core focus	Simple validation	Extreme performance	Complex scenarios & developer UX	Modern protocols & monitoring
HTTP/1.1	✅	✅	✅	✅
HTTP/2	❌	❌ (special branch)	✅	✅
HTTP/3 (QUIC)	❌	❌	❌ (community add-on)	✅ (native)
WebSocket	❌	❌ (script needed)	✅	✅
Real-time metrics	❌	❌	✅	✅ (native)
Scripting	None	Lua	JavaScript	None
Ease of use	Very low	Medium	Medium	Very low

Deep Dive

ab (The Old Guard): Simple and reliable, but limited to HTTP/1.1.
wrk (The Speedster): Blazing fast, great for raw throughput, but weak protocol support.
k6 (The Powerhouse): Rich ecosystem, powerful scripting, widely adopted, but HTTP/3 support is still unofficial.
perftest (The Specialist): Excels in two areas:

Cutting-edge protocol support (HTTP/3, WebSocket).
Native integration with Prometheus for effortless observability.

Conclusion

perftest is a modern, focused load testing tool designed for today’s cloud-native world.

It’s perfect if you need to:

Benchmark new protocols like HTTP/3 or WebSocket.
Stream performance metrics directly into Prometheus and visualize them in Grafana.
Add lightweight performance checks to your CI/CD pipeline.
Use something stronger than ab but lighter than k6.

In short, perftest is like a sharp scalpel: precise, efficient, and built for modern performance testing. At a time when tools are getting bigger and heavier, this small but powerful utility might be exactly what you’ve been looking for.

Upcoming: Distributed cluster testing, with a central coordinator managing multiple nodes.

💡 About Sponge
Sponge is a powerful and easy-to-use Go framework. With the philosophy of “Definition is Code”, it makes it easy to build stable, reliable, high-performance backend services using a low-code approach. It supports RESTful API, gRPC, HTTP+gRPC, and gRPC Gateway.
Its built-in AI assistant can analyze your service code in context and generate business logic intelligently, significantly improving development efficiency.

👉 GitHub: https://github.com/go-dev-frame/sponge

Sponge: A Framework That Reshapes the Go Development Experience and Supercharges Your Projects

gvison — Sun, 24 Aug 2025 15:38:51 +0000

Preface

Go is simple, efficient, and outstanding in concurrency performance—a true breath of fresh air in backend development. We love its purity and its “less is more” philosophy. But let’s be honest: this “purity” sometimes means starting from scratch, reinventing the wheel every single time.

Every day you’re writing similar boilerplate code, handling endless database CRUD operations, manually binding data and registering services for HTTP and gRPC… Feels draining, right? Project iterations fly by, requirements pile up, yet you’re still stuck with headaches about project structure, dependency management, logging, and configuration.

It’s like wanting to drive an F1 car, but instead spending all day hand-assembling the tires.

That’s the reality of the traditional Go development model. While it offers high flexibility and full control over details, the downsides are clear:

Efficiency bottlenecks: Repetitive tasks slow down the pace of core business logic.
Mental overhead: Beyond business needs, you also have to handle engineering, maintainability, and scalability issues.
Uneven wheel quality: Homemade wheels might “work,” but not necessarily “work well.” Robustness and performance often become concerns.

So we can’t help but ask: isn’t there a way to enjoy Go’s high performance while escaping this sea of repetitive work?

Enter the Modern Framework

Yes, there is! Just like equipping a hero with legendary gear, modern Go frameworks aim to solve these pain points. They integrate common components and best practices for project development, freeing you to focus on business logic.

You might worry: “Isn’t it too heavy?” “Will it restrict my freedom?” “What about performance overhead?”

Those are valid concerns. A good framework should act like a helpful assistant, not a boss barking orders. It should deliver:

High cohesion, low coupling: Rich functionality, but modular and flexible to use.
Convention over configuration: Follow widely accepted practices, reduce decision-making cost, and still keep extensibility.
Code generation, productivity boost: Automate repetitive, error-prone work so you can focus on creativity.

Which brings us to today’s star: Sponge—a “magic tool” dedicated to improving Go development efficiency and experience.

Sponge: Making Go Development as Natural as Breathing

Sponge is a fascinating open-source project. Its core philosophy is “definition is code”, embracing the low-code approach to free you from manual labor.

The coolest part? Like a sponge, it can “absorb” common capabilities and quickly build a stable, reliable, high-performance backend service for you.

One-Click Code Generation: CRUD Is Nothing

Picture this: your product manager hands you a prototype with dozens of database tables. Normally, you’d start grumbling while writing DAOs, services, APIs…

But in Sponge’s world, all you need is to define your database schema (say, a MySQL DDL), then… click a button!

Yes, you read that right. Sponge can generate a complete backend service codebase from your data model, including:

HTTP/gRPC service framework code
Service/Handler layer code
DAO layer data access code
Swagger (OpenAPI) documentation
Route registration code
Unit test code

For example, with a simple user table:

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

Traditionally, you’d have to write a GORM model, create CRUD code, maybe run GORM Gen, then still define API endpoints, register routes, and write handlers—a few hundred lines of code easily.

With Sponge, just go to its code generation page, choose your service type (http or grpc), enter the database DSN, select the user table, and click “Generate Code.” Duang! You instantly get a fully functional, well-structured service. All that’s left is adding your unique business logic into the generated templates.

Microservices? Piece of Cake!

Sponge is built with microservices in mind. It comes with service discovery, load balancing, circuit breaking, rate limiting, distributed tracing, and more—all integrated out of the box.

Instead of struggling to stitch these features together, Sponge has already paved the way. It decouples backend services into flexible, Lego-like modules, making it effortless to scale from monoliths to complex microservice clusters.

Built-In AI Assistant: Turbocharging Your Coding

Here’s the kicker: Sponge includes an AI assistant (supporting DeepSeek, ChatGPT, Gemini, etc.).

When you need to implement business logic, just summon the AI—it will help write the actual code and merge it into your project.

It’s like strapping a turbo engine onto your development workflow!

Don’t Hesitate—Embrace the Change!

From manual gear to automatic, from building your own car to driving a supercar, technology evolves to boost our efficiency and experience.

Sticking to “pure native Go” is admirable, but if a powerful framework can help you achieve more with less effort, why not embrace it? Sponge doesn’t take away your control over Go—it raises you higher, so you can focus on meaningful, challenging, and valuable work.

Sponge is a framework worth trying. It solves many Go development pain points in a friendly way, letting developers truly “focus only on business logic.”

Head over to Sponge’s GitHub repo and try it out for your next project. Trust me, once you experience this “flying” feeling, you’ll never look back.

Sponge GitHub Repo:
https://github.com/go-dev-frame/sponge

Master Go Distributed Tasks in 3 Steps! The Asynq Library Makes Async Jobs Simpler Than Ever

gvison — Thu, 07 Aug 2025 13:23:51 +0000

How Many Pitfalls of Go Background Tasks Have You Encountered?

In Go application development, there are always tasks that are not suitable for immediate execution, such as:

Sending emails/SMS: Should users have to wait after clicking a button? That's a terrible experience!
Computationally intensive tasks: Generating reports, data analysis—if the CPU is constantly occupied, will all other requests get stuck?
Scheduled tasks: Running statistics at midnight, synchronizing data every hour—are you really going to write an infinite time.Sleep loop for this?

Therefore, smart developers like us throw these tasks into an asynchronous task queue, letting background "workers" handle them.

It sounds great in theory, but once you start, you might run into these pitfalls:

Goroutine Explosion: When tasks pile up, you might be tempted to call go func() wildly, leading to thousands of unmanageable Goroutines and immense scheduling pressure.
What if a Task Fails?: Due to network jitters or a service outage, is the task simply lost? A retry mechanism is essential!
Chaotic Task Priorities: Should a payment notification be treated the same as a log entry? Of course not!
Code Becomes a Mess: Defining tasks, serialization, registering handlers... when business logic gets entangled with queue management code, maintenance becomes a nightmare.

If you've experienced any of the pain points above, congratulations, sasynq is the "antidote" you've been looking for!

What is `sasynq`? And Why Can It Save You?

sasynq is a super easy-to-use wrapper built on top of asynq. Asynq is a stable, efficient, Redis-based distributed task queue, and sasynq makes it even simpler and smoother to use.

What are its advantages?

✅ Out-of-the-box: Supports Redis Cluster and Sentinel, eliminating single points of failure.
✅ Comprehensive Features: Priority queues, delayed tasks, deduplication, cancellation, and scheduled tasks are all supported.
✅ Safe and Reliable: With retries, timeouts, and deadlines, you'll never have to worry about losing tasks again.
✅ Extremely Simple API: Compared to the native asynq, writing code is more elegant and clear.

In short, it makes complex things incredibly simple.

How Easy is `sasynq` to Use? Let's See the Code!

① Defining a Task

sasynq makes task definition effortless.

// example/common/task.go
const TypeEmailSend = "email:send"

// Task payload
type EmailPayload struct {
    UserID  int    `json:"user_id"`
    Message string `json:"message"`
}

// Task handler
func HandleEmailTask(ctx context.Context, p *EmailPayload) error {
    fmt.Printf("[Email] Email sent successfully to user %d!\n", p.UserID)
    return nil
}

Isn't that clean? Just define the payload and the handler, and no more manual json.Unmarshal.

② Enqueuing Tasks: The Ultimate Simplicity

One-off Task Producer

payload := &common.EmailPayload{UserID: 101, Message: "Important task!"}
_, _, err := client.EnqueueNow(common.TypeEmailSend, payload,
    sasynq.WithQueue("critical"),
    sasynq.WithRetry(3),
)

EnqueueNow, EnqueueIn, EnqueueAt—the function names are self-explanatory! Use sasynq.WithXXX for method chaining to configure queues, retries, and deadlines in an intuitive and elegant way.

Periodic Task Producer

payload := &common.EmailPayload{UserID: 102, Message: "Periodic task!"}
scheduler.RegisterTask("@every 1m", "request:url", &payload)

One line of code is all it takes to set up a scheduled task.

③ Consuming Tasks: Register a Handler in One Line, and You're Done!

srv := sasynq.NewServer(redisCfg, sasynq.DefaultServerConfig())

sasynq.RegisterTaskHandler(srv.Mux(), common.TypeEmailSend, sasynq.HandleFunc(common.HandleEmailTask))

srv.Run()

No redundant code. Register → Run → Done!

Canceling a Task

For a one-off, pending task:

inspector.CancelTask(queue, taskID)

For a periodic task:

scheduler.Unregister(entryID)

Cancel a task with a single line of code.

Summary: Why Choose `sasynq`?

Simpler: Minimalist API design and clear code structure.
More Powerful: Fully covers all common scenarios with support for retries, deduplication, delays, scheduling, and priorities.
Safer: Deadlines, timeouts, and retry strategies provide better control over task processing.

If you're looking for a simple, efficient, and feature-rich asynchronous task solution for your Go project, sasynq is the best choice.

sasynq URL: github.com/go-dev-frame/sponge/pkg/sasynq

sasynq is a sub-component of the Sponge framework. Sponge is a powerful and easy-to-use Go development framework based on the core principle of "Definition is Code." It helps developers easily build stable, reliable, and high-performance backend services (including RESTful API, gRPC, HTTP+gRPC, gRPC Gateway, etc.) in a "low-code" manner.

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

Comparative Analysis of Go Frameworks: Kratos, Go-Zero, GoFrame, and Sponge

gvison — Mon, 14 Jul 2025 13:50:46 +0000

The prosperity of the Go language community is as lively as a summer night food stall, with a dazzling array of frameworks to choose from. Today, let's act as "connoisseurs" and talk about the four "martial arts masters": Kratos, Go-Zero, GoFrame, and Sponge, to see which one you should bet your next project on.

When starting a new project, are you scratching your head again over which framework to choose? On one hand, there's "analysis paralysis," and on the other, the "holy wars" among the senior developers in your team. It's almost more tiring than writing code.

Today, let's bring four Go frameworks with distinct styles—Kratos, Go-Zero, GoFrame, and Sponge—onto the stage. We'll discuss their tempers, characteristics, and unique skills to help you find the one that's the perfect match.

The Arena Showdown: Which One is Your Cup of Tea?

Framework Comparison

Feature/Framework	kratos	go-zero	goframe	sponge
Design Philosophy	Microservices framework, emphasizing modularity and extensibility	High-performance, simple, and easy-to-use, oriented towards microservices	Backend development framework, emphasizing development efficiency and ease of use	Adheres to the low-code philosophy of "Definition is Code," emphasizing ease of use, development efficiency, and extensibility
HTTP Service	Supported	Supported	Supported	Supported (gin, gin+protobuf combination)
RPC Service	Supported (gRPC)	Supported (gRPC)	Supported (gRPC)	Supported (gRPC)
HTTP+RPC Hybrid Service	Supported (http+gRPC)	Not Supported	Not Supported	Supported (gin+gRPC)
Configuration Management	Supports multiple config sources (file, env variables, etc.)	Supports multiple config sources (file, env variables, etc.)	Supports multiple config sources (file, env variables, etc.)	Supports multiple config sources (file, env variables, etc.)
Logging System	Supports multiple log output formats and levels	Supports multiple log output formats and levels	Supports multiple log output formats and levels	Supports multiple log output formats and levels
ORM Support	Not supported (requires integrating third-party libraries)	Built-in ORM	Built-in ORM, supports multiple databases	Built-in ORM (gorm, mongo), supports extending with other ORM code
API Generation	Supports automatic API generation	Supports automatic API generation	Supports automatic API generation	Supports auto-generating API by parsing SQL, Protobuf, or JSON
Cache Support	Supports multiple caches (Redis, local memory)	Supports multiple caches (Redis, Memcached, etc.)	Supports multiple caches (Redis, Memcached, etc.)	Supports multiple caches (Redis, local memory)
Service Registry & Discovery	Supported (etcd, consul, nacos, etc.)	Supported (etcd, consul, etc.)	Supported (etcd, zookeeper, polaris, etc.)	Supported (etcd, consul, nacos, etc.)
Load Balancing	Supported	Supported	Supported	Supported
Circuit Breaking & Rate Limiting	Supported	Supported	Not Supported	Supported, and also supports setting fallback handlers after circuit breaking
Monitoring & Tracing	Supported (OpenTelemetry, Prometheus, etc.)	Supported (OpenTelemetry, Prometheus, etc.)	Supported (OpenTelemetry, Prometheus, etc.)	Supported (OpenTelemetry, Prometheus, etc.)
Middleware Support	Supported	Supported	Supported	Supported
Built-in AI	None	None	None	Yes, supports DeepSeek, ChatGPT, Gemini to generate and merge specific business logic code
Extensibility	High, modular design	High, supports custom plugins	High, supports custom components	Very high, modular design, and supports custom templates to generate code required for the project
Performance	High-performance	High-performance	High-performance	High-performance
Ease of Use	Medium	Medium, simple and easy-to-use	Simple and easy-to-use, out of the box	Extremely simple and friendly, out of the box, low-code development
Learning Curve	Medium	Medium	Low	Relatively Low
Documentation & Community	Detailed documentation, active community	Detailed documentation, active community	Detailed documentation, active community	Detailed documentation, active community
Applicable Scenarios	Medium to large-scale microservice projects	Medium to large-scale microservice projects	Small, medium, to large-scale projects	Medium to large-scale microservice projects

From the comparison above, everyone should have a rough picture of each "contestant":

Kratos: A product of Bilibili, battle-tested, focusing on microservices. It emphasizes "modularity" and "extensibility," exuding the rigor of an "architect."
Go-Zero: A lightning-fast efficiency tool. It pursues ultimate performance and simplicity, coming with its own code generation tools, like an efficiency-first assassin who strikes fatally without any delay.
GoFrame: An all-encompassing Swiss Army knife. Nicknamed "GF," its goal is to be your development "family bucket." It can do everything from web development to backend services, focusing on being "out of the box" and "development efficiency."
Sponge: The low-code black magician embracing the future. This is the newcomer "raising the bar." It brings a philosophy of "Definition is Code," not only wanting you to write less code but even having a built-in AI to help you write business logic, which is a bit of an unfair advantage.

Next, let's have a head-to-head confrontation from the angles everyone cares about most.

1. Learning Curve & Ease of Use: Who is More Approachable?

Winners: GoFrame, Sponge

GoFrame: If you're a Go novice or your project is all about being "short, simple, and fast," then GoFrame is definitely a blessing. Its design philosophy is "simple and easy to use," with clear documentation and an active community, lowering the barrier to entry.
Sponge: This one takes another "minimalist" route. Its low-code concept allows you to focus only on the most important business logic (defining data models and APIs), and it handles the rest. It can even use its built-in AI to help you fill in the business logic, making it extremely friendly for beginners with a very low learning curve. You can generate complete, compilable, and deployable service code (http or gRPC) just by connecting to a database.
Kratos and Go-Zero, due to their distinct microservice architecture concepts, require you to first understand their design patterns (like Kratos's layering, Go-Zero's .api specification), so their learning curve is slightly higher, at a "medium" level.

2. Microservice Support: Who is More Practical?

Evenly Matched: Kratos, Sponge

Potential Contender: Go-Zero

All four support gRPC and are capable of microservice development. But the details vary greatly.

Kratos and Sponge support HTTP+RPC hybrid services. This means you can use one set of code to expose both HTTP/JSON interfaces to the frontend and gRPC interfaces for internal service calls. This is very practical in modern microservice architectures and can effectively reduce maintenance costs.
Go-Zero and GoFrame are more "specialized" in this regard. The services they generate are either pure HTTP or pure gRPC, and they don't support mixing them in the same service instance.

So, if your microservice system requires flexible interface formats, Kratos and Sponge would be a better choice.

3. The Love-Hate Relationship with ORM: Built-in or Choose Your Own?

The Built-in Camp: Go-Zero, GoFrame, Sponge

The Freedom Camp: Kratos

This is a classic "sweet tofu pudding" versus "salty tofu pudding" debate.

GoFrame and Go-Zero both have powerful built-in ORMs that work out of the box, saving you the trouble of choosing and integrating one. For most projects, this is very convenient.
Sponge goes a step further. It not only has built-in GORM and Mongo drivers but also has designed a template mechanism. Theoretically, you can customize templates to have it generate any type of ORM code for you, which is very flexible.
Kratos insists on "architectural purity." It does not include a built-in ORM, giving the choice entirely to you. You are free to choose GORM, SQLx, or any library you like. This is an advantage for teams with specific technology stack requirements or those who like to have control over everything.

4. Code Generation: Who is the Real "Lazy Person's Gospel"?

The King: Sponge

The Strong Contenders: Go-Zero, GoFrame

In this era of "if it can be automated, never write it by hand," code generation capability is an important measure of a framework's productivity.

Go-Zero's goctl toolchain is very powerful. With an .api file, you can generate an entire service skeleton with one click, greatly improving development efficiency.
GoFrame's gf development tool generates corresponding service code through .yaml configuration, improving development efficiency.
Sponge takes this to the extreme. Its philosophy is "Definition is Code." You can start from SQL, Protobuf, or even JSON to generate service code, including Web and gRPC, with complete CRUD functionality. The most "outrageous" part is that it has built-in AI! You can have DeepSeek/ChatGPT/Gemini help you fill in the specific business logic code while maintaining a consistent code style. It truly achieves semi-automation from definition to business logic, making it the "pinnacle of development efficiency."

Kratos also supports code generation, but compared to the other three, it is slightly more conservative in terms of "automation" and "intelligence."

Who Should Your Project Choose?

Based on the comparison above, here are some selection recommendations:

If you are: A large enterprise or a die-hard fan of Bilibili, pursuing architectural standardization, stability, and ultimate extensibility.

👉 Choose Kratos.

Kratos is like an experienced architect who lays a solid foundation and provides a clear blueprint for you. Although it requires some initial investment to understand its design philosophy, this investment is worthwhile for large-scale microservice projects that need long-term evolution and collaboration among many people. It ensures your project won't "go off track" in the future.

If you are: A team pursuing ultimate performance and development efficiency, with a business centered around APIs.

👉 Choose Go-Zero.

Go-Zero is like a sharp dagger: fast, precise, and ruthless. All its designs are for performance and efficiency. With the powerful goctl tool, you can build and iterate API services like on a production line, which is very suitable for internet projects that need to quickly capture the market.

If you are: A small to medium-sized team pursuing efficient development and needing to quickly develop and validate projects.

👉 Choose GoFrame.

GoFrame is your "universal toolbox." It has everything, and everything works well. You don't need to spend too much time on technology selection and component integration to quickly implement business functions. Its development experience is very smooth, making it an excellent choice for rapid prototyping and small to medium-sized projects.

If you are: A team pursuing the ultimate in development efficiency, needing to maintain the flexibility and extensibility of the project architecture.

👉 Choose Sponge.

Sponge is a "magician" from the future. It uses the power of low-code and AI to push development efficiency to new heights. It can quickly build small and medium-sized web services, and like Kratos, it can also build complex large-scale microservice projects. It also supports hybrid services and is feature-complete. It is especially suitable for teams that want "all of the above" and is the ultimate weapon for improving the overall productivity of a team.

In Conclusion

Of course, there is no absolute "best" framework, only the "most suitable." Hopefully, this article helps you cut through the fog and see the true faces of these "masters."

The best way is to get your hands dirty, spend some time running their Hello World, and get a "feel" for them. After all, the code doesn't lie.

If you have used one or more of the above frameworks in your projects, feel free to leave your user experience in the comments section!

GitHub addresses for the 4 frameworks:

kratos: https://github.com/go-kratos/kratos
go-zero: https://github.com/zeromicro/go-zero
goframe: https://github.com/gogf/gf
sponge: https://github.com/go-dev-frame/sponge

Is Real-Time Pushing in Go Too Hard? Try Sponge SSE and Get It Done in One Click!

gvison — Wed, 02 Jul 2025 07:41:04 +0000

Hey Gophers! Have you ever encountered scenarios like these:

You're developing a backend monitoring system and want to display real-time data like CPU usage and memory consumption on the frontend, but the only way is to have the frontend send a request every few seconds, exhausting the server?
You want to build an information feed similar to Facebook or Twitter, where new messages are instantly "dinged" and pushed to the user's page, instead of waiting for them to scratch their heads and manually refresh?
Or, you simply want to notify a user: "Your delivery has been picked up by [Handsome John Doe] and is speeding your way!", rather than having them stare anxiously at the order page?

If you nodded to any of the questions above, then congratulations, you've probably been using the old method of "polling." It's like sending a subordinate to the kitchen every five seconds to ask, "Is the food ready yet?". Not only does the subordinate run their legs off, but the chef gets annoyed too.

Isn't there a more elegant way? Of course, there is! Today's star is Server-Sent Events (SSE), and it's here to save the day! And the Go SSE library we're about to introduce will give you this superpower with "one click"!

What is SSE? How is it different from WebSocket?

Before diving into the code, let's explain the principle in plain language.

SSE (Server-Sent Events), as the name suggests, are "events sent by the server." It's built on a standard HTTP connection, but this connection is a "long-lived" and unidirectional one.

Think of it as a radio broadcast:

The server is the radio station that broadcasts 24/7.
The client (browser) is the radio.

Once you tune your radio to the right channel (establish a connection), the station (server) can send you news and music (data) at any time, and you don't need to call every minute to ask, "Are there any new programs?".

So, how is it different from WebSocket?

SSE: It's a one-way street. Only the server can push data to the client. It's simple, lightweight, based on standard HTTP, and natively supports auto-reconnect. It's perfect for scenarios that only require server-to-client information pushing.
WebSocket: It's a two-way highway. The client and server can "shout" at each other at any time. It's more powerful, but the protocol is also more complex. It's suitable for scenarios like online chat and collaborative editing that require frequent two-way communication.

In summary, if your requirement is one-way notification from "server -> client," then SSE is the simpler, more appropriate "wheel" for the job.

What features does this Go library offer?

There are many SSE libraries on the market, but many only offer basic functionality. This sse library, however, is incredibly thoughtful, like an all-in-one butler:

High Performance: Excellent underlying design, capable of easily managing thousands of client connections.
Automatic Reconnection: Network jitter? User accidentally closed and reopened the page? No worries! The library has built-in mechanisms for automatic reconnection and event resending, ensuring no important messages are lost! (Requires persistent storage).
Message Persistence: You can store historical events in Redis, MySQL, or anywhere you like. Mom no longer has to worry about losing messages after a server restart.
Built-in Heartbeats: Automatically detects "zombie connections" and cleans them up in time, keeping the connection pool healthy.
Broadcast and Unicast: You can "whisper" to one or more specific users, or "shout" a broadcast to all online users.

Sounds cool, right? Just wait, seeing the code is even cooler!

Get Started in Three Minutes: Build Your First SSE Service

Let's use a simple example to see how easy it is to quickly set up a service with the sse library. Suppose we want to build a service that broadcasts "Hello World" to all clients every 5 seconds.

1. Server-side Code (`server.go`)

You'll need a Go environment and the Gin framework installed (this example uses Gin, but you can also use Go's native net/http).

go get github.com/gin-gonic/gin
go get github.com/go-dev-frame/sponge/pkg/sse

Then, create a main.go file:

package main

import (
    "fmt"
    "math/rand"
    "net/http"
    "strconv"
    "time"

    "github.com/gin-gonic/gin"
    "github.com/go-dev-frame/sponge/pkg/sse"
)

func main() {
    // 1. Initialize our SSE "Broadcast Center" (Hub)
    // Think of it as the main control room of the radio station
    hub := sse.NewHub()
    defer hub.Close()

    // 2. Create a web server with Gin
    r := gin.Default()

    // 3. Create a "/events" endpoint for clients to "tune in"
    r.GET("/events", func(c *gin.Context) {
        fmt.Println("New listener joined!")
        // For demonstration, we assign a random ID to each connecting client
        uid := strconv.Itoa(rand.Intn(999) + 1000)
        hub.Serve(c, uid)
    })

    // 4. [Optional] Create an endpoint to manually trigger a broadcast
    // You can test it with a curl command:
    // curl -X POST -H "Content-Type: application/json" -d '{"events":[{"event":"message","data":"This is a manual broadcast!"}]}' http://localhost:8080/push
    r.POST("/push", hub.PushEventHandler())

    // 5. Start a tireless "broadcaster" (goroutine)
    go func() {
        i := 0
        for {
            // Prepare a new message every 5 seconds
            time.Sleep(time.Second * 5)
            i++
            msg := "Hello everyone, this is automatic broadcast number " + strconv.Itoa(i) + "!"

            // Create a standard event
            event := &sse.Event{
                Event: "message", // Event type, can be customized
                Data:  msg,
            }

            // Call hub.Push to broadcast (passing nil for uids means broadcasting to everyone)
            fmt.Printf("Broadcasting: %s\n", msg)
            _ = hub.Push(nil, event)
        }
    }()

    fmt.Println("SSE server started at http://localhost:8080")
    // Start the server
    if err := http.ListenAndServe(":8080", r); err != nil {
        panic(err)
    }
}

See? It's super clear! Initialize Hub -> Create connection point -> Push message. Done!

2. Client-side Code (`client.go`)

Now, we need a "radio" to receive the messages. This library also provides a client implementation, which is very convenient.

package main

import (
    "fmt"
    "github.com/go-dev-frame/sponge/pkg/sse"
)

func main() {
    url := "http://localhost:8080/events"

    // 1. Create an SSE client pointing to our server address
    client := sse.NewClient(url)

    // 2. Register an event listener
    // Tell the client: "Once you receive an event of type 'message', execute the following function"
    client.OnEvent("message", func(event *sse.Event) {
        // event.Data is the message content we receive from the server
        fmt.Printf("Received a new broadcast! Content: [%s], ID: %s\n", event.Data, event.ID)
    })

    // 3. Start connecting!
    err := client.Connect()
    if err != nil {
        fmt.Printf("Connection failed, oh no: %v\n", err)
        return
    }

    fmt.Println("Radio is on, waiting for broadcast... (Press Ctrl+C to exit)")

    // Block the main program, waiting for the client to exit
    <-client.Wait()
}

Now, first run go run server.go, then open another terminal and run go run client.go.

You will see that the client prints a new message from the server every 5 seconds, without the client needing to do anything extra! That's the magic of SSE!

Of course, you can also use other clients for testing.

Advanced Usage: Make Your SSE Service More Powerful

The power of the sse library goes far beyond this.

Scenario 1: I don't want to lose a single message!

Imagine your service is pushing critical stock prices. If a client disconnects for 10 seconds due to network issues, they could miss out on a fortune!

This is where persistent storage and event resending come into play.

You just need to implement a simple Store interface to tell the sse library how to save and read events (e.g., using Redis).

// Pseudo-code: Implement your own Store
type MyRedisStore struct{ /* ... redis client ... */ }

func (s *MyRedisStore) Save(ctx context.Context, e *sse.Event) error {
    // Serialize the event into JSON and save it to a Redis List or ZSet
    return nil 
}

func (s *MyRedisStore) ListByLastID(ctx context.Context, eventType string, lastID string, pageSize int) ([]*sse.Event, string, error) {
    // Based on the lastID received by the client, query for new events from Redis
    return events, nextLastID, nil
}

// When initializing the Hub, include your storage and resend configuration
hub := sse.NewHub(
    sse.WithStore(&MyRedisStore{}), // Use your Redis storage
    sse.WithEnableResendEvents(),  // Enable the disconnect-and-resend feature!
)

It's that simple! Now, when a client disconnects and reconnects, it will automatically include the ID of the last message it received. The server, upon seeing this, will fetch all the missed messages from your Redis and send them all at once. The fortune is saved!

Scenario 2: I want to know if a message was successfully delivered.

Sometimes, you want to know if a message pushed to a specific user failed (for example, if that user has gone offline). You can set up a "failure callback function."

failedHandler := func(uid string, event *sse.Event) {
    // The code here will be executed when a push fails
    log.Printf("Oops, failed to push message %s to user %s! You can log it and retry later.", uid, event.ID)
}

hub := sse.NewHub(sse.WithPushFailedHandleFn(failedHandler))

This way, you can log, alert, or perform other compensatory actions for failed push events.

Summary

Server-Sent Events (SSE) is a powerful tool for building modern real-time applications. Especially when dealing with one-way data streams from the server to the client, it is lighter and simpler than WebSocket.

And this sse library is like a well-equipped Swiss Army knife. It not only provides the core functionality of SSE but also thoughtfully prepares a series of "deluxe features" for you, such as persistence, auto-reconnection, failure handling, and performance monitoring. It frees developers from the tedious tasks of connection management and exception handling, allowing them to focus on implementing business logic.

So, the next time your product manager comes up with a "real-time update" requirement, don't frown and write polling code anymore. Confidently puff out your chest and tell them, "No problem, I'll get it done in minutes!" Then, gracefully import "github.com/go-dev-frame/sponge/pkg/sse" and let the magic happen!

GitHub Address: Sponge SSE

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

gvison — Fri, 27 Jun 2025 10:44:18 +0000

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, and choose the table.

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: Why I'm Raving About Sponge

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

From Node.js to Go: How to Smoothly Transition from NestJS and Fall in Love with the Sponge Framework

gvison — Mon, 23 Jun 2025 09:23:30 +0000

Introduction

Hey NestJS veterans, let's be honest, developing APIs with decorators feels like waltzing on your keyboard—a spin with @Controller, a tiptoe with @Get, an elegant bow with @Injectable, and voilà, a decent backend service is up and running in no time. TypeScript's type checking is like a considerate butler, and the CLI's nest g is practically a magic wand in the coding world. A few keystrokes, and your project scaffold magically appears—it's exhilarating!

However, when the requirements suddenly shift to handling real-time data from millions of smart light bulbs, or your boss slams the table shouting, "Cut the server budget in half!", do you find yourself sighing at Node.js's single thread: "Buddy, can your small frame handle this?" Just then, Go strides in confidently, showcasing its concurrency primitives, compilation speed, and memory efficiency... Wow, who wouldn't be tempted?

But, when you eagerly open your Go IDE, ready to make your mark—wait, where are my @Decorators? Where's my dependency injection? My code generator? Switching from NestJS's "fully automatic coffee machine" to Go's "manual coffee bean grinding" mode, the drop in experience is like going from a five-star hotel buffet back to instant noodles with a sausage...

Five "Culture Shocks" for Node.js Developers Switching to Go

1. CLI Dependency Withdrawal

In NestJS:

# Just a few keystrokes, and the project scaffold magically appears!
nest new my-project
nest g module users
nest g controller users
nest g service users

In native Go:

mkdir my-project
cd my-project
go mod init my-project
mkdir -p users/handlers users/services
touch users/handlers/users.go users/services/users.go
# Then start manually writing a bunch of boilerplate code...

2. The Loss of Modularity and DI

The elegance of NestJS:

// Watch me wave my decorator wand, dependencies auto-injected!
@Module({
  imports: [DatabaseModule],
  controllers: [UserController],
  providers: [UserService],
})
export class UserModule {}

The "simplicity" of native Go:

// You need to manually initialize all dependencies
db := NewDB()
userRepo := NewUserRepository(db)
userService := NewUserService(userRepo)
userHandler := NewUserHandler(userService)

3. Missing Type Systems and Decorators

The comfort zone of NestJS:

// Route decorators are more versatile than a magician's hat
@Get(':id')
async getUser(@Param('id') id: string): Promise<UserDto> {
  return this.userService.findOne(id);
}

The explicit style of native Go:

func GetUser(c *gin.Context) {
    id := c.Param("id")
    user, err := userService.FindOne(id)
    if err != nil {
        c.JSON(500, gin.H{"error": err.Error()})
        return
    }
    c.JSON(200, user)
}

4. Shift in Asynchronous Programming Mindset

Node.js's linear thinking:

// `await` is my time-stopper; code must follow my script
async function getUserWithOrders(userId) {
  const user = await getUser(userId);
  const orders = await getOrders(userId);
  return { ...user, orders };
}

Go's concurrency philosophy:

// Welcome to the concurrency circus! Watch me juggle multiple task balls simultaneously!
func GetUserWithOrders(userId string) (UserWithOrders, error) {
    var user User
    var orders []Order
    var userErr, ordersErr error

    wg := sync.WaitGroup{}
    wg.Add(2)

    go func() {
        defer wg.Done()
        user, userErr = GetUser(userId)
    }()

    go func() {
        defer wg.Done()
        orders, ordersErr = GetOrders(userId)
    }()

    wg.Wait()

    if userErr != nil || ordersErr != nil {
        return UserWithOrders{}, fmt.Errorf("errors: %v, %v", userErr, ordersErr)
    }

    return UserWithOrders{User: user, Orders: orders}, nil
}

5. Change in Error Handling Habits

Node.js's try-catch:

// Error? Just toss it into the black hole for now
try {
  const result = await someAsyncOperation();
} catch (err) {
  console.error('Oops:', err);
}

Go's explicit error handling:

// Every error is a traffic light; must stop and check!
result, err := SomeOperation()
if err != nil {
    log.Printf("Oops: %v", err)
    return err
}

Sponge Framework – The Savior for Node.js to Go Transition Arrives

1. What is Sponge?

sponge is a powerful and easy-to-use Go development framework. Its core philosophy is to reverse-generate modular code by parsing SQL, Protobuf, and JSON files. These code modules can be flexibly combined into various types of complete backend services.

sponge provides a one-stop project development solution with excellent project engineering capabilities, covering code generation, development, testing, API documentation, and deployment. It helps developers easily build stable and reliable high-performance backend service systems (including RESTful API, gRPC, HTTP+gRPC, gRPC Gateway, etc.) in a "low-code" manner.

2. Sponge's Three Killer Features

① Code Generator – Faster Than Copy-Pasting

# Start the code generation UI
sponge run

Visit http://localhost:24631, and you'll see:

Automatically generate RESTful API, gRPC, HTTP+gRPC, gRPC Gateway, etc., service code
One-click CRUD code generation
Custom APIs only require filling in business logic

🚀 Effect: What used to take a day's work, now done in 1 minute!

② Modular Design – Project Structure as Clear as LEGOs

// Auto-generated user module structure
user/
├── api/
└── internal/
    ├── service/    // Business logic layer
    ├── dao/        // Data access layer
    ├── model/      // Entity classes
    ├── server/     // Service
    └── cache/      // Cache

③ Built-in Enterprise-Grade Components – Say Goodbye to Decision Paralysis

Web Framework √
gRPC Framework √
ORM √
Configuration Management √
Logging √ 
Tracing √
Monitoring √
Service Discovery √
...

Practical Comparison: Creating a User API

In NestJS:

// user.controller.ts
@Controller('users')
export class UserController {
  constructor(private userService: UserService) {}

  @Get(':id')
  async getUser(@Param('id') id: string): Promise<User> {
    return this.userService.findOne(id);
  }
}

// user.service.ts
@Injectable()
export class UserService {
  constructor(private userRepo: UserRepository) {}

  async findOne(id: string): Promise<User> {
    return this.userRepo.findOne(id);
  }
}

Sponge-generated version:

// Auto-generated handler
func (h *userHandler) CreateUser(c *gin.Context) { // Note: Original had CreatUser, common typo, corrected to CreateUser
    var req pb.CreateUserRequest // Corrected typo from CreatUserRequest
    if err := c.ShouldBindJSON(&req); err != nil {
        response.Error(c, err)
        return
    }

    // Assuming h.dao.CreateUser exists and follows this pattern.
    // The original snippet was:
    // if result, err := h.dao.CreatUser(ctx, &req); err != nil {
    //     return 0, err // This implies the DAO returns (uint64, error)
    // }
    // For a create operation, it might not return a result directly in the handler like this.
    // More typically, you'd call the service/DAO and then respond.
    // Let's adjust to a more common pattern for a handler.
    _, err := h.service.Create(c.Request.Context(), &req) // Example: calling a service method
    if err != nil {
        response.Error(c, err) // Assuming response.Error handles logging and JSON response
        return
    }

    response.Success(c)
}

// Auto-generated DAO (example, assuming direct call from handler was intended to be to DAO)
// The original was:
// func (d *dao) CreatUser(ctx context.Context, req *pb.CreatUserRequest) (uint64, error) {
//     // business logic code ...
//     if err := CreateUser(ctx, req); err != nil { // This CreateUser is undefined in this context
//         return 0, err
//     }
// }
// Let's make it more concrete based on typical DAO patterns
func (d *userDao) Create(ctx context.Context, req *pb.CreateUserRequest) (uint64, error) {
    // Business logic... e.g., convert req to a model, save to DB
    // userModel := &model.User{Name: req.Name, Email: req.Email} // Example
    // result, err := d.db.Create(userModel).Error // Example with GORM
    // if err != nil {
    //     return 0, err
    // }
    // return userModel.ID, nil
    // For simplicity, let's assume the business logic is here:
    log.Printf("Creating user: %v", req.GetName()) // Example of using the request
    // Placeholder for actual database interaction
    var userID uint64 = 1 // Dummy ID
    return userID, nil 
}


// Apart from the business logic, all other code is generated by sponge.

🔍 See the difference? Although the syntax is different, the development experience is highly consistent!

Why Node.js Developers Should Try Sponge?

Seamless Productivity Transition: Sponge's CLI and code generation capabilities let you experience NestJS-like development efficiency in the Go world.
Familiar "Recipe": Modular design, API definition methods, and microservice component integration will make you feel the familiarity of using NestJS.
"Best of Both Worlds": Enjoy the performance and concurrency advantages of Go while getting a NestJS-like efficient development experience.
Microservices "Power Tool": Sponge is inherently designed for microservices, integrating essential components like service governance, tracing, and monitoring.

Conclusion

The hardest part of transitioning to Go isn't the syntax, but the shift in mindset. While you can't write Node.js-style code in Go, you can enjoy a NestJS-like development experience with Sponge!

What are you waiting for? Get moving! Follow the official documentation and whip up a demo in 1 minute.

Sponge GitHub Address: https://github.com/go-dev-frame/sponge
Sponge Development Documentation: https://go-sponge.com/

From PHP to Go: How to Gracefully Escape the Laravel Comfort Zone and Experience the "Truly Sweet" Joy of Sponge

gvison — Wed, 28 May 2025 05:28:56 +0000

The Joys and Worries of an Experienced PHP Developer

Dear experienced PHP developers, honestly, isn't writing PHP incredibly satisfying? Variables can change types however you like, forgetting a semicolon is no biggie, and with the Laravel framework, a few php artisan make:controller commands and a CRUD is done, faster than instant noodles!

But when your website user base rockets upwards like a missile, or the boss suddenly talks about microservices and high concurrency, the PHP developers start huffing and puffing. That's when the Go developer at the next desk might wink at you: "Hey, buddy, wanna give me a try? Compiles into a single file, deployment is as easy as drinking milk tea, and the performance is stellar!"

Five Major "Soul-Searching Questions" for PHP Developers Switching to Go

1. Dynamic Typing vs. Static Typing: From "Wild Card" to "Sharp Dresser"

PHP's Joy:

$name = "PHP Developer";  // Today I'm a string
$name = 42;        // Tomorrow I want to be a number
$name = [];        // The day after, I'll be an array
// PHP: No problem, buddy, whatever makes you happy!

Go's "OCD":

var name string = "Go Developer"
name = 42 // Compilation will hit you hard: cannot assign int to string!
// Go: Buddy, we need to be clear, what exactly do you want to be?

2. OOP Differences: From "Inheritance Magic" to "Composition is King"

PHP's Comfort Zone:

class User extends Model {
    use SoftDeletes; // Traits are so useful!
}

Go's New World:

type User struct {
    gorm.Model
}

// Go: Inheritance? Doesn't exist! We focus on composition.

3. Framework Dependency Syndrome: From "Fully Automatic Luxury Car" to "Manual Tractor"

PHP's Luxury Experience:

php artisan make:model Product -mc
// One command generates model, controller, migration file

Go's DIY Life:

Manually choose Gin or Echo...
Manually choose GORM or Xorm, Sqlx, Ent...
Manually set up project structure...
// Feels like going back to the Stone Age

4. Concurrency Models: From "External Player" to "Native Champion"

PHP's Concurrency:

// Either rely on PHP-FPM multi-process
// Or bring in Swoole/Workerman as external help

Go's Killer Feature:

go func() {
    // Easily start a goroutine
}()
// Go: Concurrency? Piece of cake!

5. Dependency Management: From "Composer One-Stop Shop" to "Go Modules New Style"

PHP's Convenience:

composer require laravel/sanctum
// Everything done with one command

Go's Evolution:

go mod init
go get -u github.com/gin-gonic/gin
// While not as convenient as Composer, it's much better than the GOPATH era

Sponge Framework - The Go Language Plugin for Phpers

Missing the convenience of Laravel? Actually, Sponge isn't bad either!

What is Sponge?

sponge is a powerful and easy-to-use Go development framework. Its core concept is to generate modular code by parsing SQL, Protobuf, and JSON files. These modules can be flexibly combined to form various types of complete backend services.

Sponge provides a one-stop project development solution with excellent project engineering capabilities, covering code generation, development, testing, API documentation, and deployment. It helps developers easily build stable and reliable high-performance backend service systems (including RESTful API, gRPC, HTTP+gRPC, gRPC Gateway, etc.) in a "low-code" manner.

Sponge's Magic: Powerful Code Generation Engine

PHP-like Comfort Brought by Sponge:

Code Generation: As satisfying as artisan
All-in-one integration: Gin, GORM, Redis, etc., all packaged
Unified Standards: No more arguing about code style

With Sponge as your "plugin", you're guaranteed to complete the transition from PHP to Go with a smile!

Why PHP Developers Should Try Sponge?

Development Efficiency Takes Off: Sponge's code generation capabilities and rich integrated components allow you to experience the lightning-fast development speed of PHP frameworks within a Go project. No more starting from scratch like "eating raw meat and blood".
Familiar "Recipe", Familiar "Taste": Many features and the "convention over configuration" philosophy provided by Sponge will give you that sense of familiarity you had when using PHP frameworks like Laravel and Symfony, significantly flattening the learning curve.
The Joy of "Having Your Cake and Eating It Too": You get to enjoy the ultimate performance, powerful concurrency capabilities, and deployment convenience brought by the Go language, while also gaining the development efficiency and project standardization that come with a mature framework. Isn't this what we want?
Low Code, High Efficiency, Pure Bliss: You only need to focus on the core business logic. A large amount of generic, repetitive, and basic code is automatically generated by Sponge, truly letting you experience the fun of "low-code development".
Easily Master Modern Microservice Architecture: Sponge inherently supports the components and concepts required for microservice development, helping PHP developers build and migrate to cloud-native applications more easily.

Conclusion

The Sponge framework is like a powerful "accelerator" that helps you smoothly transition, enjoy the charm of the Go language, and maintain high development efficiency and happiness. By using Sponge to make up for engineering shortcomings, experienced Laravel developers can still race on the Go track!

Take action! What are you waiting for? Follow the official documentation and build a demo in 1 minute.

Sponge GitHub address: https://github.com/go-dev-frame/sponge
Sponge Development Documentation: https://go-sponge.com/zh/

From Java to Go: The Elegant Escape from Spring's Comfort Zone to the "True Fragrance" of Sponge

gvison — Sat, 24 May 2025 14:00:36 +0000

Hey, Java folks, isn't using the Spring full stack as comfortable as wearing thermal underwear? Maven and Gradle manage dependencies more closely than your own mom, and IntelliJ IDEA makes writing code as smooth as Dove chocolate. But with the cloud-native trend blowing like a mischievous wind, Go language, this young fellow, with concurrency performance comparable to Liu Xiang's speed and agility like Bruce Lee, has unexpectedly become the "new top flow" in the coding community!

Java developers entering the Go world for the first time feel like a Northerner visiting a Cantonese dim sum restaurant for the first time – don't know how to use the utensils, can't name the dim sum! Today, let's watch those "culture shock" moments that make you not know whether to laugh or cry, and then recommend a magic tool – the Sponge framework – that can turn Javaers into "local experts" in seconds!

Java Veterans' Showcase of Confusing Go Behaviors

1. The OOP Obsessive's Nightmare

Java folks write code like this:

// A class structure like a 3-bedroom apartment, inheritance like a family tree
public abstract class Animal {
   private String name;
   // Constructors showcasing a multitude of techniques
   public Animal(String name) { /*...*/ }
}
public class Cat extends Animal implements ClimbTree {
   // Method overloading played better than Russian nesting dolls
   public void meow() { /*...*/ }
}

Go newbies tremble:

// That's it? struct + composition is all you need?
type Animal struct { Name string }
type Cat struct { Animal }  // Ancestral inheritance? Doesn't exist!
func (c Cat) Meow() { println("Meow Punch!") }

Inner Monologue: My Six-Meridian Divine Swords of design patterns are just useless now?

2. The Soul-Searching Question of Exception Handling

Java-style elegance:

try {
   riskyOperation();
} catch (Exception e) {
   // Elegantly passing the buck to the global exception handler
}

Go-style robustness:

result, err := riskyOperation()
if err != nil {  // Writing foolproof code on every line
   return errors.New("Something went wrong, folks!")
}

Real experience: After three days of writing Go, the number of 'if err' exceeds three years of Java try-catch

3. Framework Dependency Withdrawal Symptoms

Day one after leaving Spring Boot:

Want to use ORM? gorm, xorm, sqlx, Ent - choose whatever you like (Choice paralysis strikes)
Need DI? wire, dig - various manual fiddling (Missing @Autowired for the 114514th second)
Microservice governance? Assemble Prometheus+Jaeger yourself (Gradually getting irritable)

4. The Dimensional Wall of Concurrency Programming

Java Old Hand:

// Thread pool configuration can fill three pages of A4 paper
ExecutorService executor = Executors.newFixedThreadPool(8);
Future<String> future = executor.submit(() -> "Async Task");

Go Newbie:

go func() {  // So lightweight, just like cracking melon seeds
   fmt.Println("I'm the coolest goroutine!")
}()

Confusing behavior: Always trying to find a Go version of ThreadPoolExecutor, only to find channels are actually quite good

Sponge Framework - The Go Language Plugin for Javaers

What is sponge?

sponge is a powerful and easy-to-use Go development framework. Its core idea is to generate modular code by parsing SQL, Protobuf, and JSON files, which can be flexibly combined to form various types of complete backend services.

Sponge provides a one-stop project development solution with excellent engineering capabilities, covering code generation, development, testing, API documentation, and deployment. It helps developers easily build stable, reliable, high-performance backend service systems (including RESTful API, gRPC, HTTP+gRPC, gRPC Gateway, etc.) in a "low-code" manner.

When you encounter setbacks and feel discouraged in the Go programming world, Sponge appears like a timely programming companion! This efficient framework, designed specifically to alleviate the "Java to Go adaptation difficulty", has three core components:

🚀 Low-Code Generator (Comparable to Spring Initializr)

# Start the code generation page
sponge run

Visit http://localhost:24631, you will see:

On the page, click the mouse a few times, and instantly generate a project containing these luxury packages:

🍔 Gin/gRPC Framework (Choose either)
🥤 GORM/Mongodb Database Package
🍟 JWT Auth + Tracing + Metrics
🍰 Swagger Documentation and more, all included

The effect is comparable to JHipster in the Java world, no more worrying about setting up the framework!

🎮 Spring-style Development Experience

IoC Equivalent: Module auto-wiring, say goodbye to manual dependency fiddling
AOP Equivalent: Middleware interceptors implement aspect-oriented programming
Configuration Center: Supports local files / nacos remote configuration
DevOps Full Stack: Dockerfile + k8s YAML one-click generation

⚡ Implementing Business Code is Like Doing Fill-in-the-Blanks

// Auto-generated CRUD code (A whiff of Java flavor)
type UserService struct {
    userDao *dao.UserDao
}

func NewUserService() *UserService {
    return &UserService{
        userDao: dao.NewUserDao(db), // Similar to dependency injection
    }
}

// Writing business logic by hand is like filling in blanks
func (s *UserService) GetUser(id uint) (*model.User, error) {
    return s.userDao.GetById(id)
}

Conclusion

Sponge framework, like a powerful "accelerator", can help you smoothly transition, enjoy the charm of the Go language, while maintaining efficient development productivity and happiness. Use Sponge to make up for engineering shortcomings, Spring Boot/Cloud old drivers can still speed on the Go track!

Get into action! What are you waiting for? Quickly follow the official documentation and build a demo in 1 minute

sponge github address: https://github.com/go-dev-frame/sponge
sponge development documentation: https://go-sponge.com/zh/

Sponge vs Spring: A Comprehensive Comparison and Selection Guide

gvison — Wed, 19 Feb 2025 07:50:35 +0000

Framework Comparison and Selection Guide

In today's fast-evolving technological landscape, choosing the right development framework is crucial for the success of a project. This article provides a detailed comparison of two popular frameworks—Sponge and Spring—to help developers make an informed choice based on project requirements.

Framework Feature Comparison

Feature	Sponge	Spring
Programming Language	Go (Golang)	Java
Design Paradigm	Low-code, Code Generation, Modularization	IoC (Inversion of Control), DI (Dependency Injection), AOP (Aspect-Oriented Programming)
Performance	High performance, fast execution speed, excellent concurrency	Mature performance, requires JVM tuning, potentially long startup time
Maturity & Stability	Relatively new, rapidly evolving	Highly mature, industry standard, high stability
Applicable Scenarios	RESTFul API, Backend Services, Microservices, Rapid Development	Enterprise applications, Web applications, Microservices, Backend systems, Broad applicability
Learning Curve	Relatively low, low-code reduces development barriers	Steep learning curve, vast and complex ecosystem
Core Features	Code generation (SQL, Protobuf, JSON, Custom Templates), Gin, gRPC, ORM, API Documentation, CRUD, Modularization	IoC container, DI, AOP, Spring MVC, Data Access, Transaction Management, Web Services, JDBC Abstraction, Testing Framework, Modularization
Web Framework	Gin	Spring MVC, Spring WebFlux (Reactive)
Microservices Support	Natively designed for microservices, supports multiple microservice architectures	Excellent microservices support through Spring Boot and Spring Cloud
Code Generation Capability	Core feature, powerful, highly automated	Relatively weak, Spring Initializr provides project initialization and limited scaffolding
Database Support	MySQL, MongoDB, PostgreSQL, SQLite	Extensive database support via Spring Data and JDBC
Service Governance	Service registration & discovery (Consul, Etcd, Nacos), Load balancing, Circuit breaker, Rate limiting, Tracing, Monitoring, Configuration Center	Spring Cloud suite (e.g., Eureka, Consul, Nacos, Ribbon, Hystrix, Gateway, Sleuth, Zipkin), Service registration & discovery, Load balancing, Circuit breaker, Rate limiting, API Gateway, Tracing, Configuration Center, Monitoring
Community	Relatively small but growing	Large and highly active, with extensive resources and support
Toolchain	UI tools, Command-line tools	Spring Boot, Spring Initializr, Maven, Gradle, IDE support
Documentation	Comprehensive official documentation (https://go-sponge.com/)	Extensive documentation, tutorials, books, online resources, official site (https://spring.io/)

Summary & Selection Recommendations

Spring is a mature and comprehensive Java enterprise application framework with a vast community and ecosystem. It is centered around IoC, DI, and AOP, offering numerous modules and functionalities needed to build complex applications. Spring is suitable for large-scale enterprise applications, particularly those requiring high scalability, reliability, and security. However, Spring has a steep learning curve, involves complex configurations, and has relatively long startup times.

Sponge is an emerging Go development framework focused on improving development efficiency and lowering entry barriers. It emphasizes code generation and integrates common components such as the Gin web framework, gRPC RPC framework, and microservice capabilities. It also provides a user-friendly UI interface and comprehensive documentation. Sponge is ideal for rapidly developing high-performance web services, API endpoints, and microservices, especially when quick delivery and low-code development are priorities. The learning curve for Sponge is relatively low, but its community and ecosystem are not as mature as Spring's.

How to Choose:

Choose Spring if:
- You need to build large, complex, enterprise-grade Java applications.
- Your team has extensive experience with Java and Spring.
- You require high maturity, stability, and strong community support.
- Application performance bottlenecks are primarily in business logic or database layers rather than the framework itself.
Choose Sponge if:
- You need to rapidly develop high-performance Go web services, RESTFul APIs, or microservices.
- You prioritize development efficiency and low-code development.
- Your team has solid Go development experience or wants to explore a new Go framework.
- Fast startup time and low resource consumption are critical.
- Suitable for small to large backend services with rapid iteration and scalability needs.

With this comparison and selection guide, developers can choose the most suitable framework based on their project requirements and team technology stack, ensuring successful and efficient development.

DEV Community: gvison

Go in Action: Building a Production-Grade Dynamic Reverse Proxy on Top of Gin

Foreword

Why Implement Reverse Proxy in Code?

Quick Start: Build Your Gateway

1. Basic Code Implementation

2. Advanced Configuration: More Than Just Forwarding

Killer Feature: Runtime Dynamic Management

Scenario 1: Service Scaling

Scenario 2: Node Offline / Canary Release

Scenario 3: Monitoring Dashboard

Summary and Suggestions

No More Complex Scripts! PerfTest Distributed Load Testing Uses a Single YAML to Orchestrate Massive Cluster Tests Gracefully

Preface

Why Choose Distributed Cluster Stress Testing?

Architecture Design: Collector and Agent

How It Works: From Registration to Aggregation

Quick Start: A Simple Cluster Example

Step 1. Start the Collector

Step 2. Start the Agents

Automated Deployment in Kubernetes Scenarios

Horizontal Comparison: The "Players" in Distributed Stress Testing

Conclusion: From Single-Point to Cluster, Simple but Not Simplistic

PerfTest: The "Swiss Army Knife" of Load Testing Tools, Natively Supporting HTTP/1/2/3 and WebSocket with Real-Time Monitoring

Preface

What is PerfTest?

When should you use PerfTest?

Getting Started

HTTP Load Testing Example

Simulating a WebSocket Message Storm

PerfTest vs. ab, wrk, k6

Deep Dive

Conclusion

Sponge: A Framework That Reshapes the Go Development Experience and Supercharges Your Projects

Preface

Enter the Modern Framework

Sponge: Making Go Development as Natural as Breathing

One-Click Code Generation: CRUD Is Nothing

Microservices? Piece of Cake!

Built-In AI Assistant: Turbocharging Your Coding

Don’t Hesitate—Embrace the Change!

Master Go Distributed Tasks in 3 Steps! The Asynq Library Makes Async Jobs Simpler Than Ever

How Many Pitfalls of Go Background Tasks Have You Encountered?

What is sasynq? And Why Can It Save You?

How Easy is sasynq to Use? Let's See the Code!

① Defining a Task

② Enqueuing Tasks: The Ultimate Simplicity

③ Consuming Tasks: Register a Handler in One Line, and You're Done!

Canceling a Task

Summary: Why Choose sasynq?

Comparative Analysis of Go Frameworks: Kratos, Go-Zero, GoFrame, and Sponge

The Arena Showdown: Which One is Your Cup of Tea?

Framework Comparison

1. Learning Curve & Ease of Use: Who is More Approachable?

2. Microservice Support: Who is More Practical?

3. The Love-Hate Relationship with ORM: Built-in or Choose Your Own?

4. Code Generation: Who is the Real "Lazy Person's Gospel"?

Who Should Your Project Choose?

In Conclusion

Is Real-Time Pushing in Go Too Hard? Try Sponge SSE and Get It Done in One Click!

What is SSE? How is it different from WebSocket?

What features does this Go library offer?

Get Started in Three Minutes: Build Your First SSE Service

1. Server-side Code (server.go)

2. Client-side Code (client.go)

Advanced Usage: Make Your SSE Service More Powerful

Scenario 1: I don't want to lose a single message!

Scenario 2: I want to know if a message was successfully delivered.

Summary

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

The Pains We've All Endured

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

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

Discovering Sponge: My "Game-Changer" Moment!

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

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

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

Conclusion: Why I'm Raving About Sponge

From Node.js to Go: How to Smoothly Transition from NestJS and Fall in Love with the Sponge Framework

Introduction

What is `sasynq`? And Why Can It Save You?

How Easy is `sasynq` to Use? Let's See the Code!

Summary: Why Choose `sasynq`?

1. Server-side Code (`server.go`)

2. Client-side Code (`client.go`)