Welcome to PlatformHub

Welcome PlatformHub!

The aim of this project is to connect plugins (libraries/frameworks) together in a plug and play manner, allowing us to add and remove plugins to our apps without the need for large code refactoring. The communication between plugins is done via a very narrow, simple and well defined API in PlatformHub which acts, as its name indicates, as the communication hub of your app.

Support

To assist teams with PlatformHub adoption the TigerBus team was setup to assist you with your questions, problems and blockers. You can reach the team via email #TigerBusTeam or alternatively via creating a front door ticket under this confluence page. If you choose the latter, the team will setup a meeting with you to discuss your adoption needs. Email requests are well suited for short quick clarifications. If you have however more questions or questions that are complex in nature it is recommended to choose the latter approach. There is also the Mobile Clinic which is scheduled every Tuesday where PlatformHub related questions can be raised; please send us an email if you would like to receive an invitation to this meeting.

What problems are we trying to solve?

There is a demand to converge more apps into Global X but the current implementation doesn't scale quick enough to satisfy this demand. The new platform, with PlatformHub at its heart, is meant to change the current architecture to provide a solution that can scale faster and it's easier to maintain.

During the last years, business and technical teams have been facing several problems with Global X. These are some examples of the problems that our new architecture is looking to solve:

• High level of complexity in the Host App to maintain over 30 different entities/apps
• Very difficult to align hundreds of developers across the globe to follow the same principles, standards and architecture
• Monthly release cycle not suitable for all the entities/markets
• High number of issues in the Global code base
• High testing effort required
• Coupling: Dependencies between components/libraries and also with the Host App itself
• Lack of visibility and ownership of each part of the platform
• Slow performance i.e. very slow app launch
• There is no clear Metric/ data of the platform
• Difficulty ensuring code quality when code is being produced 24h a day
• Slow creation of new apps and new functionalities
• Slow and complex process to integrate new functionalities
• High maintenance cost of the platform
• App size

PlatformHub as a solution

PlatformHub is a new framework that enables standardisation across the foundational aspects of the app building, therefore teams can focus on building great user experience for our customers.

The purpose of the new framework is to allow entities using the Global X platform to select and configure only the features required. Currently, there is some level of control with feature toggles and flavours but it is at the expense of code complexity, coupling the frameworks with the Host App and very slow delivery due to the deep implication of code changes. With PlatformHub the coupling is minimal and therefore the code will be more flexible to add, update and remove features without impacting the rest of the app; improving not only our integration times but also the release cycles to our customers.

We will be able to:

• Release on demand
• Reduce the Global X complexity, reducing bugs, increasing testability, readability and decoupling
• High visibility on the platform components allowing us to see what tools are available, team ownership, interaction, app usage and statistics
• Performance test
• World wide code alignment across teams
• Flexibility adding, updating and deleting frameworks (plugins) from an app, resulting in faster response to change and delivery

PlatformHub

PlatformHub is a framework which coordinates communication between plugins, allowing uncoupled messaging between them and the containing app under an event driven architecture.

Components

We will see this in more detail further in this documentation, but here is a high level list of the different components that are part of the PlatformHub's ecosystem:

• Microkernel: Coordinates the initialisation of the app, algorithms sequence and messaging
• MessageDispatcher: Orchestrator of all the communication between plugins, ensuring that each plugin is entitled to send a certain messages and that the receiver gets the message delivered
• MessageSender: PlatformHub component that allows Plugins to send messages to other plugins following the strict channels declared in the MessageSending public protocol
• Message: The struct which contains the name of the message and either the name of the plugin sending the message or the plugin it is directed to (depending on the type of message: Direct Message or Event. More on this here)
• Payload: Data exchanged together with a message. Payloads are JSONObjects instances which essentially encapsulate a JSON payload. If any plugin wants to send any information to another plugin it will have to be with a payload
• EventOutput: Struct which wraps a Result<JSONObject, PluginInternalError> and an optional correlationMessage, used as the type for events and query responses
• PluginInternalError: Error Protocol describing any error which may be returned in an event or in the response to a sent message (in the EventOutput), which can also contain a JSONObject payload, a description and an error code to provide more details of what went wrong
• Plugins: Generally we refer as a plugin to a framework/library which can be used in the PlatformHub ecosystem. But a plugin is also the specific class conforming to PlatformHub's Plugin protocol, whose implementation allows receiving messages from other plugins
• Adapters: Legacy framework whose original public interface has been hidden and wrapped by the new Plugin protocol interface, enabling it to be part of the PlatformHub ecosystem. The adapter translates the pre-existing public interface into the Plugin protocol interface
• Policy: JSON file living inside each plugin which defines basic information like the name and version of the plugin and the interface of messages a plugin will use to communicate with other plugins
• Registration: Process to allocate a unique id to each production ready Plugin. This allows us to have fine control on what plugins are approved to be in a release version of an app

Initialising PlatformHub

PlatformHub as a framework must be imported and initialised by the containing app before any plugins' messages can be sent or received.

• Android

Sending and receiving messages

Plugins must implement the Plugin protocol, enabling them to receive messages sent to them.

PlatformHub itself initialises its own message sender (which conforms to the MessageSending protocol) and it's injected in all the initialised plugins, so that they can send messages through it.

Within the PlatformHub messages, the exchange of information is done through payloads that take the form of JSON and are encapsulated inside JSONObject instances. Using these generic JSONObjects will ensure complete decoupling of interfaces and data.

Decoupling

No plugin has any knowledge of another plugin's data models (Structs, Classes, etc). This translates in no plugin importing any other plugin, only PlatformHub will be allowed to be imported. All a plugin knows is it will fire a message to PlatformHub and eventually it will get a response. PlatformHub is responsible for all the mediation between plugins communications, therefore there is no need for a plugin to import another plugin since they are, and must be, completely decoupled.

Sometimes this would lead us to have to duplicate certain code in different plugins. In a large organisation like is SKYRIN, experience tells us duplication is preferable to coupling different unrelated components to a centralised framework containing an amalgamation of unrelated logic; which in the long term has been proven to be unmaintainable, exponentially complex and source of conflicts that end up slowing us down. There are other technologies in place to achieve similar results (ie: Plugin Configuration files) with less footprint in our code.

"The more reusable something is, the less usable it is" - Neal Ford.

For platforms, what this often means is that a one-size-fits-all solution will end up not solving some of the specific use cases for an individual business unit.

Navigation

In addition to events and commands PlatformHub provides functionality required for navigation between different journeys. It should be used for cross plugin navigation only, internal navigation within a plugin should use the platform specific navigation. All decoupling principles are applied to the navigation capability meaning there is no shared type or shared code. PlatformHub operates on generic view entities (UIViewController / SwiftUI View on iOS or Fragment / Activity / @Composable on aOS) that you can obtain by PlatformHub Navigation (Android) / ViewQuery (iOS) messages.

In the future this iOS navigation mechanism will replace iOS Mobile Navigation Libraries: iOS

Documenting plugin messages and payloads

The plugin's Policy.json file contains all the different messages a plugin will be able to send and receive.

A plugin's documentation should include schemas for the JSONs sent with each message, so that consuming plugins know what is going to be in the JSON payloads. Basically this schemas serve as communication contracts between plugins. In addition, if it is anticipated that PluginInvocationErrors will be thrown where additional information about the error is required, this additional information can be encapsulated in the error description.