To enable the fastest routing we should avoid linear scans over both route patterns (in the Router) and middleware (in mount()). Instead we should have a trie-like structure for fast-matching requests against a collection of patterns and use in the Router.
Once we have a fast-at-scale Router, mount() becomes an anti-pattern, and because routing and mounting is such an important and primary task of a web server framework, routing should just move into core.
The future core API would merge the current App and Router classes.
Instead of a separate Router:
import {App, Router} from 'zipadee';
const app = new App();
const router = new Router();
router.get('/greet/:name', async (req, res, next, params) => {
// ...
});
app.use(router.routes());
app.listen();
we'd have routing methods on App:
import {App} from 'zipadee';
const app = new App();
app.get('/greet/:name', async (req, res, next, params) => {
// ...
});
app.listen();
Router would stick around to enable nested routers. App would implement the Router interface.
We will need an implementation of something like URLPatternList to match against a collection of URLPatterns. See whatwg/urlpattern#30
To enable the fastest routing we should avoid linear scans over both route patterns (in the Router) and middleware (in
mount()). Instead we should have a trie-like structure for fast-matching requests against a collection of patterns and use in the Router.Once we have a fast-at-scale Router,
mount()becomes an anti-pattern, and because routing and mounting is such an important and primary task of a web server framework, routing should just move into core.The future core API would merge the current
AppandRouterclasses.Instead of a separate Router:
we'd have routing methods on
App:Routerwould stick around to enable nested routers.Appwould implement theRouterinterface.We will need an implementation of something like
URLPatternListto match against a collection of URLPatterns. See whatwg/urlpattern#30