feat: add Routes method to support getting all registered routes

[devhaozi]

📑 Description

Closes goravel/goravel#632

✅ Checks

• Added test cases for my code

[Copilot]

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.04%. Comparing base (9e85faf) to head (ebbc8fe).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #995   +/-   ##
=======================================
  Coverage   70.04%   70.04%           
=======================================
  Files         168      168           
  Lines       11353    11355    +2     
=======================================
+ Hits         7952     7954    +2     
  Misses       3050     3050           
  Partials      351      351           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hwbrzzl]

How about defining some constants for this field? User may not know what this is: GET or get?

[devhaozi]

How about defining some constants for this field? User may not know what this is: GET or get?

Looks like can't use these fields directly, since they are defined as string, not a custom type.

[hwbrzzl]

Okay, if so, string should be fine. Could you add a comment to this field to tell the user what this field will be like?

[almas1992]

Should the Route interface include a Routes() []Info method to expose route information?

[hwbrzzl]

It will be facades.Route().Routes, a bit strange. How about List or something else?

[devhaozi]

It will be facades.Route().Routes, a bit strange. How about List or something else?

How about GetRoutes?

[devhaozi]

It will be facades.Route().Routes, a bit strange. How about List or something else?

And gin use Routes

[hwbrzzl]

Em, if so, I suggest List. Any thoughts, please? cc @almas1992

[almas1992]

I agree facades.Route().List() seems more appropriate.

[almas1992]

I feel like there’s something off with the current implementation of Routes() []route.Info.

The returned handler names are mostly like github.com/goravel/gin.(*Group).xxx.handlerToGinHandler.func1, which aren’t meaningful or helpful.

For example, when I register a route like:

userController := controllers.NewUserController()
facades.Route().Get("/users/{id}", userController.Show)

The current Routes() output gives me a handler name like github.com/goravel/gin.handlerToGinHandler.func1, which doesn’t reflect the actual method being used.

Ideally, it should return something more meaningful, like goravel/app/http/controllers.(*UserController), which is what dlv (Delve debugger) displays. That format is much more informative and would be very useful for tools like artisan route:list to display readable and traceable route-handler mappings.

[devhaozi]

I feel like there’s something off with the current implementation of Routes() []route.Info.

The returned handler names are mostly like github.com/goravel/gin.(*Group).xxx.handlerToGinHandler.func1, which aren’t meaningful or helpful.

For example, when I register a route like:

userController := controllers.NewUserController()
facades.Route().Get("/users/{id}", userController.Show)

The current Routes() output gives me a handler name like github.com/goravel/gin.handlerToGinHandler.func1, which doesn’t reflect the actual method being used.

Ideally, it should return something more meaningful, like goravel/app/http/controllers.(*UserController), which is what dlv (Delve debugger) displays. That format is much more informative and would be very useful for tools like artisan route:list to display readable and traceable route-handler mappings.

Seems hard to do this, any suggestions? Or maybe just remove the Handler field?

[almas1992]

By the way, you can retrieve the method name like goravel/app/http/controllers.(*UserController).Show-fm within the func (r *Group) Get(relativePath string, handler httpcontract.HandlerFunc) function.

For example:

func (r *Group) Get(relativePath string, handler httpcontract.HandlerFunc) {
    pc := reflect.ValueOf(handler).Pointer()
    fn := runtime.FuncForPC(pc)
    fmt.Println("fn.Name() ========>", fn.Name())

    r.getRoutesWithMiddlewares().GET(
        pathToGinPath(relativePath),
        []gin.HandlerFunc{handlerToGinHandler(handler)}...,
    )
    r.clearMiddlewares()
}

Output:

fn.Name()=========> goravel/app/http/controllers.(*UserController).Show-fm

In other words, the []route.Info should ideally be populated during route definition, since all the necessary context—including the handler’s full name—is available at that point.

If performance is a concern, one possible optimization is to store reflect.ValueOf(handler).Pointer() during route definition, and defer the more expensive call to runtime.FuncForPC until the handler name actually needs to be displayed.

[devhaozi]

If performance is a concern, one possible optimization is to store reflect.ValueOf(handler).Pointer() during route definition, and defer the more expensive call to runtime.FuncForPC until the handler name actually needs to be displayed.

There is no performance issue, because the routes do not need to be registered frequently. I am considering that this will require many modifications.

[devhaozi]

If performance is a concern, one possible optimization is to store reflect.ValueOf(handler).Pointer() during route definition, and defer the more expensive call to runtime.FuncForPC until the handler name actually needs to be displayed.

There is no performance issue, because the routes do not need to be registered frequently. I am considering that this will require many modifications.

And need to support Group route, which seems not easy too.

[almas1992]

The required changes are indeed a bit extensive. For each routing method—such as Any, Get, Post, Put, Resource, etc.—we need to extract the handler’s function name and compute the full route path at the time of registration. This information should be stored in a global []route.Info slice to ensure all routes are collected in one place.

A global variable is necessary because if []route.Info were a field on individual structs, then route definitions—especially from grouped routes—would be scattered across multiple Group instances, making centralized tracking difficult.

Note: In Gin, computing the full route path for grouped routes requires combining both the originPrefix and prefix fields from the Group struct.

[almas1992]

I’m wondering whether it’s necessary to build a framework built-in routing system, instead of relying on third-party libraries like Gin or Fiber. Since Go 1.22 introduced built-in routing enhancements, the standard library is now capable of handling routing natively.

This would also give us full flexibility to implement structured routing, grouping, middleware, and other features without limitations—allowing the design to better align with the philosophy of our framework. @hwbrzzl

I know this would be a massive undertaking, but as the saying goes, “The road ahead is long and arduous, I will seek far and wide.”

[hwbrzzl]

I’m wondering whether it’s necessary to build a framework built-in routing system, instead of relying on third-party libraries like Gin or Fiber. Since Go 1.22 introduced built-in routing enhancements, the standard library is now capable of handling routing natively.

This would also give us full flexibility to implement structured routing, grouping, middleware, and other features without limitations—allowing the design to better align with the philosophy of our framework. @hwbrzzl

I know this would be a massive undertaking, but as the saying goes, “The road ahead is long and arduous, I will seek far and wide.”

Yes, maybe in the future. For now, it should not be our main work, can't give us a lot of benefits.

[devhaozi]

I’m wondering whether it’s necessary to build a framework built-in routing system, instead of relying on third-party libraries like Gin or Fiber. Since Go 1.22 introduced built-in routing enhancements, the standard library is now capable of handling routing natively.

This would also give us full flexibility to implement structured routing, grouping, middleware, and other features without limitations—allowing the design to better align with the philosophy of our framework. @hwbrzzl

I know this would be a massive undertaking, but as the saying goes, “The road ahead is long and arduous, I will seek far and wide.”

Yes, that why I create a new package mux, I want to do some test first.

[devhaozi]

Due to my work schedule, I am unable to continue this PR, if anyone is willing, please feel free to take over.