📝 [Proposal]: Seperate router

[pjebs]

Feature Proposal Description

It would be good if Fiber's router could be made more modular and separated out into a independent package.

Alignment with Express API

N/A

HTTP RFC Standards Compliance

N/A

API Stability

API Can remain stable

Feature Examples

N/A

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have searched for existing issues that describe my proposal before opening this one.
• I understand that a proposal that does not meet these guidelines may be closed without explanation.

[gaby]

What's the benefit? Sounds like maintenance overhead

[pjebs]

If anything, it will be easier to maintain if it's seperate out and not mixed with all the other code.

Making the main framework part simpler to see and understand what is going be on.

[pjebs]

The fiber codebase is too large and has become a jungle.

Harder for new people to quickly contribute stuff.

[pjebs]

Plus my understanding is the router is stable

[gaby]

The fiber codebase is too large and has become a jungle.

Harder for new people to quickly contribute stuff.

Please lets us know which parts feel that way so we can address it.

[gaby]

Plus my understanding is the router is stable

Mostly yes, but having to do maintenance of another repo, dependencies, workflows, etc doesn't outweigh that.

[pjebs]

@ReneWerner87 what's your opinion

[grivera64]

@pjebs When you say a separate router, do you mean:

• Making a new independent module for the router that needs to be installed separately with go get? Or
• Making a new package in the same GitHub repository, but in a way to organize router related code and files into a subfolder/several files in the same main module?

If you mean the second option, this sounds reasonable. The first option feels like it would add unnecessary separation, considering that the router is part of Fiber core.

[pjebs]

In both cases they will be seperate packages so the effect will be the same in terms of importing and maintaining.

Only different is one will be in a different repo which is hardly a inconvenience - especially since it is stable and will hardly get updated/modified. It is just an extra line in go.mod.

One advantage of seperate repo is others can use it for other projects.

Both options are better than the current codebase which has everything in one large package

[ReneWerner87]

@pjebs how does the request differ from the proposal ?
#2202

[ReneWerner87]

in order to solve this concept, a few things have to be finalized first, which we can do until version 4

[pjebs]

I think creating an interchangeable router would be too ambitious for v3 of Fiber given the delays with v3 and how many people are getting impatient with it.
If it is going to happen, it should use a "blank" import registration process like database/sql drivers.

My proposal is much simpler and can done in a day of refactoring, and a step in the right direction to implement #2202 since the default router will be only 1 of potentially many router packages that can be used with Fiber, and thus should be a separate package/module/repo.