next

[yoshuawuyts]

middleware

Like koa, but without any generators:

var merry = require('merry')
var app = merry()

app.use(function responseTime (req, res, ctx, next) {
  var start = Date.now()

  next(null, function (err, data, next) {
    var now = Date.now()
    console.log('time elapsed: ' + (start - now) + 'ms')
    next(err, data)
  })
})

router

In turn this means the router is just another piece of middleware. Calling it as the final handler would matter, but that's a common pattern anyway:

var merry = require('merry')
var app = merry()
app.router([ '/', routeHandler ])
app.listen(8080)

serializers

And adding custom new serializers isn't that tricky:

var merry = require('merry')
var app = merry()

app.use(function responseTime (req, res, ctx, next) {
  next(null, function (err, data, next) {
    if (err) return next(err)
    if (data instanceof SomeDataType) {
      res.statusCode = 201
      return res.end('<xml>MY CUSTOM XML REPLY BUHAHA</xml>')
    }
    next(err, data)
  })
})

error handling

Error handling is done by calling done(err) from anywhere in the stack. By default we've got logging and error handling for boom errors. Actually merry.error should probably just expose boom. This would allow for custom error handling and fancy error pages.

[yoshuawuyts]

hard part is done - https://github.com/yoshuawuyts/nanostack

[lrlna]

Okay, I am going to start brain dumping a few things in here and see how we get on. I think the most confusing part to users about merry is the way router is structured (or maybe it's the way we document it?)

I really like that methods are ideally meant to be handled in groups by a route. That means that with a larger architecture when I step into a project I don't know, I can see the router with all the possible routes and their methods and then can go and make sense of it. It works like a nice map to a project.

I get the idea that folks are used to working with .get() and .post(), but I don't think it's impossible to acquaint people with another way of doing it. I like that you put forward the above idea of just having a route and a handler, and I feel like that will work pretty well with a more nested router:

app.router([
  ['/', {
    get: getHandler()
  }],
  ['/candidate', {
    get: getCandidateHandler(),
    put: putCandidateHandler(),
    delete: deleteCandidateHandler()
  }],
  ['/article', {
    get: getArticleHandler(),
    put: putArticleHandler(),
    delete: deleteArticleHandler()
  }],
])

where the handlers could also just be require statements, and take in the usual req, res, ctx, done and handle the middleware portion. So the router only works with the one function, and still functions like a really nice source map.

idk.

and maybe i am also just reiterating whatever we've already talked about but ya ✨

[YerkoPalma]

Hi, is there any update on middlewares yet? If they are planned to be used with nanostack is the proposed API going to remain the same? Or is possible to use middleware with the current merry API?

[yoshuawuyts]

I don't think we're going to do middleware - instead run-series or run-waterfall should work well enough for most complex cases. For simple cases nesting a bunch of functions should probably work well too (: We've found that middleware creates unnecessary lock-in, whereas instead we could just be making code that's compatible with require('http'). Hope that makes sense! :D

On Thu, Jun 15, 2017 at 9:49 PM Yerko Palma notifications@github.com wrote:

Hi, is there any update on middlewares yet? If they are planned to be used with nanostack is the proposed API going to remain the same? Or is possible to use middleware with the current merry API?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/shipharbor/merry/issues/79#issuecomment-308845624, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWlerZXGDF6gSbDI7ue2cQPd18Kr32Rks5sEYi1gaJpZM4ML39i .

[lrlna]

I think I am going to close this so folks don't get confused on whether we are doing this (but we obviously can continue discussing)