Fiber: 馃殌 New function to initialise Fiber App

Created on 18 Jul 2020  路  9Comments  路  Source: gofiber/fiber

Is your feature request related to a problem?

My feature request is related to the logger and the way Fiber is initialised. Can we have a developer friendly environment by integration of logger and Fiber app when development is in progress?

Describe the solution you'd like
The Fiber v1.13.0 has a colourful logger which is very useful. Can we create a new function like Fiber.Default(). which when the env variable is not set to release , it automatically includes the logger and the recovery middleware . If it is set to release we can include only the recovery logger.

But Why?
It will be easy and intuitive for users who want to prototype routes fast , saves some time and it feels more natural. Some other go web frameworks also provide this kind of feature and we could also follow the same standards so that the users feel more welcome when they try out this framework.

Describe alternatives you've considered
Maybe we could print a message when users use Fiber.New() to include such middleware for better development experience?

Additional context

package main

import (
    "github.com/gofiber/fiber"
    "github.com/gofiber/fiber/middleware"
    "net/http"
)

func main() {
    app := fiber.New()
    app.Use(middleware.Logger())
    app.Use(middleware.Recover())


    //let the above 3 commands be merged into one
    // app := fiber.Default()


    app.Get("/", func(c *fiber.Ctx) {
        c.Status(http.StatusOK)
        c.Send("Hello World!")
    })
    _ = app.Listen(3000)
}

However we can still provide the user to have option for Fiber.New() if the user prefers so.

馃槑 Nice to Have

Most helpful comment

Hi @DarthBenro008, nice typo catch in https://github.com/gofiber/fiber/pull/638 馃憤, here are my two cents on this proposal:

One of Fiber's core features is having a flexible but minimalistic API design, just like Express. I mentioned API design specifically because I think having too many helper methods will eventually bloat the framework. This is one of those things which separates us from other frameworks.

I also think that implementing another initialize method for just two middleware is just not worth it, plus its good practice to visually see what middleware is declared to avoid confusion. I'm very strict when it comes to adding new methods to Fiber, I hope I elaborated enough why this is.

Let me know what you guys think 鉂わ笍

All 9 comments

Thanks for opening your first issue here! 馃帀 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

Thanks for the issue!

I think it's a good idea. As far as I know, Gin does this too.

Okay we can do that, just need to define which settings and middlewares are standard

Default mw: recover, logger, compression? , cors?, favicon?

Maybe cors should be in the core middlewares

I was thinking we should keep some standards such as

Default MW Development : logger, recovery , facvicons , compression
Default MW Release : recovery, favicons and compression (if it doesn't affect performance)

I believe middleware such as cors must be configurable and upto user's choice , the main aim of default middleware is to get started quickly and fast prototyping. Suggestions are welcome.

I will start working on the template soon then!

I don't think it is necessary for an api application to have the favicon and compress middleware.

Okay , so the final standards can be :

Default MW Development : logger, recovery
Default MW Release : recovery.

I hope this will do?

Hi @DarthBenro008, nice typo catch in https://github.com/gofiber/fiber/pull/638 馃憤, here are my two cents on this proposal:

One of Fiber's core features is having a flexible but minimalistic API design, just like Express. I mentioned API design specifically because I think having too many helper methods will eventually bloat the framework. This is one of those things which separates us from other frameworks.

I also think that implementing another initialize method for just two middleware is just not worth it, plus its good practice to visually see what middleware is declared to avoid confusion. I'm very strict when it comes to adding new methods to Fiber, I hope I elaborated enough why this is.

Let me know what you guys think 鉂わ笍

Hi @Fenny , thanks 馃槃 , so here is my view on this:

I completely agree with the fact Fiber is light and fast , and that is what is unique about it, but as an developer I felt logger and recovery are primitive tools required when developing, esp when we have such a cool logger too, I believe most of the developers are going to add these primitive middleware's anyway at the start when they get down to develop (No statistical proof, but evident from experience and other's opinions) hence I suggested why not add them in one command?

I do not see this as a bloat but an feature that could polish Fiber more. I completely agree those points are valid from a technical point of view , I am just suggesting a convenience point of view 馃槄

Hi @DarthBenro008, I agree with Fenny's comment as well due to the fact that Fiber want to have a minimalistic API design.

Eventhough I agree with you that both the logger and recover middlewares are pretty primitive and might get added by most of the developers using Fiber, I don't think adding a helper function to add these middlewares is a significant improvement to the overall framework.
In addition, leaving aside the discussion of which middleware would have been most commonly used to implement in your proposed Default method.

I am closing this issue after contrasting the ease of use and minimalism regarding your proposal. Feel free to join our Discord and discuss your ideas and contributions as well. Thanks! 馃殌

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Terisback picture Terisback  路  3Comments

renatojf picture renatojf  路  3Comments

MohamedGouaouri picture MohamedGouaouri  路  3Comments

petersephrin picture petersephrin  路  4Comments

bashery picture bashery  路  4Comments