📝 [v3 Proposal]: Koa Style `ctx.Request` and `ctx.Response` Objects about fiber HOT 12 OPEN

I am OK with the change. Btw we should return Req() and Resp() as interface.

from fiber.

@efectn we could also use this for the ctx interface

from fiber.

Sorry to bring this up again, but I figured I'd try to close the loop on this because the previous discussion kind of fizzled out when the Koa idea was brought up.
No worries if we want to keep the API as-is, it will be good to be able to point back to this proposal in the future either way.

Gist with sample implementation
https://gist.github.com/nickajacks1/2fd8bc71ba3a5a9839ebaf4313082efe

from fiber.

Ping @gofiber/maintainers

from fiber.

i like your proposal and gist, we can do it that way for all i care

this way the old api's still work and it's better separated

from fiber.

@efectn @gaby @sixcolors any ideas for this? otherwise someone can start with this or ?

from fiber.

https://github.com/rjeczalik/interfaces#cmdinterfacer-

maybe via go:generate

from fiber.

@efectn we could also use this for the ctx interface

Sounds good idea

from fiber.

Sounds good, to keep it short and neady I vote for .Req / .Res interface. It's still good to allow users to access the underlying fasthttp pointers. Maybe ctx.Fasthttp() is an option, but should all methods be exposed in this one? If so, some functions might break internals, can place it "use at own risk" kinds thing 😆 or we limit it to fasthttp's request / response pointers only.

Feel free to comment

from fiber.

I also vote for .Req / .Res interface. Your example looks good.

I like ctx.Fasthttp().Res() more than ctx.Res().Fasthttp() but it doesn't really matter. I could easily be convinced it should be the other way.

from fiber.

Thanks for the feedback. I'll get started.
I think that fasthttp gives you enough ways to shoot yourself in the foot that accessing it should be a "use at your own risk" type of thing, but leaving it available for use is probably a good idea just in case someone really needs it due to gaps in the fiber public API.

Should the existing ctx.Request() and ctx.Response() be left alone, marked deprecated, or removed? Today, they return the fasthttp objects, but they're also available using c.Context().Request. It would be confusing to have more than one method that returns a "request" or "response" object, but removing it entirely would be one more breaking change. Maybe that's fine since it's a new major version and it can be fixed with a find+replace.

from fiber.

I lean toward removing redundant or similarly named functions that would make the framework confusing. Accessing the underlying fasthttp pointer should be very explicit so I favor the ctx.Fasthttp() approach.

This would be breaking and I think v3 is a good opportunity to clean up and improve our approach. But, i think we really need to start a v2 => v3 migration guide. I recently did a migration of play billing lib for an Android app and think Google did a good job of their guide https://developer.android.com/google/play/billing/migrate-gpblv6

What does everyone else think?

from fiber.