server-gateway and introspection support

[mcollina]

The example mention "api-gateway" and link to "server-gateway", which points to nowhere.

It seems that api-gateway/server-gateway can walk through all the declared routes, and you can attach metadata to them! Can you please document the API for doing so?

[yoshuawuyts]

Haha, yeah I never came around to writing those - got lost in other distractions before I could implement them.

If you pass a callback as opts.wrap, you get a function that can wrap the whole thing (L53-L61). Here's a test that shows off the behavior in action: https://github.com/yoshuawuyts/server-router/blob/master/test.js#L168-L189

Inside of the handler there could be any number of assertions passed, values extracted (how cool would it be to have swagger-generating APIs? :grin:) and pretty much anything else that makes sense for a server.

But to be honest I think in hindsight I might make the base API of server-router slightly closer to that of sheet-router. I've found a single, nested router to work brilliantly - quite like an application manifest of some sorts :sparkles:

Does this make sense? Cheers!

[mcollina]

opts.wrap "intercepts" each request. That's really cool for validations, etc. However, I'm interested on a way to programmatically browse the registered paths, and possibly use that to generate swagger docs etc. It's one of the feature of Hapi I like most.

Makes super sense, @davidmarkclements and myself have been thinking about writing a "web framework" for some time, as all of those are really slow compare to native http.

[davidmarkclements]

yes, yes and yes. 40k reqs (core http) down to 15k reqs (express, koa, and I'm being generous) is hardly an acceptable cost for abstraction sugar, surely?

I love what @yoshuawuyts is doing with choo - a loose assemblage of pieces packaged as a recommended architectural pattern - let's do that for a light weight web framework, mainly driven for creating API layers that front distributed systems

[yoshuawuyts]

However, I'm interested on a way to programmatically browse the registered paths

Agreed, this should be possible - the internal trie structure is exposed through router._router._trie (if I'm not mistaken) and could then be traversed using a recursive function to extract the paths. If combined with opts.wrap more information could be exposed by appending it to the callback (if so desired). It'd be grand if the crawler could be exposed as a separate package, perhaps even included as a file in wayfarer (the underlying trie implementation).

---

let's do that for a light weight web framework, mainly driven for creating API layers that front distributed systems

Yesssss! - that's what I wanted to do with merry but then choo took off big time and now I'm stuck improving frontend haha. There's also bankai which would take care of static asset serving, but yeah that too kinda fell through a little because of choo :grin:

Super excited to see what you'll come up with!

[yoshuawuyts]

cc/ @ahdinosaur this discussion is probably relevant for the work you're doing on vas too :sparkles:

[davidmarkclements]

oh cool pull streams, I wrote websocket-pull-stream some time ago, gzips and minifies to <3kb as opposed to websocket-stream that gzip and minifies to ~20kb

[yoshuawuyts]

@davidmarkclements ooh neat! - yeah I suspect pull-stream might be reaching wider audiences soon; we're def making a lil push for it and I think it might work out quiiiiite well

[mcollina]

I love that merry has a full readme and a top-notch implementation 😱 https://github.com/yoshuawuyts/merry/blob/master/index.js 🎉

[yoshuawuyts]

documentation driven development, amirite ✌️

[yoshuawuyts]

Added the walk function in v4.0.0 :sparkles: - probably also want to pass { thunk: false } so it like doesn't wrap things for ya and we save a closure :grin: