Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Rhys Bartels-Waller
    @rhyslbw
    Welcome back! Let’s chat privately about that
    Rhys Bartels-Waller
    @rhyslbw

    So based on the discussion we had relating to the Space.cqrs.ProcessManager and some more research I’m in favour of reworking it based on the State Machine pattern. Here’s a good excerpt from the MS Journey project:

    "In this bounded context, a process manager is a class that coordinates the behavior of the aggregates in the domain. A process manager subscribes to the events that the aggregates raise, and then follow a simple set of rules to determine which command or commands to send. The process manager does not contain any business logic; it simply contains logic to determine the next command to send. The process manager is implemented as a state machine, so when it responds to an event, it can change its internal state in addition to sending a new command.

    Our process manager is an implementation of the Process Manager pattern defined on pages 312 to 321 of the book by Gregor Hohpe and Bobby Woolf, entitled Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Professional, 2003). “

    Dominik Guzei
    @DominikGuzei
    Ahoi! Yeah let's do it like that – I In the first step, I would suggest that we strive for a very basic implementation of the state machine pattern without any bells and whistles. Then we can try it out in an real-world scenario and work from there.
    Rhys Bartels-Waller
    @rhyslbw

    Have you read these articles? Given the state machine pattern still needs to record a log, maybe it is better to retain event sourcing as the persistence, but instead of just extending the aggregate, the event sourcing functionality be extracted that can then be extended by the Aggregate class and the Process Manager class

    http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-i-of-ii/
    http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/

    That way the ProcessManager doesn’t end up with Aggregate concepts, and it can be expressed with methods like Transition, Configure, PermitIf
    Rhys Bartels-Waller
    @rhyslbw
    *Aggregate concepts like handling a command…
    If the methods abstracted the boilerplate code required for event sourcing, it would seem that the ‘overhead’ is no longer a problem.
    Dominik Guzei
    @DominikGuzei
    Yeah I've read both and that was actually the reason i implemented the process manager with event sourcing.
    Of course we could extract the basic functionality, but i am not sure how much benefit it would bring as the first step. It also wouldn't solve the concern of "boilerplate events" – they are not boilerplate but in many cases it feels like a lot of overhead to model even the simplest concepts
    but i guess that's a general problem with event sourcing, it has long-term benefits but brings a lot of tiny overhead-tradeoffs to the table
    Rhys Bartels-Waller
    @rhyslbw
    I guess by boilerplate I actually mean we could focus on making the API more expressive rather that it just being a generic event handler with the ability to trigger commands and maintain state.
    Which could initially be done by experiements directly within the ProcessManager class, then later if it makes sense, revisit the class it’s extended from
    Dominik Guzei
    @DominikGuzei
    yeah of course, that's something we can improve step-by-step ;-)
    Rob Landers
    @withinboredom
    Hello...
    Rob Landers
    @withinboredom
    Have any of you guys hooked this up to distributed queue, like SQS, IronMQ or Azure ServiceBus?
    Rhys Bartels-Waller
    @rhyslbw

    Hey @withinboredom. No but the latest space:messaging includes a basic custom queue using Mongo. It’s undocumented right now but check this commit for changes and tests CodeAdventure/space-messaging@aa286c7

    It’s brand new and I’ll be starting an implementation using it later today

    Rhys Bartels-Waller
    @rhyslbw
    Looks like @DominikGuzei released this to Atmosphere as 1.5.0 but maybe not pushed the latest to GitHub yet
    Rob Landers
    @withinboredom
    looks pretty awesome, and pretty straight forward to extend and get it to use a different queue system
    Rhys Bartels-Waller
    @rhyslbw
    What type of systems are you connecting?
    Rob Landers
    @withinboredom
    It will probably be through Azure ServiceBus, since they give you free money for Azure through bizspark.
    Still have a long way to go before I get that far.
    Rhys Bartels-Waller
    @rhyslbw
    What about the apps though, all Meteor?
    Rob Landers
    @withinboredom
    The core will be, but there are other microservices which are not.
    Rhys Bartels-Waller
    @rhyslbw
    Are you using space-cqrs?
    Rob Landers
    @withinboredom
    yeah, It's some bank automation software, so I'll be receiving and sending events to workers that are running casperjs and other node based software
    Rob Landers
    @withinboredom
    Rhys Bartels-Waller
    @rhyslbw

    The project @DominikGuzei and I are working on uses meteor apps and a node microservice too. The meteor-space apps are inpendant but have integration points, which is why we feel it would be a natural fit for space-messaging to provide a lightweight distributed solution.

    We’re using https://github.com/vsivsi/meteor-job-collection as it’s much more powerful and is built to suit to exact purpose of running node workers. I did look at meteor-workers when doing reasearch a while back, but I heard Ry Walker of Differential discuss the project on a podcast, and he mentioned it was practically abandoned. Job Collection on the other hand is one of the most solid projects on the other hand, being actively developed, well maintained documentation, a comprehensive test suite, and support from the author.

    Rob Landers
    @withinboredom
    Thanks for that, would have never known it was abandoned!
    Is there any documentation for space-messaging? Like what features it has?
    I'd love to help with documenting various components, would help me learn it and benefit everyone.
    Rhys Bartels-Waller
    @rhyslbw
    Documentation is a bit thin, but test coverage not, so that’s the best way to understand it right now
    But yes documentation is the biggest limiting factor for attracting new people to the project IMO
    We discussed the best way is to focus documentation here: https://github.com/CodeAdventure/meteor-space/blob/master/README.md, then link out to more detailed docs for the sub-projects
    Rhys Bartels-Waller
    @rhyslbw
    …and as you can see there’s no content on messaging there yet
    Rhys Bartels-Waller
    @rhyslbw
    the functionality was actually first part of the cqrs package, but since it’s not specific to that and is used by space-ui, was broken out. This seems to indicate why it wasn’t included in the main docs, but is very much a natural fit with the other intro content
    Rob Landers
    @withinboredom
    May be helpful to use the full stack in a "todo" app or something.
    Rob Landers
    @withinboredom
    best quote ever: If you don't use some structure, you will end up throwing your laptop against the wall. btw
    Rhys Bartels-Waller
    @rhyslbw
    yes haha, been there
    The example is a but out of date with current thinking though. It still uses mediators whereas we’re now using Blaze Components instead
    The Todo app is also not complex enough to demonstrate the cqrs package capabilities, so we really need to put togethe an example from a more complex domain
    Rhys Bartels-Waller
    @rhyslbw
    That example could include the distributed messaging capabilities
    Rhys Bartels-Waller
    @rhyslbw
    To clarifty the example I posted, in a CQRS app you would want to be passing a command to the commandBus instead of updating the collection here. The command is constructed on the client and passed as a serialsed, type-checked object. A handler in the domain layer handles the command, loading up the aggregate, and calling it’s method.
    # Somewhere on client
    Space.messaging.Api.call MyCommand
    class @MyApi extends Space.messaging.Api
    
    @method MyCommand, (context, command) ->
        @commandBus.send command
    class @MyAggregateHandler extends Space.messaging.Controller
    
      Dependencies:
        repository: ‘Space.cqrs.Repository’
    ...
      @handle MyCommand, (command) ->
        aggregate = @repository.find MyAggregate, command.aggregateId
        aggregate.doSomething(command)
        @repository.save aggregate
    Dominik Guzei
    @DominikGuzei
    Hey @withinboredom, welcome – sorry for the silence, was hooked up with a lot of different work lately ;-)
    space-messaging is very badly documented at the moment, but i will be putting something together asap! For starters you can also take a look at two of my blog posts that cover a bit of the ground and philosophy behind the whole space framework: