routingo: splitting Rails routes into something readable

Rails routes start as a tidy map of the application. Then the product grows. Admin areas, APIs, integrations, public pages, redirects, callbacks, and internal tools all begin to share the same file. At some point config/routes.rb stops feeling like an entry point and starts feeling like a scroll.

routingo is built around a simple idea: routes should be grouped by the way a developer thinks about the application. A billing slice can live with billing routes. API routes can live away from public pages. Experimental or internal areas can be kept readable without turning the main routes file into a long table of contents.

The value is not only file organization. Smaller route files make code review calmer because the diff lands near the domain it changes. They also make onboarding easier because the path from feature to route is shorter. When the routing layer is split along useful boundaries, it becomes easier to see what the app exposes and where new behavior belongs.

The shape I like here is conservative: keep Rails as Rails, keep the routing DSL familiar, and add just enough structure to make a large application feel smaller again.

Use it when:

• routes.rb is long enough that people avoid opening it.
• Routes from different product areas are mixed together.
• Route changes are noisy in code review.
• The app is old enough to have corners nobody wants to touch.

Good open source tools often come from a tiny pressure point. routingo is one of those: it treats route organization as a maintainability problem, not as a framework problem.