Awesome

wayfarer-to-server

31/01/2016: since wayfarer@6.0.0 this project is no longer compatible with wayfarer and has been deprecated. An alternative server implementation should be linked on the wayfarer page.

Wrap wayfarer to provide HTTP method matching and req, res delegation.

Installation

$ npm install wayfarer-to-server

Usage

import toServer from 'wayfarer-to-server'
import match from 'pathname-match'
import wayfarer from 'wayfarer'
import http from 'http'

const server = http.createServer((req, res) => {
  const router = toServer(wayfarer())

  router.on('/hello', {
    get: (req, res, params) => console.log('get'),
    all: (req, res, params) => console.log('any route matches')
  })

  router(match(req.url), req, res)
})

server.listen(1337)

API

router = toServer(wayfarer())

Wrap an instance of wayfarer to match HTTP methods and delegate req, res.

router.on(route, methods)

route: the route name that is matched. See routington.define() for all options.
methods: a nested router or an object containing methods. Method keys must be HTTP verbs, any or all. See methodist for the full documentation. Methods are lowercased before matched.

router(route, req, res)

Match a route and execute the corresponding callback. Alias: router.emit().

FAQ

why did you build this?

Server routers are inherently more complex than client routers because of the necessity to handle HTTP methods. wayfarer-to-server extends the wayfarer router to match HTTP methods and delegate req, res objects while maintaining its composable nature and fast radix trie core.

why not use existing server routers?

Most routers have strong opinions on how applications should be structured. These opinions are expressed in features such as: middleware helpers, error handlers, control flow constructs or even mutating the err, req objects. Some of these features might be desireable to have in an application, but shouldn't be included in a router.

License

MIT