Messaging | The flexible dart/flutter event sourcing package that you need

When you build your dart application (and so your flutter application), one of the main thing you think about is State Management (or Components communication) and for that you adopt one design pattern that fit it. The most used design patterns in those cases are MVC (Model View Controller) or MVVM (Model View ViewModel). Both are excellent for component communication and state management especially if the presentation layer of your application represent a big part of it. But these design patterns have a flaw where your components are highly dependant or linked together and are mostly related to the presentation layer and not the whole application and probably your business logic.

For example in the MVVM design pattern, the ViewModel interacts with the view by providing data for this view and executing specific available commands sent by it but your whole application is probably not only this viewmodel and this view. There are probably anothers operations that must be made depending on some actions or any external invokations. To face these cases, you have to rely on another layer, mainly the domain layer where your business logic lies. But there, there’s no more a ViewModel to handle command sent by the View, there’s a bunch of services that handle your logic and communicates with others components.

In a simple system using only MVC or MVVM patterns, your ViewModels, your Views and your services (or generally your components) are highly coupled. For each interactions, you must know all components that must be called or used, your components are absolutely not independant. They cannot have their own life or removed at anytime without breaking your whole application. They cannot be maintain, refactored or improved without thinking of the impact in the whole application, which is not that bad but make your whole highly dependant of one component. To solve this, there are anothers patterns that can be used:

• Microservices
• Event-driven architecture

Both are used to seperates concerns and fit well for scalabitlity, maintenance and performance. The components used here are totally not dependant from each other or directly connected. This allowing to add, update or remove one without affecting your whole application.

To address this case in application, the components must be connected to central part that acts like a broker or a bus etc and allows components to inform and be informed from specific action, event or message.

So this central part must receive messages from some components and send them to others components and there comes the package messaging.

This package implements the Messaging design pattern allowing to:

• Publish one or many messages
• Subscribe/Unsubscribe to one or many messages
• Priority queue
• Store messages to restore them and publish they was not fully published before the application shutdown
• Filter messages to allow and block depending on some conditions
• Observe the lifecycle of a message to be inform at any stage.

Its use is quite simple. You create an instance like

Instantiation of messaging

Then with your message

Message that will be published

And your subscriber

Subscriber implementation

You use them like

You can go even further by totally customizing the queue and the store used by the package to use one that fit your application. The level of customization and flexibitlity is high and allows you to use it in many cases. Feel free to read the documentation in the package page.