Home
MERLin' is a reactive framework that aims to simplify the adoption of an event-driven architecture within an iOS app. It emphasises the concept of modularity, promoting an easy to implement communication channel to deliver events from producers to listeners.
When a greenfield app is started, the analysis of its complexity drives the team to choose one, among the many possible architectural design pattern to build each feature. Being consistent, when development continues, your choice might result overengineered for some feature, or not good enough for more complex ones.
It's quite common to see apps built in VIPER where presenters are simply proxying the interactors. It's also common to see MVVM applications where the ViewModel is doing too much. Having each feature contained in a module, architectural choices might vary. They are developed in isolation and the architecture can be tailored for the complexity of the specific feature. MERLin is what makes possible to mix and match these modules like Lego bricks taking advantage of the loose coupling typical of an event-driven architecture, but without compromising type safety.
In MERLin a Module is a framework that exposes a specific functionality; an app feature. It’s independent or it has very limited dependencies, It should not know about other modules and does not expose implementation details. Any module can be a producer of events of a specific type and it must be contextualised (it needs a context to be built).
An Event is a message sent by a system to notify of a change happened in its domain. They are named and unique within the same system domain and can have payloads describing the change that happened in the domain.
Different systems offering the same service will emit the same events.
In MERLin, Modules can be events producer and emit events to signal a change of state or that an action was started/finished.
In MERLin, events are enums conforming the EventProtocol protocol.
Some events might cause routing to another module of the app. The Router is the object that makes the connection possible in terms of UI.
In an event-driven architecture, events consumer are listening for events coming from events producers.
In MERLin an events consumer is called Events Listener.
An events listener reacts to a module’s events; It can listen to specific types of events, or to any event. Some events listener can produce routing, in that case, we will call them Routing Events Listeners. These special listeners have a router to make routing to new modules possible.
Each listener should have only one responsibility. There is no limit to the number of listeners that can be listening to a specific module event channel, so it is possible to have a specific listener for each analytics provider, for each module.
I must say that all of this was not possible without my team. They gave me trust, patience, they helped me identifying weak spots in this framework, repetitive tasks and gave me crucial feedbacks and suggestions to take MERLin' at today's state. I've been very lucky as each one of my team members if they spot a problem usually present it along with a possible solution, rather than just complain about it. This attitude made the Team Gaudì the best team I've worked with.
I started MERLin' alone, I might have written most of the code but really, it's teamwork.
Chris La Pat, Fabio Felici, Nikita Korchagin, Niloy Chakraborty (in alphabetic order), thank you.