Fireball

High-performance web framework for Go, reaches top scores in Lighthouse.

![Aero Go Logo](docs/media/aero.go.png)

[![Godoc][godoc-image]][godoc-url]
[![Report][report-image]][report-url]
[![Tests][tests-image]][tests-url]
[![Coverage][coverage-image]][coverage-url]
[![Sponsor][sponsor-image]][sponsor-url]

Aero is a high-performance web server with a clean API.

## Installation

```shell
go get -u github.com/aerogo/aero/...
```

## Benchmarks

[![Web server performance](docs/media/server-performance.png)](docs/Benchmarks.md)

## Features

- HTTP/2
- Radix tree routing
- Low latency
- Bandwidth savings via automated ETags
- Session data with custom stores
- Server-sent events
- Context interface for custom contexts

## Links

- [API](docs/API.md)
- [Configuration](docs/Configuration.md)
- [Benchmarks](docs/Benchmarks.md)

[godoc-image]: https://godoc.org/github.com/aerogo/aero?status.svg
[godoc-url]: https://godoc.org/github.com/aerogo/aero
[report-image]: https://goreportcard.com/badge/github.com/aerogo/aero
[report-url]: https://goreportcard.com/report/github.com/aerogo/aero
[tests-image]: https://cloud.drone.io/api/badges/aerogo/aero/status.svg
[tests-url]: https://cloud.drone.io/aerogo/aero
[coverage-image]: https://codecov.io/gh/aerogo/aero/graph/badge.svg
[coverage-url]: https://codecov.io/gh/aerogo/aero
[sponsor-image]: https://img.shields.io/badge/github-donate-green.svg
[sponsor-url]: https://github.com/users/akyoto/sponsorship


Aero

Golf is a fast, simple and lightweight micro-web framework for Go. It comes with powerful features and has no dependencies other than the Go Standard Library.

<a href="http://golf.readme.io"><img width=50% src="/golf-logo.png"></img></a>

