mxriverlynn
commented
8 years ago @dermidgen I've been meaning to write up a road map for a while, but haven't had time to focus on the things that i know i need to do. projects and life and all that. :)
for a bit of background:
this project sprang to life nearly 3 years ago when i first started working with RabbitMQ. the github history doesn't reflect that, because it was originally part of a proprietary system i was building in a private repository.
the original goal was to abstract the pain of the underlying amqp library away from my applications. i wanted something simple and clean that would encapsulate the patterns i use frequently. having gone through 3 different amqp libraries as the underlying tech, things got a bit ugly and hard to maintain.
on top of that, i was still heavily in the learning while doing phase when i wrote most of this code. so, there's a lot of ugly parts leftover and a lot of missing things that i need.
for example, some missing features:
- ability to reject or nack a message (right now, it automatically nacks a failed message handler and there's no way to get around that)
- method signatures violate node.js standards and don't provide error parameter in many cases where it should
- wascally features are hidden behind obtuse object code and hard to use, sometimes
the over-all goal of the project is still to simplify runtime use of rabbitmq, but in a different way than i had originally planned.
one of my very large applications requires dynamic creation of exchanges, queues and bindings - things that can only be determined at runtime, based on configuration data in the application itself. wascally supports this, but it seems to prefer the one-time configure call to pre-configure everything. rabbus was supposed to make this easier for me... and it largely does. i am able to create the rabbitmq topology i need, at runtime... but the topology options are pretty much limited to what i needed in my system.
i see the future of rabbus as more of a composition system, where features and capabilities can be composed in to an object rather than coded in to it directly.
i want to reduce the amount of code duplication between all of the various producers and consumers (i started working on this with producer and consumer base objects... but didn't get very far, and it confused some of the direction with ugly code)
ultimately, i see rabbus as a service bus layer on top of wascally - a place where common patterns and conventions are built-in so you don't have to recreate them with wascally, yourself.
this probably doesn't provide much in the way of actionable tasks... but hopefully this gives an idea of my intention, and a place to start looking at things.
i think there is some low-hanging fruit in terms of simplifying and making the API more consistent... the ability to reject and nack messages, etc. it's largely a question of digging in, trying to use it and seeing what needs to be fixed / changed / added.
and with my time becoming more and more constrained due to family needs, rabbus needs all the help it can get from you and/or anyone else that wants to help it move in a better direction!
rhyslbw
@derickbailey Do you have a roadmap or list of fixes/features you would like to see implemented? I would like to begin leveraging this library in production, but I am concerned with stability. How can I help bring stabilize this project and bring it into alignment with your current needs?