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.
# 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
space-cqrsis not a good fit for the ORM based orionjs solution anyway. But we sparked the idea of building a good example application that shows the concepts and benefits of DDD / CQRS with space-cqrs
payments) that could be dropped into your application and configured. This would provide great examples of how to model a self-contained bounded context and possibly draw more attention to space (get more devs on board).
package.jsis programmable in Meteor we can use environment vars to include only those value objects that are needed by modules / apps.
environment.sh. Then run the app via the