go-doudou generates your OpenAPI and gRPC code from Go interfaces

Interfaces in, OpenAPI and Protobuf out

go-doudou, which the readme says is pronounced with doudou sounding like /dəudəu/, is an OpenAPI 3.0 spec and Protobuf v3 based lightweight microservice framework, and it supports monolith service applications as well.

The design decision is the first bullet in the feature list: it starts from the Golang interface, with no need to learn a new IDL, an interface definition language. You write a Go interface for your service, and the framework derives the rest.

That is a deliberate inversion of the usual order. Most API toolchains start from a specification file, a protobuf definition or an OpenAPI document, and generate server stubs from it, which means the spec is a separate artefact that has to be kept in step with the code by hand or by a linting step. go-doudou starts from the Go type that already exists and generates the specification from it, so the specification cannot drift, because it is derived.

The two outputs are OpenAPI 3.0 for REST and Protobuf v3 for gRPC, and the choice of transport is not something you have to commit to before you write the service. The README also mentions an ORM in the repository topics, and the dependencies in the module file include GORM, sqlx and the MySQL driver, so the data layer is part of the framework rather than something you bolt on.

The audience is a Go team that has decided to expose services over HTTP or gRPC and wants the plumbing generated rather than written. The documentation lives at go-doudou.github.io/guide, and the project is maintained under the unionj-cloud organisation with an MIT licence.

The code generator is the product

The second feature bullet is the one that decides whether you use this framework. There is a powerful code generator CLI built in, and after defining your interface methods your only job is implementing your awesome idea.

That phrasing is casual, but it describes the workflow accurately. The generator takes the interface definitions and produces the parts that would otherwise be repetitive: the transport handlers, the request and response plumbing, the specification document, and the client side pieces. What remains is the handler body, which is the part you actually wrote the framework to write.

The repository layout backs this up. There is a cmd directory for the command line entry points, a framework directory for the runtime, a version directory, and an app.yml.example at the root, which suggests the generator and the runtime are configured from a file rather than from code. The command line itself is built with cobra, so the familiar subcommand conventions apply, and the dependency list shows the generator is a real program with a configuration format rather than a template script.

The appeal is clearest if you have written this code before. In a typical Go service, the handler, the router entry, the request struct with its tags, the response struct, the swagger comment block and the matching client method are all maintained by hand, and the swagger comment is the one that gets forgotten, which is why the published API drifts from the real one. Generating it removes that failure mode, and it is the reason to look at this project even if you end up not using its runtime.

The cost is the coupling. Once the generated code is part of your build, changing how the generator works is a breaking change across every service that uses it, and the version line in the module file, v2, tells you that the project has already been through that kind of transition.

Service governance is in the box, not in a later sprint

The fourth feature bullet lists the built-in service governance support, and the list is long: remote configuration management, client-side load balancer, rate limiter, circuit breaker, bulkhead, timeout, retry and more.

This is the difference between a code generator and a framework, and it is the part that decides whether go-doudou is useful for a team or only interesting.

Each of those mechanisms is a well understood pattern with a well understood failure mode, and each takes weeks to get right when you write it yourself. The client-side load balancer means a service does not need a service mesh to spread requests. The rate limiter needs a shared store to be meaningful across instances, which is why the credits section says the framework relies on go-redis/redis_rate to implement the Redis based rate limit feature. The circuit breaker, the bulkhead and the timeout are the resilience trio, and the bulkhead in particular is the one that stops a slow dependency from consuming every worker.

Remote configuration is the other half. The credits name the two libraries behind it, apolloconfig/agollo for the Apollo remote configuration management support and nacos-group/nacos-sdk-go for service discovery and remote configuration management for Nacos. So the framework covers the two configuration and discovery systems that Chinese infrastructure teams tend to already run, and it does so by depending on their client libraries rather than by inventing a standard.

The trade is dependency weight. The module file for go-doudou lists GORM and sqlx for data access, resty and gabs for HTTP and JSON, prometheus client_golang for metrics, opentracing with the Jaeger client for tracing, ristretto and go-redis for caching, zookeeper for coordination, sonic as a JSON library, and testcontainers-go for integration tests. That is a large surface, and it is a large surface that you get for free in the sense that you would have written it yourself, and expensive in the sense that every one of those is a version you now depend on.

The same framework for a monolith and for a fleet of services

One of the feature bullets is a sentence that matters more than it looks: supporting both monolith and microservice architectures gives you flexibility to design your system.

