Project maintained?

[pada57]

Is this project actively maintained by more than one developer?

What is roadmap plan for this year?

[martinzima]

Hello,

Yes, this project is actively maintained and it is currently used in production projects by our company (although I do most of the pull requests in this repo myself). Regarding the roadmap:

1. Right now, we are working on refactoring the DI container integration to move away from Ninject to the pseudo-standard Microsoft.Extensions.DependencyInjection, allowing users to use DI container of their preference. This will introduce some breaking changes, but it also should make the framework easier to embrace for new developers. :) I expect this update to land by the end of April.
2. The shift from Ninject to Microsoft.Extensions.DependencyInjection will likely also come alongside better support for the minimal ASP.NET Core APIs and easier setup.
3. I plan to publish our MQTT client integration sometime next month.
4. Refactoring the built-in EF Core naming conventions for better customizability. Likely 3rd quarter of this year.
5. I would also like to finally come up with more examples and tutorials and update the docs a bit, but no ETAs there (hopefully later this year).

EDIT: I almost forgot, 6. I really need to set up some integration tests when I get the time.

Besides this, feedback and PRs from the community are always welcome!

[pada57]

Great

Which size is your company? How many Devs and running apps using this framework in production?
Do you know if use by other companies?

Would be great to support Dapr as transport.layer as would open much wider integration like azure, Aws, etc..

Is this framework implementing inbox and outbox pattern? Transactional message publishing with aggregate? Is there support for multiple bulk update aggregates?

What are rules if we contribute?

[martinzima]

Hello, to answer your questions:

• We are a startup company (no more than 10 devs) running our backend stack with Revo. I know about other companies experimenting with the framework, but I have no information about whether they are using it in production or not now.
• I know of Dapr, but I don't know their architecture in detail. What specific integration with Azure/AWS do you have in mind?
• Yes, both the inbox and outbox pattern and transactional message publishing with aggregates is implemented by Revo's asynchronous message queues.
• Yes, you can bulk update aggregates.
• IIRC, when contributing, you have to sign a quite standard CLA basically just agreeing to releasing the contribution under MIT license (same as the framework).

[pada57]

Thanks for your answer, very appearling your third bullet point on inbox/outbox.

my concern is with current framework, i see all your interface and aggregate base class / base identity class take a Guid as unique identifier. If we want to have a long or int, is it possible ?
turn this question in another way, is it a problem if we create complete different custom aggregates, will it still work with rest of the framework : handlers, inbox / outbox , messaging, sagas ... ?

What specific integration with Azure/AWS do you have in mind?

with Dapr integration is a configuration detail as transport layer is abstracted via Dapr API. Current messaging building block is supporting those :
https://docs.dapr.io/reference/components-reference/supported-pubsub/

[martinzima]

Using GUIDs for primary keys is an opinionated design decision that Revo indeed currently enforces for its aggregates. In theory, you could make the framework support other ID types, but it would make the code definitely more convoluted in some places, so I originally decided not to implement this (yet). Please note that this does not prevent you from adding another int key (and perhaps if using DBS like MSSQL, make the table cluster on that column's index instead, if you were worried about performance).

Regarding Dapr, I believe it should be possible to write an integration for Revo for publishing/subcribing messages (similarly to how it now integrates with RabbitMQ via EasyNetQ, for example).