- [./adaptors](https://github.com/kataras/iris/tree/v6/adaptors) and [./middleware](https://github.com/kataras/iris/tree/v6/middleware) contains examples of their usage.
- [HISTORY.md](https://github.com//kataras/iris/tree/v6/HISTORY.md) is your best friend, version migrations are released there.
Iris has its own middleware form of `func(ctx *iris.Context)` but it's also compatible with all `net/http` middleware forms using [iris.ToHandler](https://github.com/iris-contrib/middleware/blob/master/cors/cors.go#L33), i.e Negroni's middleware form of `func(w http.ResponseWriter, r *http.Request, next http.HandlerFunc)`.
Here is a small list of Iris compatible middleware, I'm sure you can find more! Feel free to put up a [PR](https://github.com/iris-contrib/middleware) your middleware if you have built one :
| Middleware | Author | Description |
| -----------|--------|-------------|
| [binding](https://github.com/mholt/binding) | [Matt Holt](https://github.com/mholt) | Data binding from HTTP requests into structs |
| [delay](https://github.com/jeffbmartinez/delay) | [Jeff Martinez](https://github.com/jeffbmartinez) | Add delays/latency to endpoints. Useful when testing effects of high latency |
| [New Relic Go Agent](https://github.com/yadvendar/negroni-newrelic-go-agent) | [Yadvendar Champawat](https://github.com/yadvendar) | Official [New Relic Go Agent](https://github.com/newrelic/go-agent) (currently in beta) |
| [gorelic](https://github.com/jingweno/negroni-gorelic) | [Jingwen Owen Ou](https://github.com/jingweno) | New Relic agent for Go runtime |
| [JWT Middleware](https://github.com/auth0/go-jwt-middleware) | [Auth0](https://github.com/auth0) | Middleware checks for a JWT on the `Authorization` header on incoming requests and decodes it|
| [prometheus](https://github.com/zbindenren/negroni-prometheus) | [Rene Zbinden](https://github.com/zbindenren) | Easily create metrics endpoint for the [prometheus](http://prometheus.io) instrumentation tool |
| [render](https://github.com/unrolled/render) | [Cory Jacobsen](https://github.com/unrolled) | Render JSON, XML and HTML templates |
| [RestGate](https://github.com/pjebs/restgate) | [Prasanga Siripala](https://github.com/pjebs) | Secure authentication for REST API endpoints |
| [secure](https://github.com/unrolled/secure) | [Cory Jacobsen](https://github.com/unrolled) | Middleware that implements a few quick security wins |
| [stats](https://github.com/thoas/stats) | [Florent Messa](https://github.com/thoas) | Store information about your web application (response time, etc.) |
| [xrequestid](https://github.com/pilu/xrequestid) | [Andrea Franz](https://github.com/pilu) | Middleware that assigns a random X-Request-Id header to each request |
<ahref="http://gopherbook.iris-go.com/"><imgsrc="https://img.shields.io/badge/examples-%20repository-3362c2.svg?style=flat-square"alt="Examples for new Gophers"></a>
> Q: OK Iris is really fast, but my current website does not need that performance at the moment, are there other reasons to move into Iris?
Iris is fully vendored. That means it is independent of any API changes in the used libraries and **will work seamlessly in the future**!
The size of the executable file is a critical part of the Application Deployment Process.
Two very simple identical applications, the first was written with `iris` and the second with a simple golang router.
- _iris_ had `8.505 KB` overall file size
- _gin_ had `9.029 KB` overall file size
- _net/http_ had produced an executable file with `5.380 KB` size.
> Iris has built'n support for the most of the features that you will use to craft your perfect web application, while the golang router(gin & httprouter alone) doesn't. Imagine what would happened if the simple app we created would use `sessions`, `websockets`, `view engine`... I tested that too, `gin` and `net/http` had produced the x3 of their original size, **while `iris application`' overall executable filesize remained stable**!
**Applications that are written using Iris produce smaller file size even if they use more features** than a simple router library!
Iris always follows the latest trends and best practices. Iris is the **Secret To Staying One Step Ahead of Your Competition**.
Iris is **a high-performance** tool, but it doesn't stops there. Performance depends on your application too, **Iris helps you to make the right choices** on every step.
**Familiar** and easy **API**. Sinatra-like REST API.
Contains examples and documentation for all its features.
Iris is a `low-level access` web framework, you always know what you're doing.
You'll **never miss a thing** from `net/http`, but if you do on some point, no problem because Iris is fully compatible with stdlib, you still have access to `http.ResponseWriter` and `http.Request`, you can adapt any third-party middleware of form `func(http.ResponseWriter, *http.Request, next http.HandlerFunc)` as well.
Iris is a community-driven project, **you suggest and I code**.
Unlike other repositories, this one is **very active**. When you post an issue, you get an answer at the next couple of minutes(hours at the worst). If you find a bug, **I am obliged to fix** that on the same day.
Click the below animation to see by your self what people, like you, say about Iris.
<imgsrc="https://github.com/iris-contrib/website/raw/gh-pages/assets/gif_link_to_yt2.gif"alt="What people say"/>
</a>
> Q: Why no `serverless`?
New web developers are so enthusiastic about the idea of `serverless` and `AWS`. Most of the experienced developers we already know that we shouldn't use these things for our critical parts of our application.
**`Serverless and AWS` Are Wonderful—Until They Go Wrong.** There was a flash-point (at 28 February of 2017) where the 'internet was offline' and most of the sites, including isitdownrightnow.com, were down or operated very slow! Why? Because of `serverless` and `AmazonS3`.
Please think twice before moving your code into `serverless`, **instead, use web frameworks that are created for servers that you control**, i.e Iris.
The Iris philosophy is to provide robust tooling for HTTP, making it a great solution for single page applications, web sites, hybrids, or public HTTP APIs. Keep note that, today, iris is faster than nginx itself.
Iris does not force you to use any specific ORM or template engine. Iris is routerless which means you can adapt any router you like, [httprouter](https://github.com/kataras/iris/blob/v6/adaptors/httprouter/_example/main.go) is the fastest, [gorillamux](https://github.com/kataras/iris/blob/v6/adaptors/gorillamux/_example/main.go) has more features. With support for the most used template engines (5), you can quickly craft the perfect application.
I started to design Iris the night of the 13 March 2016, some weeks later, iris started to became famous and I have to fix many issues and implement new features, but I didn't have time to work on Iris because I had a part time job and the (software engineering) colleague which I studied.
I wanted to make iris' users proud of the framework they're using, so I decided to interrupt my studies and colleague, two days later I left from my part time job also.
- **Do Pull Requests on the [iris-contrib](https://github.com/iris-contrib)** organisation's repositories, like [book](https://github.com/iris-contrib/gitbook), [examples](https://github.com/iris-contrib/examples) and to [gopherbook](http://gopherbook.iris-go.com/).
If you are interested in contributing to the Iris project, please see the document [CONTRIBUTING](https://github.com/kataras/iris/blob/master/.github/CONTRIBUTING.md).
Besides the fact that we have a [community chat][Chat] for questions or reports and ideas, [stackoverflow](http://stackoverflow.com/) section for generic go+iris questions and the [iris support](http://support.iris-go.com) for bug reports and feature requests, you can also contact with me, as a person who is always open to help you: