Goyave: an opinionated Go REST framework that tells you what it will not do

The non-goals list is the most useful thing in the README

Most framework READMEs describe what a thing does. Goyave also states what it will not do, and the list is short enough to be a genuine filter:

- Hyper-optimisation and performance - Small projects and prototypes - Providing control on low-level networking - Providing tools for front-end development

Read that as a positioning decision rather than a caveat. Goyave is aimed at companies with enterprise-level clean architecture for medium to large projects, and the framework's stated goals include helping developers focus on business logic instead of technical aspects, providing an all-in-one package with no setup friction, and staying open and hackable despite being opinionated.

The pairing of those two ideas is the framework's actual thesis. Opinionated means the routing, validation and error conventions are decided for you; open and hackable means you can reach past them. If you need a framework that optimizes for the last request per second, or that stays out of your way on a four-hour project, this one tells you in advance that it is not that.

Feature coverage is broad and deliberately unopinionated about databases

The features list runs long: Routing, Controllers, Middleware, request parsing, advanced validation, business transactions, authentication, configuration, testing utilities, database support and ORM, localization, advanced error handling, structured logging, CORS, support for file systems, Websockets, dynamic filtering and pagination using query parameters, DTO conversion and model mapping.

Most of those are self-explanatory. Three deserve a note because they are the ones teams most often build badly themselves.

Business transactions mean the framework wraps request handling in a database transaction rather than leaving transaction boundaries to each handler, which is what makes a validation failure roll back cleanly. Advanced validation is a named feature rather than a library you bolt on, and the contributors list shows the surface is actively extended, with names attached to `DoesntStartWithValidator`, `DoesntEndWithValidator` and `KeysInValidator`.

The database story is where GORM does the work. go.mod lists drivers for BigQuery, ClickHouse, MySQL, Postgres, SQLite and SQL Server, all through gorm.io/gorm. SQLite as a first-class driver alongside the distributed databases is the tell that local development and testing are a design goal, not an afterthought.

Go 1.26 and a v5 module path

The module is `goyave.dev/goyave/v5` and go.mod declares go 1.26.0. Both facts matter for adoption.

The v5 suffix in the module path means the major version is part of the import path, so upgrading across a major version is an import rewrite rather than a dependency bump. For an API framework that teams tend to run for years, that is a migration with real cost, and the point at which to plan is when you pick it, not when v6 arrives.

The Go requirement is at the current edge. A project pinned to an older toolchain cannot take this framework, and there is no indication in the README of support for earlier versions.

Development is active. The last push was on 2026-10-16, and releases v5.12.5 on 2026-09-28, v5.12.4 on 2026-09-08 and v5.12.3 on 2026-09-04 show a patch cadence inside a single minor line.

The top-level file list explains the architecture

The repository root is a map of the framework's own design. Request handling centers on `request.go`, `response.go`, `route.go`, `router.go`, `server.go`, `middleware.go` and `component.go`, with matching `_test.go` files beside each, which tells you every one of these is a first-class unit with its own tests rather than a helper buried in a package.

`service.go` is the notable one. A service layer alongside the router is the clean-architecture shape the goals section refers to, and the fact that it is a top-level concept rather than something you assemble is what separates this framework from a router plus middleware.

Then there are directories that map to the feature list: `auth/`, `config/`, `cors/`, `database/`, `lang/` for localization, `log/`, `middleware/`, `validation/`, `websocket/` and `slog/`. The presence of a dedicated `slog/` directory next to `log/` is the Go 1.21+ structured logging standard getting first-class treatment rather than an adapter bolted on later.

There is also `static.go` and a `resources/` directory. Utility code sits in `util/`, while `parameterizable.go` suggests a shared parameter mechanism.

Linting is configured through `.golangci.yml`, and there is a `router_bench_test.go`, which matters given performance is an explicit non-goal: the project still benchmarks its own routing.

Documentation, examples and the productivity CLI

The README defers essentially all usage detail to goyave.dev, which it calls clear and extensive documentation where developers can always find the answer to their questions. That is a claim about the docs rather than a fact about the framework, and it is worth verifying for your specific question before adopting.

An example project is available at go-goyave/goyave-blog-example.

Two companion tools appear in the contributor list. The `gyv` CLI from go-goyave/gyv is a productivity tool, contributed by Louis Laurent. The `filter` package at goyave.dev/filter provides the `search` feature behind dynamic filtering and pagination, contributed by Clement3.

Both matter for the adoption decision because they show Goyave's ecosystem is modular rather than monolithic: some functionality lives outside the core module, which is consistent with the stated goal of no bloat but does mean the core repository is not the whole picture.

Where Goyave is the wrong choice

The framework disqualifies itself for whole categories, and taking that at face value saves time.

Performance is the first. Hyper-optimisation and performance is the first non-goal. If your workload is bound by request latency at high concurrency, or you are comparing against a hand-tuned net/http service, you are outside what this project optimizes for. The presence of benchmarks in the repository is about the router, not about competing with a tuned stack.

Project scale is the second. Small projects and prototypes are an explicit non-goal, which is unusual and useful to state plainly. The framework's convention overhead pays for itself across a codebase with many endpoints, several developers and real architectural boundaries. On a service with six handlers, the conventions are overhead with no offsetting benefit.

Networking control is the third. No control on low-level networking means no custom protocols, no unusual timeouts you need to control precisely, no custom transport behaviors. If you need those, you are fighting the framework rather than using it.

Front-end is the fourth, and self-explanatory: there are no front-end tools here.

The dependency weight is worth noting too. go.mod pulls in GORM plus six database drivers, cloud.google.com/go and the BigQuery client as indirect dependencies, ClickHouse's Go client, Apache Arrow, JWT handling, gorilla/websocket, klauspost/compress for brotli, and a separate copier library. That is a substantial module graph for a service talking to one Postgres database.

Against Gin, Echo and Chi

The selection rule is simple. A team that wants fewer decisions and has a codebase large enough to benefit from them should consider Goyave. A team that wants to own every layer, or that is optimizing request latency, should not. Nobody should pick Goyave for a prototype, since the framework says so itself.

Editorial conclusion

Goyave fits a team building a REST API in Go for a medium to large project with clean architecture ambitions and a preference for a framework that decides things for you, and that will read the documentation on goyave.dev rather than the README. It does not fit a latency-critical service, a weekend prototype, or anyone who needs to control low-level networking. Before adopting, read the framework's own non-goals list and check it against your project, confirm the module path is goyave.dev/goyave/v5 with a go 1.26.0 requirement, and pick only the ORM drivers your database actually needs so the BigQuery, ClickHouse, MySQL, Postgres, SQLite and SQL Server dependencies do not all land in your build.

Frequently asked questions

Official sources

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