From 1f5a274caecd34e561c54fbcf9ebba7ed23234d9 Mon Sep 17 00:00:00 2001 From: "Gerasimos (Makis) Maropoulos" Date: Fri, 3 Mar 2017 04:54:18 +0200 Subject: [PATCH] Nothing special yet: Readme updates and gofmt -s -w . (including vendor) Former-commit-id: b275e55b7cd90392772c49f72e8ecd644bf0634c --- README.md | 36 ++++++++++++++++-------------------- iris.go | 1 - status.go | 4 ++-- 3 files changed, 18 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index 3c000115..45c0d1a3 100644 --- a/README.md +++ b/README.md @@ -27,7 +27,7 @@ Iris is an efficient and well-designed toolbox with robust set of features.

-

Hashtag #Not_Just_YAWF

+

#Not_Just_A_Web_Framework

CHANGELOG/HISTORY @@ -39,37 +39,33 @@ Iris is an efficient and well-designed toolbox with robust set of features.

+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. -> Q: First of all, why I have to choose server-based web framework instead of AWS-based(or `serverless`) frameworks? -> A: `Serverless and AWS` Are Wonderful—Until They Go Wrong. Today the 'internet has been broken' and most of the sites -, including isitdownrightnow.com, are down or operating very slow! Why? Because of AmazonS3. -Many articles have been written about this sad fact: +**`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**. -- WashingtonPost: https://www.washingtonpost.com/news/the-switch/wp/2017/02/28/why-a-whole-slew-of-websites-are-suddenly-down-or-working-slowly/?tid=sm_fb&utm_term=.583d2ca0921b -- CNN: http://money.cnn.com/2017/02/28/technology/amazon-web-services-outages/index.html -- CNET: https://www.cnet.com/news/no-the-internet-is-not-broken-amazon-web-services-is-just-having-issues/?ftag=COS-05-10-aa0a&linkId=34980800 -- MIT Technology Review: https://www.technologyreview.com/s/603738/centralized-web-services-are-wonderful-until-they-go-wrong/?_ga=1.82562070.1263144274.1488319022 +Proof of concept: -> I will not reveal which one I wrote:) +- [Washington Post](https://www.washingtonpost.com/news/the-switch/wp/2017/02/28/why-a-whole-slew-of-websites-are-suddenly-down-or-working-slowly) +- [CNN](http://money.cnn.com/2017/02/28/technology/amazon-web-services-outages/index.html) +- [CNET](https://www.cnet.com/news/no-the-internet-is-not-broken-amazon-web-services-is-just-having-issues/?ftag=COS-05-10-aa0a&linkId=34980800) +- [MIT Technology Review](https://www.technologyreview.com/s/603738/centralized-web-services-are-wonderful-until-they-go-wrong/?_ga=1.82562070.1263144274.1488319022) +- [GolangNews](https://golangnews.com/stories/1835-serverless-is-wonderfuluntil-they-go-wrong.) -**Continue to read about Iris' advantages over other go web frameworks** 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, +The size of the executable file is a critical part of the Application Deployment Process. -I made two very simple identical applications, the first written with a famous mini web framework named `gin`(=a Router, with logger, recover and pure Context out-of-the-box support) and the second in `iris` -(=every feature that you will need at the first place is bundled when you install Iris. Including sessions, websockets, typescript support, a cloud-editor, the view engine with 5 different template parsers, two Routers to select from, an end-to-end framework to test your API, more than 60 handy helpers via Context, complete rest API implementation, and cors, basicauth, internalization i18n, logger and recover middleware out-of-the-box). - -I ran `go build` for both of them, - - - _gin_ had `9.029 KB` overall file size, - - _iris_ had `8.505 KB` overall file size! +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. -> The app didn't used any third-party library. If you test the same thing I test and adapt other features like sessions and websockets then the size of `gin` and `net/http` could be doubled while `iris`' overall file size will remain almost the same. +> 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! diff --git a/iris.go b/iris.go index 83d5765f..bd311c0d 100644 --- a/iris.go +++ b/iris.go @@ -462,7 +462,6 @@ func (s *Framework) Boot() (firstTime bool) { // right before the Listen, all methods have been setted // usually is used to adapt third-party servers or proxies or load balancer(s) s.policies.EventPolicy.Fire(s.policies.EventPolicy.Build, s) - firstTime = true }) return diff --git a/status.go b/status.go index ac3376be..e34c2e20 100644 --- a/status.go +++ b/status.go @@ -196,8 +196,8 @@ func (e *ErrorHandlers) GetOrRegister(statusCode int) Handler { } ctx.SetStatusCode(statusCode) if _, err := ctx.WriteString(statusText[statusCode]); err != nil { - ctx.Log(DevMode, "error from a pre-defined error handler while trying to send an http error: %s", - err.Error()) + ctx.Log(DevMode, "(status code: %d) %s", + err.Error(), statusCode) } }) e.mu.Lock()