dry-core
A toolset of small support modules used throughout the @dry-rb & @rom-rb ecosystems (by dry-rb)
decafsucks
Rebuilding decafsucks.com as an OSS Hanami 2.0 example app (by decafsucks)
Our great sponsors
dry-core | decafsucks | |
---|---|---|
1 | 1 | |
169 | 68 | |
0.6% | - | |
6.0 | 4.8 | |
2 months ago | 18 days ago | |
Ruby | Ruby | |
MIT License | - |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dry-core
Posts with mentions or reviews of dry-core.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-07-16.
-
Optimizing performance in MemoWise, a new memoization gem
I ran your benchmark against the Memoizable module from dry-core and got some interesting results. Both gems performed pretty much the same in the no argument benchmark. memo_wise was 1.5-2 times faster in the one argument benchmarks, while dry-core was around 2 times faster in the others.
decafsucks
Posts with mentions or reviews of decafsucks.
We have used some of these posts to build our list of alternatives
and similar projects.
-
Ryan Bigg - Hanami 2.0 Thoughts
In ordinary usage (i.e. outside the very simple rom setup in the getting started guide), I'd definitely recommend interacting with repos directly rather than the rom object itself. You can see this simple repo from my sample application (https://github.com/decafsucks/decafsucks/blob/8729deada9b6b6706b0e9893f535a198781ba3d0/slices/main/repos/cafe_repo.rb) as an example of an auto-registered repo. This can be resolved from my slice via `Main::Slice["cafe_repo"]` and is ready to use from there.
What are some alternatives?
When comparing dry-core and decafsucks you can also consider the following projects:
dry-validation - Validation library with type-safe schemas and rules
rom-sql - SQL support for rom-rb
memo_wise - The wise choice for Ruby memoization
dry-cli - General purpose Command Line Interface (CLI) framework for Ruby
ROM - Data mapping and persistence toolkit for Ruby
dry-types - Flexible type system for Ruby with coercions and constraints
dry-struct - Typed struct and value objects