Hello! New to the whole dry-rb community, but found myself experimenting through the weekend past with various post-Rails options for life, to include Roda. Now I’ve also been trying to work through some service layer design discussions with the team at work and dry-transaction has come up. Imagine my pleasant surprise while experimenting to stumble across dry-web and dry-web-roda! However, I can’t say that my experience getting up and running was all that simple or successful. Granted, I’m running Ruby 2.6.1 at home, but the errors I ran into were in at least one case somewhat documented (see https://github.com/dry-rb/dry-web/issues/45 specifically), there were others that came up from rom initialization and so on. Overall, it seems like there’s a lot still in flux if there can be that much breaking change in “current” versions, which has led me to ponder some of the following:
-
There’s pretty much nothing on the website about dry-web and/or it’s -roda counterpart. This is sad on a lot of levels, but in particular because trying to unpack Berg as an example for sure, and even to an extent dry-web-blog isn’t the easiest without a lot of pre-existing familiarity with some of the components that have a similar documentation problem. This issue is compounded by how up-to-date those various components and examples are or aren’t on top of it all.
-
How does dry-web fit into the philosophy of the other dry-* projects? It seems to have a slightly different aim, certainly once you get into dry-web-roda as at least a lightly opinionated, if far more pluggable, testable, and performant type of framework. I think this is useful and probably occupies a valuable place in the Ruby community, but it’s hard to see this without more documentation that describes intent.
-
How does (or doesn’t) this all interplay with Hanami and that project’s approach and/or usage of other dry-* and rom gems? I realize this is probably a big, tangled, interpersonal mess, as most collaboration and crossover is from time to time, but what’s the hope/goal of each? Where are they aligned and where do they diverge?
I’d really like to see this come together into a more cohesive/usable toolchain for folks wanting to get started with a complete stack of the “Good Stuff™” such as myself. I think one of the excellent places this fits is in the debate I’m (still) having over a project I’m working on about Elixir/Phoenix vs Ruby/(something that isn’t Rails). The dry-web composition seems like it’s poised to do a great job at bringing a number of things. that I like about Phoenix to bear around testability, injection, umbrella application structure and options, etc. without forcing me to use a language and tools that I’m not as deeply familiar with. I know there are others that fall into the same camp of wanting to stay with Ruby but also wanting a lot of those features of Phoenix, and I want to have something solid to point to for a bit of having it both ways.
Just to be clear, not looking to solely burn up time - I’m willing to sit down and try to learn more and get to putting some contributions together to help make it happen if I’m able to get on the same page with a lot of these questions, but this is the stuff that’s holding me back at this point. Yeah, there are some hiccups in the code, but I can get after those if I feel like I’m working from a position of purpose/strength in general.
