Is this over-designed?

[magicdawn]

I don't see any point on creating a sub app to take over all traffics.
And this company with plenty of problems. Such as route orders.

https://github.com/krakenjs/express-enrouten/blob/v1.2.x-release/index.js#L120
https://github.com/krakenjs/express-enrouten/blob/v1.2.x-release/lib%2Fregistry.js#L65

[grawk]

As to the question of being over-engineered... ┐(ツ)┌ ... that's a pretty subjective question we shouldn't, and won't, attempt to "resolve"

To attempt to get at an actual issue here, are you concerned about route order? Do you have a use case to consider?

[jasisk]

@magicdawn I believe you may be confused by our implementation.

Routes register through express-enrouten are not mounted on a sub app. They are, however, mounted on a Router instance.

The sub app you see is popped off the stack immediately after it is mounted. The sole reasons for using this pattern (which I call the "ephemeral app pattern") are 1) to make express-enrouten work like a middleware without actually being one while 2) having access to the parent app and 3) being able to register a mount point.

What we actually do is create a Router instance and mount that to the parent app.

Now there are many benefits to using a Router instance instead of registering routes directly against the parent. For one, you can namespace routes by setting a mount path for the Router (e.g., app.use('/namespace', myRouter). Routers are self contained—you can bulk register middleware against their containing routes, you can register error handling middleware that are contained within the Router, etc.

If none of those grab you, perhaps the performance benefit will? Registering a hundred routes against the parent app means that your route resolution could potentially have to do 100 tests to resolve the route (because it will be a flat list of routes). If, however, you can register your routes under a namespace, you can turn your flat route map into a tree structure. Now your flat, 1-level route map will be a more tree-like 2 (or more) level route map.

I'm not sure what you're asking with your route order comment—could you please clarify?

[sixlettervariables]

If slightly more deterministic route ordering is what he'd like, I've started that in PR #47.