Nice. Might just try this out in my next project.
I've actually built something similar back when I was doing C# but were not
able to finish due a stupid compiler bug.
It basically is a function(req, resp) { } thing, but which was made a first
class thing in my framework and methods
were provided to join, split, and combine them in interesting ways. Much
like what you have with pipe.siphon / pipe.fit and stuff.
For example, you can split web applications into aspects, each with their
own routes, entirely usable and testable
on their own and then you can have those set of pipes fitted together into
a single app via larger-encompassing
piece of routing pipe that dispatches requests to the right aspect (with
some url mangling to make requests looks local)
essentially a very simple sub-application mounting system etc.
Basically a connect middleware on steroids.
shameless self-promotion: I think I might have built something on a similar
idea with https://github.com/chakrit/jam
that async calls should be treated as a highest-level thing and then
methods provided to join / fit them together.
might worth checking out :p
One big glaring caveat with pipeworks though:
*Callback (the next() function in this case) should always accepts error as
first argument.*
Otherwise you will break a lot of established pattern and convention with
callback function usage.
For example, how do you:
- Handle error when one of the pipe throws or wants to callback with new
Error ?
- Use with other library that expect standard callback like `redis.get` ?
From what I can see from your README I cannot pass `next()` to this
function directly
without wrapping it in a `function(e, result) { next(result); }` first
to swap the arguments right?
And what if there is an Error?
On Tuesday, April 16, 2013 5:54:22 PM UTC+7, Kevin Swiber wrote:
>
> Anticipating the usual "why not use the async module?" question, I posted
> a "pipeworks vs. async" comparison here:
>
> https://gist.github.com/kevinswiber/5394922
>
> The Premise:
> 1. Start a pipeline.
> 2. Delegate to workers passed into the execution context.
> 3. Pause until the workers are done.
> 4. Continue executing the pipeline.
>
> Absolutely, the async module can handle this.
>
> The major difference…
>
> The async module is a toolbox of useful async utility functions.
> Pipeworks use cases are focused on joining, splitting, and passing around
> execution pipelines as first-class citizens. Executing a pipeline is
> explicit, and it's not uncommon to load up a pipeline and hang on to it
> until the right moment of execution.
>
> So when would you use pipeworks over async? When your use-case needs to
> explicitly manage execution pipelines. My use case is an HTTP reverse
> proxy. We build a pipeline of middleware to execute on a request. We
> build another pipeline for the response. A target endpoint gets thrown in
> the middle, the pipelines are joined, and the whole thing gets executed on
> each request. I wouldn't want to support that (along with custom
> middleware-specific pipelines) using just the async module. Pipeworks is a
> good fit.
>
> Cheers,
>
> --
> Kevin Swiber
> @kevinswiber
> https://github.com/kevinswiber
>
> On Apr 15, 2013, at 5:50 PM, Kevin Swiber <[email protected] <javascript:>>
> wrote:
>
> Hello.
>
> I just pushed the first version of
> pipeworks<https://npmjs.org/package/pipeworks>,
> a module for fitting together small components (pipes) into pipelines.
>
> With *pipeworks*, you can:
>
> - Fit components into execution pipelines.
> - Siphon the flow into branches during execution.
> - Join multiple pipelines together.
>
> Have a look-see! The repo is here:
> https://github.com/kevinswiber/pipeworks
>
> *Benefits:*
>
> - Reuse components (pipes<https://github.com/kevinswiber/pipeworks#pipes>
> ).
> - Redirect flow to branches on-the-fly
> (pipeline.siphon<https://github.com/kevinswiber/pipeworks#pipelinesiphonarguments-next>
> ).
> - Compose multiple pipelines prior to execution
> (pipeline.join<https://github.com/kevinswiber/pipeworks#pipelinejoinpipeline>
> ).
> - Ensure certain pipes are executed before or after the main execution
> flow
> (pipeline.fit<https://github.com/kevinswiber/pipeworks#pipelinefitoptions-pipe>
> ).
>
> *Example:*
> *
> *
>
> - https://github.com/kevinswiber/pipeworks#example
>
>
> It works very well with a plug-in architecture that imposes an ordered,
> asynchronous execution flow. Pipeworks is extracted from an HTTP server
> project, where it is currently being used as the primary engine of
> middleware execution. I hope it fits a use case for you, as well.
>
> Feedback, issues, and pull requests are always welcome.
>
> This is pretty rad, and I dig it. I hope you do, too.
>
> Thanks!
>
> --
> Kevin Swiber
> @kevinswiber
> https://github.com/kevinswiber
>
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
