Introduing a web pipe for the dry ecosystem

First of all, apologies if somebody thinks it is not the appropriate place to post this announcement, but I do think it is relevant here.

I’d like to share with the dry community a small library I developed: web_pipe.

I’m not going to dig into the details here because you can find them in its README, but the overview is that it is a rack application builder through a pipe of operations on an immutable struct that can be halted at any step. In simple terms, it is also a web controller decoupled from the web routing process.

You can see that the way to use it is very similar to the taste that dry-rb proposes. Mainly, it resembles to dry-transaction, and uses design principles like IoC Container and DI, functional objects, etc. It also uses internally some of dry-rb libraries. The immutable struct is a dry-struct, and dry-monads, dry-types and dry-initializer are used under the hood.

The reason why I developed it is because I missed a layer for the web request/response cycle with dry-rb design concepts in mind, as roda and hanami-controller, even they are great, have different approaches. web_pipe would integrate very easily with dry-view, and my idea with it would be to use alongside hanami-router in an alternative stack to dry-web-roda.

Keep in mind that the library is at its very early stage. It has everything you need to build a rack application, but not some conveniences to make it more straightforward. I’ll be adding them as extensions, along with other improvements like caching.

I don’t know whether the dry-rb team would be interested in having this project under its organization. For my side, I’d be more than happy, because it would give me more motivation to keep it forward. For now, the library is only available in Github, and I’ll wait for your feedback on this before pushing to rubygems. If you like it, we could rename it to dry-web_pipe or dry-controller. If not, no worries, I’ll push it to rubygems with its actual name, or we can also leave it for a further stage.



@waiting-for-dev This looks super interesting! I’d love to give it a try sometime and see how it feels for the range of different types of request/route/web actions I typically find myself writing in an app. Do you happen to have any kind of example apps using it?

At this point I couldn’t say whether this could move into the dry-rb organisation, but I think it could easily be done at any point in the future if we all agreed to it (we’ve “imported” gems released under previous names before, it’s indeed how dry-transaction came to be).

Hey @timriley, thanks for looking into this and for your comments.

Unfortunately, right now I don’t have any example application code using it. As I said, this is the very beginning of its life and some additions need to be done. But I used Elixir’s Plug in the past, from which the library takes the model of a one-way pipe, and it worked very well for all the scenarios I was confronted with.

Cool, then surely I’ll release a 0.0.1 version to rubygems later this week and we’ll see in the future :slight_smile:

Hey folks!

I just wanted to post here again because I bring big news about web_pipe.

API has been highly consolidated and a lot of extensions has been added to make common workflows easy to implement. Between those, two of them are specially dedicated to the dry-rb ecosystem, integrating with dry-view and dry-schema respectively.

Even more important, I have added comprehensive documentation about every single feature. You can check it at:

I have also forked dry-web-roda and switched roda dependency to a combination of web_pipe plus hanami-router:

Its command line generator works exactly as in dry-web-roda. You can check its README for some details about generated files. Hopefully, it will lower entry barrier to start playing with web_pipe and, I’d love, get some feedback!

web_pipe is now production ready in the sense that it is currently being used
in an application in production and in that it supports any feature you may
need. It’s not in version 1.0 yet, so you should expect some API changes, but
they should be doable to adapt and everything will be documented :smiley: