👉 **Keep RouteGroups flat. Don’t nest them.**
---
### Best way to structure `RouteGroup`s (Recommended)
For **large Flint Dart apps**, the best practice is to keep RouteGroups **flat, modular, and feature-based**, not nested.
Each RouteGroup should represent **one clear domain or feature** (auth, users, admin, billing, etc.).
```dart
class AuthRoutes extends RouteGroup {
@override
String get prefix => '/auth';
@override
void register(Flint app) {
app.post('/login', AuthController().login);
app.post('/register', AuthController().register);
}
}
```
Register it once at the app level:
```dart
app.register(AuthRoutes());
```
---
### ❌ Why nesting RouteGroups is discouraged
Nesting RouteGroups:
* Makes routing harder to reason about
* Causes middleware inheritance confusion
* Hurts readability and debugging
* Scales poorly as the app grows
If you feel the need to nest RouteGroups, it usually means:
> You should create **another RouteGroup**, not a nested one.
---
### ✅ Use prefixes instead of nesting
Use the `prefix` getter to define structure:
```dart
class AdminRoutes extends RouteGroup {
@override
String get prefix => '/admin';
@override
List<Middleware> get middlewares => [AdminMiddleware()];
}
```
This keeps:
* Routing flat
* Middleware explicit
* Structure clear
---
### When to use `app.mount` instead
`app.mount()` is **not a replacement for RouteGroups**.
Use it only for:
* Pluggable modules
* Optional features
* External packages (DB manager, mail, admin panels)
**Core application routes should always use RouteGroups.**
---
### Final recommendation (Community Answer)
✔ Keep RouteGroups **flat**
✔ One RouteGroup per feature/domain
✔ Use `prefix` for structure, not nesting
✔ Apply middleware at the group level
✔ Use `app.mount()` only for modular extensions
> **Flat RouteGroups scale. Nested RouteGroups don’t.**
This is the recommended and idiomatic approach in Flint Dart.