Air
An ideally refined web framework for Go.
High-performance? Fastest? Almost all web frameworks are using these words to
tell people that they are the best. Maybe they are, maybe not. Air does not
intend to follow the crowd. Our goal is always to strive to make it easy for
people to use Air to build their web applications. So, we can only guarantee you
one thing: Air can serve properly.
Features
- API
- As less as possible
- As clean as possible
- As simple as possible
- As expressive as possible
- Server
- HTTP/2 (including h2c) support
- SSL/TLS support
- ACME support
- PROXY (only version 1) support
- Graceful shutdown support
- Router
- Based on the Radix Tree
- Zero dynamic memory allocation
- Blazing fast
- Has a good inspection mechanism
- Group routes support
- Gas (aka middleware)
- Router level:
- Before router
- After router
- Route level
- Group level
- Router level:
- WebSocket
- Full-duplex communication
- Reverse proxy
- Retrieves resources on behalf of a client from another server
- Supported protocols:
- HTTP(S)
- WebSocket
- gRPC (including gRPC-Web)
- Binder
- Binds HTTP request body into the provided struct
- Supported MIME types:
application/jsonapplication/xmlapplication/protobufapplication/msgpackapplication/tomlapplication/yamlapplication/x-www-form-urlencodedmultipart/form-data
- Minifier
- Minifies HTTP response on the fly
- Supported MIME types:
text/htmltext/cssapplication/javascriptapplication/jsonapplication/xmlimage/svg+xml
- Gzip
- Compresses HTTP response by using the gzip
- Default MIME types:
text/plaintext/htmltext/cssapplication/javascriptapplication/jsonapplication/xmlapplication/tomlapplication/yamlimage/svg+xml
- Renderer
- Rich template functions
- Hot update support
- Coffer
- Accesses binary asset files by using the runtime memory
- Significantly improves the performance of the
air.Response.WriteFile - Asset file minimization and gzip support
- Default asset file extensions:
.html.css.js.json.xml.toml.yaml.yml.svg.jpg.jpeg.png.gif
- Hot update support
- I18n
- Adapt to the request's favorite conventions
- Implanted into the
air.Response.Render - Hot update support
- Error
- Centralized handling
Installation
Open your terminal and execute
$ go get github.com/aofei/air
done.
The only requirement is the Go, at least v1.12.
Hello, 世界
Create a file named hello.go
package main
import "github.com/aofei/air"
func main() {
air.Default.GET("/", func(req *air.Request, res *air.Response) error {
return res.WriteString("Hello, 世界")
})
air.Default.Serve()
}
and run it
$ go run hello.go
then visit http://localhost:8080.
Documentation
Does all web frameworks need to have a complicated (or a lovely but lengthy)
website to guide people how to use them? Well, Air has only one
GoDoc with useful comments. In fact,
Air is so succinct that you don't need to understand how to use it through a
large document.
Gases
As we all know that the air of Earth is a mixture of gases. So the same is that
Air adopts the gas as its composition. Everyone can create new gas and use it
within Air simply.
A gas is a function chained in the HTTP request-response cycle with access to
the air.Request and the
air.Response which it uses
to perform a specific action, for example, logging every request or recovering
from panics.
return func(next air.Handler) air.Handler {
return func(req *air.Request, res *air.Response) error {
// Do something here...
return next(req, res) // Execute the next handler
}
}
If you already have some good HTTP middleware, you can simply wrap them into
gases by calling the
air.WrapHTTPMiddleware.
If you are looking for some useful gases, simply visit
here.
Examples
If you want to be familiar with Air as soon as possible, simply visit
here.
FAQ
Why named Air?
"A" for "An", "I" for "Ideally" and "R" for "Refined". So, Air.
Why based on the net/http?
In fact, I've tried to implement a full-featured HTTP server (just like the
awesome valyala/fasthttp). But when I
finished about half of the work, I suddenly realized: What about stability? What
about those awesome middleware outside? And, seriously, what am I doing?
Why not just use the net/http?
Yeah, we can of course use the net/http directly,
after all, it can meet many requirements. But, ummm... it's really too stable,
isn't it? I mean, to ensure Go's backward compatibility (which is extremely
necessary), we can't easily add some handy features to the
net/http. And, the
http.Request does not only represents
the request received by the server, but also represents the request made by the
client. In some cases it can be confusing. So why not just use the
net/http as the underlying server, and then
implement a refined web framework that are only used for the server-side on top
of it?
Do you know we already got the gin-gonic/gin and the labstack/echo?
Of course, I knew it when I started Go. And, I love both of them! But, why not
try some new flavors? Are you sure you prefer them instead of Air? Don't even
give Air a try? Wow... well, maybe Air is not for you. After all, it's for
people who love to try new things. Relax and continue to maintain the status
quo, you will be fine.
What about the fantastic Gorilla web toolkit?
Just call the
air.WrapHTTPHandler
and the
air.WrapHTTPMiddleware.
Is Air good enough?
Far from enough. But it's already working.
Community
If you want to discuss Air, or ask questions about it, simply post questions or
ideas here.
Contributing
If you want to help build Air, simply follow
this to send pull requests
here.
License
This project is licensed under the Unlicense.
License can be found here.