Routing, Route Groups, and the stdlib Baseline

What Routing Really Does

Routing is the process that turns an incoming HTTP request into a specific chain of code: match a method and path, attach the right middleware, extract any path state, and hand the request to exactly one handler. Good routing makes the resource model legible. Poor routing hides scope, duplicates policy, and forces every handler to rediscover context that the path already knew.

The term route group is conceptually broader than any one library. A route group is simply a set of routes that share a path prefix, a middleware chain, or both. Whether the implementation uses net/http, Gin, chi, or another router is a secondary question. The underlying design problem is always the same: where does shared request policy attach, and how does the URL express resource containment?

The Real Meridian Baseline

The current repository uses the standard library only. apps/gateway/internal/router/router.go builds an http.NewServeMux, registers GET /healthz, and returns an http.Handler. apps/identity-service/cmd/identity-service/main.go does the same. No go.mod file includes Gin, and no service has path parameters or grouped middleware yet. That is the ground truth this chapter must respect.

Route Groups as a Concept

Even with stdlib net/http, the route tree should still be designed in groups. For identity-service, public auth endpoints form one group. Authenticated membership endpoints form another. Tenant-scoped administration endpoints form a third. The code can implement those groups with helper functions, nested muxes, prefix dispatch, or a richer router later. What matters first is the structure of the tree and the middleware boundaries it implies.

The most common routing mistake in multi-tenant systems is flattening everything into short URLs and hoping headers or body fields carry the real scope. A better design makes important boundaries obvious in the route tree. Once the path contains /v1/tenants/{tenantID}/memberships, a reviewer can immediately ask whether the tenant in the path matches the tenant in the authenticated actor context. Routing structure should invite that question, not obscure it.

Designing the Identity Route Tree

identity-service owns tenants, users, memberships, roles, and permissions. Its future HTTP surface should therefore separate identity-establishing routes from tenant-administering routes. The first set answers 'who is the caller?' The second set answers 'what may the caller do inside this tenant?' Combining both concerns into one flat handler list leads to duplicated checks and weak mental models.

When Gin Would Earn Its Place

A router library earns its place when the route tree becomes rich enough that the standard library starts fighting readability. Named path parameters, nested groups, shared middleware chains, and request helpers can all make a router worthwhile. But introducing one should solve an actual codebase problem, not retroactively decorate a small service. Meridian is not there yet. It has /healthz routes, one recovery middleware in the gateway, and empty domain packages. The correct present-tense lesson is the stdlib baseline, not a speculative framework migration.

• Treat route groups as a design concept first and a library feature second.
• Use the real net/http baseline when describing meridian today.
• Design the route tree so tenant and authorization boundaries become visible in the path and middleware ordering.
• Adopt Gin only if route complexity genuinely justifies it later.