# Tigo: a Go web framework with a Tornado-shaped API

> Two thousand stars for a framework whose selling point is that you write one struct per route, embed a base handler, and define Get, Post or Delete methods on it.

**karldoenitz/Tigo** — Tigo is an HTTP web framework written in Go (Golang). It features a Tornado-like API with better performance.

- Repository: https://github.com/karldoenitz/Tigo
- Website: https://karldoenitz.github.io/Tigo/
- Stars: 2,202 · Forks: 121
- Language: Go
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/karldoenitz-tigo

## One struct per route, one method per verb

The README's description is explicit that Tigo offers a Tornado-like API with better performance claims, and the repository description repeats it in both English and Chinese.

The model is class-based routing. You define a struct that embeds `web.BaseHandler`, then write `Get`, and later `Post` or `Delete` as methods on it. A `web.Pattern` ties the path, the handler struct and a list of middleware together, and a slice of those patterns goes into the `web.Application` literal along with an IP address and a port. Then you call `Run`.

That is the whole example. There is no router variable to configure, no registration call per route, and no map of method names to functions. Verb handling falls out of Go's method sets, which is either exactly the abstraction you want or an unusual one, depending on your background.

The middleware list on each pattern is per-route rather than global, and a middleware is a plain function returning a bool. Returning true continues, false short-circuits and skips later middleware, which is a coarse but readable contract.

## tiger for scaffolding, tission for sessions

Two companion tools are named in the README, and they are not bundled into the same module.

`tiger` is a scaffolding tool built specifically for Tigo. It lives inside the repository at `external_tools/tiger` and is installed as a Go tool:

```shell
go install github.com/karldoenitz/Tigo/external_tools/tiger@latest
```

From there, creating a project is one command:

```shell
tiger create aowuProject
```

`tission` is a session plugin, maintained in its own repository under the same author's account. That split is worth noting: sessions were not built into the core, so anything needing them adds a dependency on a separate project.

Upgrading to a specific version is a standard Go modules operation, with the framework reference given as the module path and the version as a suffix, so there is no bespoke upgrade tool to learn.

## Build, run, and a port number that disagrees with itself

The README's build and run instructions are minimal:

```shell
go build main.go
```

```shell
./main
```

That produces a binary you run directly, or you can run it from the command line as a service.

The sample console output in the README is where the documentation gets sloppy. The application literal in the example sets the port to 8888, but the sample log line reads `Server run on: http://127.0.0.1:8080`, and the very next sentence tells you to visit port 8888. One of those is wrong and the README does not say which.

It is a small thing, and it is the kind of small thing that tells you where the documentation effort has gone. The Chinese and English READMEs are both present in the tree, and full documentation lives in a separate `documentation/documentation.md` file rather than in godoc comments, so the conceptual reference lives outside the source.

## Package layout tells you what is included

The repository is small and flat enough to read in an afternoon. `web/` holds the core: the application type, the base handler, patterns and middleware. `request/` is request handling and context. `binding/` is parameter binding, which is the feature that most often justifies a framework over the standard library. `logger/` is logging, which the 2026 release notes show being reworked. `external_tools/` contains tiger. `test_case/` holds tests. `documentation/` holds the docs and the performance chart image.

The tree is short enough that there is no `cmd/`, no `internal/` and no sprawling package list. That is a positive signal for comprehensibility and a neutral one for whether it will scale.

Build and quality signals are present: a GitHub Actions workflow badge for Go, a Go Report Card badge, a GoDoc badge, a CodeTriage badge, and a Gitter chat link.

## Release history and adoption claims

Three releases are published, and the middle gap is the interesting part. v2.0.0 came on 2023-12-31, v2.0.1 on 2024-12-08, and v2.0.2 on 2026-01-11. That is roughly a year between minor point releases.

The release notes are mostly pull request titles, largely from the maintainer, and a lot of them are housekeeping: standardizing encoding, removing comments that did not meet documentation standards, fixing the install command in the readme, reformatting code blocks. v2.0.2 stands out for splitting the logging code and then rolling back to rework the logging architecture, and for adding logrus support to the tiger tool.

The README lists organizations using Tigo: Cube Backup, Tencent and Xiaomi, plus JetBrains as a supporting organization. Those are logos without case studies, so treat them as claims rather than references.

Open issues number one, forks 121, and the repository was last pushed to on 2026-06-05. The MIT license is declared both in the repository metadata and as a badge in the README.

## Conclusion

Tigo's handler model is the part worth remembering: a route binds a URL to a struct, and the HTTP verb becomes a method on that struct, which means the compiler enforces your routing surface instead of a string table. The `tiger` scaffolding tool and the separate session plugin fill the gaps a framework needs but did not build in. What you give up by choosing it is the ecosystem: Go's standard library already does routing in a line, and most Go teams reach for a framework only when they want middleware chaining and request binding, which Tigo provides but in a shape of its own. If you are coming from Tornado or from a struct-based framework in another language, the demo in the README is short enough to read in full and will tell you within a minute whether the model fits.

## FAQ

### What is Tigo and what language is it written in?

Tigo is an HTTP web framework written in Go. Its API is modeled on Tornado, with a class-based routing style, and the project claims better performance than that reference point. Both an English and a Chinese README are maintained.

### How do I create a new Tigo project?

Install the tiger scaffolding tool with `go install github.com/karldoenitz/Tigo/external_tools/tiger@latest`, then run `tiger create` followed by a project name. tiger lives in the framework repository under external_tools/tiger rather than being part of the core module.

### How does Tigo handle HTTP methods and middleware?

Each route binds a URL pattern to a struct, and the HTTP verb is a method on that struct, so a Get method handles GET and a Post method would handle POST. Middleware is attached per pattern as a slice of functions that take a ResponseWriter and Request and return a bool, where true continues and false short-circuits.

### Does Tigo have session support built in?

Not in the core framework. The README points to a separate project called tission, a session plugin built for Tigo and maintained in its own repository. That means session support is an additional dependency rather than part of the framework.

## Sources

- [karldoenitz/Tigo on GitHub](https://github.com/karldoenitz/Tigo)
- [License: MIT](https://github.com/karldoenitz/Tigo/blob/master/LICENSE)
- [Project website](https://karldoenitz.github.io/Tigo/)
- [README](https://github.com/karldoenitz/Tigo/blob/master/README.md)
- [Releases](https://github.com/karldoenitz/Tigo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/karldoenitz-tigo