[![GoDoc](http://img.shields.io/badge/golf-documentation-blue.svg?style=flat-square)](http://golf.readme.io/docs)
[![License](http://img.shields.io/badge/license-mit-blue.svg?style=flat-square)](https://raw.githubusercontent.com/dinever/golf/master/LICENSE) 
[![Build Status](http://img.shields.io/travis/dinever/golf.svg?style=flat-square)](https://travis-ci.org/dinever/golf) 
[![Build Status](https://goreportcard.com/badge/github.com/dinever/golf?style=flat-square)](https://travis-ci.org/dinever/golf) 
[![Coverage Status](http://img.shields.io/coveralls/dinever/golf.svg?style=flat-square)](https://coveralls.io/r/dinever/golf?branch=master)

A fast, simple and lightweight micro-web framework for Go, comes with powerful features and has no dependencies other than the Go Standard Library.

Homepage: [golf.readme.io](https://golf.readme.io/)

## Installation

    go get github.com/dinever/golf

## Features

1. No allocation during routing and parameter retrieve.
1. Dead simple template inheritance with `extends` and `include` helper comes out of box.

    **layout.html**
    
    ```html
    <h1>Hello World</h1>
    {{ template "body" }}
    {{ include "sidebar.html" }}
    ```
    
    **index.html**

    ```jinja2
    {{ extends "layout.html" }}
    
    {{ define "body"}}
    <p>Main content</p>
    {{ end }}
    ```
    
    **sidebar.html**
    
    ```jinja2
    <p>Sidebar content</p>
    ```
1. Built-in XSRF and Session support.
1. Powerful middleware chain.
1. Configuration from JSON file.

## Hello World

```go
package main

import "github.com/dinever/golf"

func mainHandler(ctx *golf.Context) {
  ctx.Send("Hello World!")
}

func pageHandler(ctx *golf.Context) {
  ctx.Send("Page: " + ctx.Param("page"))
}

func main() {
  app := golf.New()
  app.Get("/", mainHandler)
  app.Get("/p/:page/", pageHandler)
  app.Run(":9000")
}
```

The website will be available at http://localhost:9000.

## Benchmark

The following chart shows the benchmark performance of Golf compared with others.

![Golf benchmark](https://cloud.githubusercontent.com/assets/1311594/14748305/fcbdc216-0886-11e6-90a4-231e78acfb60.png)

For more information, please see [BENCHMARKING.md](BENCHMARKING.md)

## Docs

[golf.readme.io/docs](https://golf.readme.io/docs)

## License

[MIT License](/LICENSE)


Golf

REST framework for quickly writing resource based services.

![Image of Yaktocat](http://resoursea.com/img/resoursea-logo-header.png)

## What is Resoursea?

A high productivity web framework for quickly writing resource based services fully implementing the REST architectural style.

This framework allows you to really focus on the Resources and how it behaves, and let the tool for routing the requests and inject the required dependencies.

This framework is written in [Golang](http://golang.org/) and uses the power of its implicit Interface and decentralized package manager.

## Features

- Describes the service API as a Go *struct* structure.
- Method dependencies are constructed and injected when requested.
- Resources becomes accessible simply defining the HTTP methods it is listening to.

## Getting Started

First [install Go](https://golang.org/doc/install) and setting up your [GOPATH](http://golang.org/doc/code.html#GOPATH).

Install the Resoursea package:

~~~
go get github.com/resoursea/api
~~~

To create your service all you have to do is create ordinary Go *structs* and call the `api.newRouter` to route them for you. Then, just call the standard Go server to provide the resources on the network.

## By Example

Save the code below in a file named `main.go`.

~~~ go
package main

import (
	"log"
	"net/http"

	"github.com/resoursea/api"
)

type Gopher struct {
	Message string
}

func (r *Gopher) GET() *Gopher {
	return r
}

func main() {
	router, err := api.NewRouter(Gopher{
		Message: "Hello Gophers!",
	})
	if err != nil {
		log.Fatalln(err)
	}

	// Starting de HTTP server
	log.Println("Starting the service on http://localhost:8080/")
	if err := http.ListenAndServe(":8080", router); err != nil {
		log.Fatalln(err)
	}
}
~~~

Then run your new service:

~~~
go run main.go
~~~

Now you have a new REST service runnig, to **GET** your new `Gopher` Resource, open any browser and type `http://localhost:8080/gopher`.

Another more complete example shows how to build and testing a [simple library service](https://github.com/resoursea/example) with database access, dependency injection and the use of `api.ID`.

## Basis

- Create a hierarchy of ordinary Go *structs* and it will be mapped and routed, each *struct* will turn into a new Resource.

- Define HTTP methods for Resources these methods will be cached and routed.

- Define the dependencies of each method and these dependencies will be constructed and injected whenever necessary.

- You can define the initial state of some Resource and it will be injected in the initializer and constructor methods.

- Resources can define an initializer `Init` method and it will be used to change the initial state of this Resource. It runs just one time when resources are being mapped.

- Resources can define a constructor `New` method, it will be used to construct the Resource every time it needs to be injected. It runs every time one method depends on this resource.

- The URI address of the Resource will be the identifier of the field that receives this Resource.

- The root of the Resource tree isn't attached to any field, so you can pass 2 optional parameters when creating the router: the field identifier and the field tag.

### More Info

* Initial state of Resources are optional, if not defined a new empty instance will be used.

* The initialzer method `Init` is optional, if not declared the initial state will remains the same.

* The constructor method `New` is optional, if not declared the initial state will be injected.

* The first argument of a Go *struct* method is the *struct* itself, it means that for mapped methods the instance of the Resource will be always injected as the first argument.

* One of the constraints for a REST services is to don't keep states in the server component, it means that the Resources shouldn't keep states over the connection. For this rason, every request will receive a new constructed Resource of each dependency.

* Initializers cant have dependencies, and you can return just the resource itself and/or an error.

* Constructors can have dependencies, but **you can't design a circular dependency**, and you can return just the resource itself and/or an error.

* Obs: If you change the state of some dependency somewhere that isn't it's method constructor, when it receives pointer Dependency value for instance, it can cause unexpected behavior.

### The Resource Tree

Resources is declared using ordinary Go *structs* and *slices* of *struts*.

When declaring the service you create a tree of *structs* that will be mapped in routes.

If you declare a list of Resources `type Gophers []Gopher` its behavior will be::

- Requests for the route `/gophers` will be answered by the `Gophers` type.

- Requests for the route `/gophers/:ID` will be answered by the `Gopher` type.

- Methods in `Gopher` could request for `*api.ID`. This dependency keeps the requested ID for this Resource present in the URI.

### Initializer `Init` Method

This method is used to insert/modify the initial value of some method. If you defined the initial state of this resource on the API creation, this state will always be injected as the first argument of this method. This method just can return the resource itself and/or an error. If this method returns an error, this value will be returned by the `api.NewRouter` method.

### Constructor `New` Method

This method is used to construct the value of the Resource before it is injected. The initial value of this method will always be injected as the first argument of this method. This method just can return the resource itself and/or an error. If this method returns an error, this value can be caught by any subsequent method.


### ID Dependency

This dependency is used to identify one Resource in a list. The `api.ID` dependency will be injected in the Resource's methods that it's parent is a slice of the Resource itself.

### Interface Dependency

Interfaces can be used to decouple the service of the Resource's implementation. When an method is requiring an Interface, the framework will search in the Resource tree which Resource satisfies this Interface. It searches in the siblings and uncles until reaches the root of the tree. If no Resource were found to satisfy thi Interface, an error is returned on the mapping time.

So, if some method requires one Interface, you should specify at least one implementation of this interface in the Resource tree. You can add all the interfaces implementation in the root of your service, so it will be easy to change the implementation if it's necessary.

## A More Complete Example

~~~ go
package main

import (
	"log"
	"net/http"

	"github.com/resoursea/api"
)

type Gopher struct {
	ID          int
	Message     string
	Initialized bool
}

func (r *Gopher) Init() *Gopher {
	r.Initialized = true
	return r
}

func (r *Gopher) New(id api.ID) (*Gopher, error) {
	idInt, err := id.Int()
	if err != nil {
		return nil, err
	}
	r.ID = idInt
	return r, nil
}

func (r *Gopher) GET(err error) (*Gopher, error) {
	return r, err
}

type Gophers []Gopher

type API struct {
	Gophers Gophers
}

func main() {
	router, err := api.NewRouter(API{
		Gophers: Gophers{
			Gopher{
				Message:     "Hello Gophers!",
				Initialized: false,
			},
		},
	})
	if err != nil {
		log.Fatalln(err)
	}

	// Starting de HTTP server
	log.Println("Starting the service on http://localhost:8080/")
	if err := http.ListenAndServe(":8080", router); err != nil {
		log.Fatalln(err)
	}
}

~~~

When you run de service above and try to **GET** one specific `Gopher`, accessing `http://localhost:8080/api/gophers/123` in a browser, the server will return:

~~~ javascript
{
	"Gopher": {
		"ID": 123,
		"Message": "Hello Gophers!",
		"Initialized": true,
	}
}
~~~

Here we can see that the declared initial state was injected in the `Gopher` initializer, and this method updates the initial state. The initial state of `Gopher` and the `api.ID`, sent by the URI, was injected in the constructor method. The `GET` method of `Gopher` just listen for an **HTTP GET** action and return the injected values to the client.


### Mapped Methods

In the REST arquitecture HTTP methods should be used explicitly in a way that's consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping:


- GET = Retrieve a representation of a Resource.
- POST = Create a new Resource subordinate of the specified resource collection.
- PUT = Update the specified Resource.
- DELETE = Delete the specified Resource.
- HEAD = Get metadata about the specified Resource.

This thing scans and route all Resource's methods that has some of those prefix. Methods also can be used to create the Actions some Resource can perform, you can declare it this way: `POSTLike()`. It will be mapped to the route `[POST] /resource/like`. If you declare just `POST()`, it will be mapped to the route `[POST] /resource`.


### Dependency Injection

When this framework is creating the Routes for mapped methods, it creates a tree with the dependencies of each method and ensures that there is no circular dependency. This tree is used to answer the request using a depth-first pos-order scanning to construct the dependencies, which ensures that every dependency will be present in the context before it is was requested.

When injecting the required dependency, first the framework search for the initial value of the Resource in the Resource tree, if it wasn't declared, it creates a new empty value for the `struct`. If this dependency has a creator method (New), it is called using this value, and its returned values is injected on the subsequent dependencies until arrive to the root of the dependency tree, the mapped HTTP method itself.

If the method is requesting for an Interface, the framework need find in the Resource tree which one implements it, the framework will search in the siblings, parents or uncles. The same search is done when requiring Structs too, but it is not necessary to be in the Resource tree, if it is not present just a new empty value is used. All this process is done in the route creation time, it guarantee that everything is cached before start to receive the client requests.


### Resoursea Ecosystem

You also has a high software reuse through the sharing of Resources already created by the community. It’s the resource sea!

Think about a Resource used by virtually all web services, like an instance of the database. Most web services require this Resource to process the request. This Resource and its behavior not need to be implemented by all the developers. It is much better if everyone uses and contribute with just one package that contains this Resource. Thus we’ll have stable and secure packages with Resources to suit most of the needs. Allowing the exclusive focus on particular business rule, of your service.

In Go the explicit declaration of implementation of an Interface is not required, which provide a decoupling of the Interface with the struct which satisfies this interface. This added to the fact tat Go provides a decentralized package manager provides the ideal environment for the sustainable growth of an ecosystem with interfaces and features that can be reused.

Think of a scenario with a list of interfaces, each with a list of Resources that implements it. His work as a developer of services is choosing the interfaces and Resources to attend the requirements of the service and implements only the specific features of your nincho.

### Router Printer

A [printer package](https://github.com/resoursea/printer) was created just for debug reasons. If you want to see the tree of mapped routes and methods, you can import the `https://github.com/resoursea/printer` package and use the `printer.Router` method, passing the *Router* interface returned by a `api.newRouter` call.

## Larn More

[The concept, Samples, Documentation, Interfaces and Resources to use...](http://resoursea.com)

## Join The Community

* [Google Groups](https://groups.google.com/d/forum/resoursea) via [resoursea@googlegroups.com](mailto:resoursea@googlegroups.com)
* [GitHub Issues](https://github.com/resoursea/api/issues)
* [Leave us a comment](https://docs.google.com/forms/d/1GCKn7yN4UYsS4Pv7p2cwHPRfdrURbvB0ajQbaTJrtig/viewform)
* [Twitter](https://twitter.com/resoursea)


Resoursea

Framework to build REST/GraphQL API on top of databases with mostly configuration over code.

REST Layer

Fast micro-framework designed to build REST APIs and web services in a fast and simple way.

[![GoDoc](https://godoc.org/github.com/yarf-framework/yarf?status.svg)](https://godoc.org/github.com/yarf-framework/yarf)
[![Version](https://badge.fury.io/gh/yarf-framework%2Fyarf.svg)](https://badge.fury.io/gh/yarf-framework%2Fyarf)
[![Build Status](https://travis-ci.org/yarf-framework/yarf.svg?branch=master)](https://travis-ci.org/yarf-framework/yarf)
[![Coverage Status](https://coveralls.io/repos/github/yarf-framework/yarf/badge.svg?branch=master)](https://coveralls.io/github/yarf-framework/yarf?branch=master)
[![Go Report Card](https://goreportcard.com/badge/github.com/yarf-framework/yarf)](https://goreportcard.com/report/github.com/yarf-framework/yarf)
[![Join the chat at https://gitter.im/jinzhu/gorm](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/yarf-framework/yarf) 


# YARF: Yet Another REST Framework

YARF is a fast micro-framework designed to build REST APIs and web services in a fast and simple way. 
Designed after Go's composition features, takes a new approach to write simple and DRY code.


## Getting started

Here's a transcription from our examples/simple package. 
This is a very simple Hello World web application example. 


```go
package main

import (
    "github.com/yarf-framework/yarf"
)

// Define a simple resource
type Hello struct {
    yarf.Resource
}

// Implement the GET method
func (h *Hello) Get(c *yarf.Context) error {
    c.Render("Hello world!")
    
    return nil
}

// Run app server on http://localhost:8080
func main() {
    y := yarf.New()
    
    y.Add("/", new(Hello))
    
    y.Start(":8080")
}

```

For more code and examples demonstrating all YARF features, please refer to the 'examples' directory.



## Features


### Struct composition based design

YARF resources are custom structs that act as handlers for HTTP methods. 
Each resource can implement one, several or all HTTP methods needed (GET, POST, DELETE, etc.).
Resources are created using Go's struct composition and you only have to declare the yarf.Resource type into your own struct.

Example: 

```go

import "github.com/yarf-framework/yarf"

// Define a simple resource
type Hello struct {
    yarf.Resource
}

// Implement the GET method
func (h *Hello) Get(c *yarf.Context) error {
    c.Render("Hello world!")
    
    return nil
}

```


### Simple router

Using a strict match model, it matches exact URLs against resources for increased performance and clarity during routing. 
The routes supports parameters in the form '/:param'.

The route: 

```go
/hello/:name
```

Will match: 

```
/hello/Joe
/hello/nobody
/hello/somebody/
/hello/:name
/hello/etc
```

But it won't match: 

```
/
/hello
/hello/Joe/AndMark
/Joe/:name
/any/thing
```

You can define optional parameters using multiple routes on the same Resource.


### Route parameters

At this point you know how to define parameters in your routes using the /:param naming convention. 
Now you'll see how easy is to get these parameters by their name from your resources using the Context.Param() method. 

Example: 

For the route: 

```
/hello/:name
```

You can have this resource:

```go
import "github.com/yarf-framework/yarf"

type Hello struct {
    yarf.Resource
}

func (h *Hello) Get(c *yarf.Context) error {
    name := c.Param("name")

    c.Render("Hello, " + name)

    return nil
}

```


### Route wildcards

When some extra freedom is needed on your routes, you can use a `*` as part of your routes to match anything where the wildcard is present. 

The route: 

```
/something/*/here
```

Will match the routes

```
/something/is/here
/something/happen/here
/something/isnt/here
/something/was/here
```

And so on... 

You can also combine this with parameters inside the routes for extra complexity.


### Catch-All wildcard

When using the `*` at the end of any route, the router will match everything from the wildcard and forward. 

The route: 

```
/match/from/here/*
```

Will match: 

```
/match/from/here
/match/from/here/please
/match/from/here/and/forward
/match/from/here/and/forward/for/ever/and/ever
```

And so on...


#### Note about the wildcard

The `*` can only be used by itself and it doesn't works for single character matching like in regex. 

So the route:
 
```
/match/some*
```

Will **NOT** match:

```
/match/some
/match/something
/match/someone
/match/some/please
```


### Context

The Context object is passed as a parameter to all Resource methods and contains all the information related to the ongoing request. 

Check the Context docs for a reference of the object: [https://godoc.org/github.com/yarf-framework/yarf#Context](https://godoc.org/github.com/yarf-framework/yarf#Context)



### Middleware support

Middleware support is implemented in a similar way as Resources, by using composition.  
Routes will be pre-filtered and post-filtered by Middleware handlers when they're inserted in the router.

Example: 

```go
import "github.com/yarf-framework/yarf"

// Define your middleware and composite yarf.Middleware
type HelloMiddleware struct {
    yarf.Middleware
}

// Implement only the PreDispatch method, PostDispatch not needed.
func (m *HelloMiddleware) PreDispatch(c *yarf.Context) error {
    c.Render("Hello from middleware! \n") // Render to response.

    return nil
}

// Insert your middlewares to the server
func main() {
    y := yarf.New()

    // Add middleware
    y.Insert(new(HelloMiddleware))
    
    // Define routes
    // ...
    // ...
    
    // Start the server
    y.Start()
}
```


### Route groups

Routes can be grouped into a route prefix and handle their own middleware.


### Nested groups

As routes can be grouped into a route prefix, other groups can be also grouped allowing for nested prefixes and middleware layers.

Example: 

```go
import "github.com/yarf-framework/yarf"

// Entry point of the executable application
// It runs a default server listening on http://localhost:8080
//
// URLs after configuration:
// http://localhost:8080
// http://localhost:8080/hello/:name
// http://localhost:8080/v2
// http://localhost:8080/v2/hello/:name
// http://localhost:8080/extra/v2
// http://localhost:8080/extra/v2/hello/:name
//
func main() {
    // Create a new empty YARF server
    y := yarf.New()

    // Create resources
    hello := new(Hello)
    hellov2 := new(HelloV2)

    // Add main resource to multiple routes at root level.
    y.Add("/", hello)
    y.Add("/hello/:name", hello)

    // Create /v2 prefix route group
    g := yarf.RouteGroup("/v2")

    // Add /v2/ routes to the group
    g.Add("/", hellov2)
    g.Add("/hello/:name", hellov2)

    // Use middleware only on the /v2/ group
    g.Insert(new(HelloMiddleware))

    // Add group to Yarf routes
    y.AddGroup(g)

    // Create another group for nesting into it.
    n := yarf.RouteGroup("/extra")

    // Nest /v2 group into /extra/v2
    n.AddGroup(g)

    // Use another middleware only for this /extra/v2 group
    n.Insert(new(ExtraMiddleware))

    // Add group to Yarf
    y.AddGroup(n)

    // Start server listening on port 8080
    y.Start(":8080")
}
```

Check the ./examples/routegroups demo for the complete working implementation.


### Route caching

A route cache is enabled by default to improve dispatch speed, but sacrificing memory space. 
If you're running out of RAM memory and/or your app has too many possible routes that may not fit, you should disable the route cache.

To enable/disable the route cache, just set the UseCache flag of the Yarf object: 

```go
y := yarf.New()
y.UseCache = false
```


### Chain and extend

Just use the Yarf object as any http.Handler on a chain. 
Set another http.Handler on the Yarf.Follow property to be followed in case this Yarf router can't match the request. 

Here's an example on how to follow the request to a public file server: 

```go
package main 

import (
    "github.com/yarf-framework/yarf"
    "net/http"
)

func main() {
    y := yarf.New()

    // Add some routes
    y.Add("/hello/:name", new(Hello))
    
    //... more routes here
    
    // Follow to file server
    y.Follow = http.FileServer(http.Dir("/var/www/public"))
    
    // Start the server
    y.Start(":8080")
}
```


### Custom NotFound error handler

You can handle all 404 errors returned by any resource/middleware during the request flow of a Yarf server. 
To do so, you only have to implement a function with the func(c *yarf.Context) signature and set it to your server's Yarf.NotFound property.

```go
y := yarf.New()

// ...

y.NotFound = func(c *yarf.Context) {
    c.Render("This is a custom Not Found handler")
}

// ...
``` 


## Performance

On initial benchmarks, the framework seems to perform very well compared with other similar frameworks. 
Even when there are faster frameworks, under high load conditions and thanks to the route caching method, 
YARF seems to perform as good or even better than the fastests that work better under simpler conditions.

Check the benchmarks repository to run your own:

[https://github.com/yarf-framework/benchmarks](https://github.com/yarf-framework/benchmarks)



## HTTPS support

Support for running HTTPS server from the net/http package. 

### Using the default server

```go
func main() {
    y := yarf.New()
    
    // Setup the app
    // ...
    // ...
    
    // Start https listening on port 443
    y.StartTLS(":443", certFile, keyFile)
}

```

### Using a custom server

```go
func main() {
    y := yarf.New()

    // Setup the app
    // ...
    // ...

    // Configure custom http server and set the yarf object as Handler.
    s := &http.Server{
        Addr:           ":443",
        Handler:        y,
        ReadTimeout:    10 * time.Second,
        WriteTimeout:   10 * time.Second,
        MaxHeaderBytes: 1 << 20,
    }
    s.ListenAndServeTLS(certFile, keyFile)
}

```


## Why another micro-framework? 

Why not?

No, seriously, i've researched for small/fast frameworks in the past for a Go project that I was starting. 
I found several options, but at the same time, none seemed to suit me. 
Some of them make you write weird function wrappers to fit the net/http package style. 
Actually, most of them seem to be function-based handlers. 
While that's not wrong, I feel more comfortable with the resource-based design, and this I also feel aligns better with the spirit of REST. 

In Yarf you create a resource struct that represents a REST resource and it has all HTTP methods available. 
No need to create different routes for GET/POST/DELETE/etc. methods. 

By using composition, you don't need to wrap functions inside functions over and over again to implement simple things like middleware or extension to your methods. 
You can abuse composition to create a huge OO-like design for your business model without sacrifying performance and code readability. 
 
Even while the code style differs from the net/http package, the framework is fully compatible with it and couldn't run without it. 
Extensions and utilities from other frameworks or even the net/http package can be easily implemented into Yarf by just wraping them up into a Resource, 
just as you would do on any other framework by wrapping functions.
  
Context handling also shows some weird designs across frameworks. Some of them rely on reflection to receive any kind of handlers and context types. 
Others make you receive some extra parameter in the handler function that actually brokes the net/http compatibility, and you have to carry that context parameter through all middleware/handler-wrapper functions just to make it available. 
In Yarf, the Context is automatically sent as a parameter to all Resource methods by the framework. 

For all the reasons above, among some others, there is a new framework in town. 


The Best Go Libraries For Web Frameworks - Full stack web frameworks. (6)

Fireball

Aero

Golf

Resoursea

REST Layer

YARF