The reason to mention it is that the two architectures are usually treated as different products. A monolith gets a web framework, and a microservice gets a service framework with discovery, and the code you write for one does not run in the other. go-doudou claims both, and the mechanism for that claim is visible in the dependencies rather than in the readme. There is a zookeeper client and a Nacos client for discovery, an Apollo client for configuration, and a client-side load balancer so that a service can find its peers without a mesh.

What is not stated, and what you would need to check in the guide, is how the two modes differ in practice. Whether a monolith in this framework is the same code with a different deployment, or the same interface definitions with different wiring, is exactly the kind of detail that decides whether the claim is a convenience or a real capability.

The other piece of positioning is the cloud-native framing. The readme says it was born from the cloud-native era and that the built-in CLI can speed up your product iteration. The repository topics list apollo, etcd, nacos, service-mesh and orm alongside the rest, so the intended neighbourhood is clear: teams running Go services on Kubernetes with a Chinese cloud stack, or teams migrating towards one.

For a team that is simply running a handful of Go services on one machine, none of that machinery is needed, and this framework is a heavy way to get a router.

The benchmark is a latency sweep, and the version is old

The readme has a benchmark section, and the parameters are worth reading because they tell you what kind of measurement this is.

The machine is a MacBook Pro 16 inch from 2019, with a 2.3 GHz eight core Intel Core i9 and 16 GB of 2667 MHz DDR4 memory. The processing times swept are 0 ms, 10 ms, 100 ms and 500 ms, the concurrency is 1000, and the duration is 30 seconds. The version measured is go-doudou v1.3.7, and the test code is in a separate repository, wubin1989/go-web-framework-benchmark.

What that says is that this is a framework comparison under simulated backend latency, with a fixed concurrency and a fixed time window. The four processing times are the interesting axis, because they separate the cost of the framework itself from the cost of waiting for a dependency, and a framework that looks good at 0 ms can look very different at 500 ms.

Two things to keep in mind. The measured version is v1.3.7 while the current release is v2.5.13, so the number describes a generation of the framework that is several minor versions old. And the result itself is an image in the repository, benchmark.png, with the underlying data in a different repository, so if you want to reproduce it you are reproducing someone else's harness.

That is not a criticism of the project, it is a measurement of how much weight the number can carry. Treat it as evidence that the framework was competitive in a latency sweep at some point, and run your own comparison with your own dependencies.

The module file shows what you are actually depending on

The go.mod is worth reading as a bill of materials, because for a framework the dependency list is a large part of the decision.

The module is github.com/unionj-cloud/go-doudou/v2, on Go 1.25.0. The direct dependencies split into layers. The web and API layer brings go-resty for HTTP calls, gabs for JSON manipulation, and the goccy/go-yaml parser. The data layer is GORM alongside sqlx and the MySQL driver, plus the unionj-cloud/toolkit module. The CLI is cobra, with logrus for logging and joho/godotenv for environment loading. Observability is prometheus client_golang for metrics and opentracing with the Jaeger client for tracing. The infrastructure clients are go-redis/redis/v8, dgraph-io/ristretto for caching and go-zookeeper/zk. The testing stack is stretchr/testify and testcontainers-go. And there are two dependencies that stand out: bytedance/sonic, a fast JSON library, and elliotchance/orderedmap.

Two things follow from that list. The first is that this is a framework that expects infrastructure to exist. Redis, a tracing backend, a configuration service and a service registry are all assumed, and a team that wants a small self contained service will trim a lot of it away, at which point they are using the generator rather than the framework.

The second is that the tests are containerised. testcontainers-go means the test suite starts real dependencies rather than mocking them, which is the right call for a framework whose whole job is talking to those dependencies, and also the reason the test suite is slow and needs a Docker daemon.

The repository itself is compact for a framework of this scope, with cmd, framework, version, main.go, an app.yml.example and the two readmes, one in English and one in Chinese, which is a good hint at the audience.

Editorial conclusion

go-doudou is worth adopting if you are writing Go services and want the API description, the client stubs and the transport layer to come out of the same interface definition, because the generator removes a whole category of hand written glue that drifts out of sync with the code. It is the wrong choice if your team is comfortable writing OpenAPI by hand or with a separate tool, since the generator is the main argument, and it is the wrong choice if you want a minimal dependency footprint, because the governance features pull in Redis, an ORM, tracing and a service discovery client. Before you adopt it, read the guide at go-doudou.github.io/guide, and note that the current release is v2.5.13 from 2025-09-05 with the last push on 2026-05-02.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. unionj-cloud/go-doudou on GitHub