Plugin Architecture

[peterbroadhurst]

See #4 for info on why this is in Git

FireFly Three Layered Plugin Architecture

In #6 the extensible nature of the FireFly node is described, with separate pluggable runtimes orchestrated into a common API for developers.

Here the mechanic of that pluggability for developers of new connectors is explained:

This architecture is designed to provide separations of concerns to account for:

• Differences in code language for the low-level connection to a backend (Java for Corda for example)
• Differences in transports, particularly for delivery of events:
  • Between FireFly Core and the Connector
    • Different transports other than HTTPS/WebSockets (GRPC etc.), and different wire protocols (socket.io, etc.)
  • Between the Connector and the underlying Infrastructure Runtime
    • Often this is heavy lifting engineering within the connector
• Differences in High Availability (HA) / Scale architectures
  • Between FireFly Core, and the Connector
    • Often for event management, and active/passive connector runtime is sufficient
  • Between the Connector and the Infrastructure Runtime
    • The infrastructure runtimes have all kinds of variation here... think of the potential landscape here from PostreSQL through Besu/Fabric/Corda, to Hyperledger Avalon and even Main-net ethereum