github.com/kaleido-io/firefly@v0.0.0-20210622132723-8b4b6aacb971/docs/architecture/plugin_architecture.md (about)

     1  ---
     2  layout: default
     3  title: Plugin Architecture
     4  parent: Architecture
     5  nav_order: 4
     6  ---
     7  
     8  # Plugin Architecture
     9  {: .no_toc }
    10  
    11  ## Table of contents
    12  {: .no_toc .text-delta }
    13  
    14  1. TOC
    15  {:toc}
    16  
    17  ---
    18  
    19  ## Overview
    20  
    21  ![FireFly Plugin Architecture](../images/firefly_plugin_architecture.jpg "FireFly Plugin Architecture")
    22  
    23  The FireFly node is built for extensibility, with separate pluggable runtimes orchestrated into a common API for developers.  The mechanics of that 
    24  pluggability for developers of new connectors is explained below:
    25  
    26  This architecture is designed to provide separations of concerns to account for:
    27  - Differences in code language for the low-level connection to a backend (Java for Corda for example)
    28  - Differences in transports, particularly for delivery of events:
    29    - Between FireFly Core and the Connector
    30      - Different transports other than HTTPS/WebSockets (GRPC etc.), and different wire protocols (socket.io, etc.)
    31    - Between the Connector and the underlying Infrastructure Runtime
    32       - Often this is heavy lifting engineering within the connector
    33  - Differences in High Availability (HA) / Scale architectures
    34     - Between FireFly Core, and the Connector
    35       - Often for event management, and active/passive connector runtime is sufficient
    36     - Between the Connector and the Infrastructure Runtime
    37       - 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
    38  
    39  ## FireFly Core
    40  
    41  - Golang
    42  - N-way scalable cluster
    43    - Database is also pluggable via this architecture
    44  - No long lived in-memory processing
    45    - All micro-batching must be recoverable
    46  - Driven by single configuration set
    47    - Viper semantics - file, env var, cmdline flags
    48  
    49  ## Plugin for Connector
    50  
    51  - Golang
    52  - Statically compiled in support at runtime
    53    - Go dynamic plugin support too immature
    54  - Must be 100% FLOSS code (no GPL/LGPL etc.)
    55  - Contributed via PR to FF Core
    56  - Intended to be lightweight binding/mapping
    57  - Must adhere to FF Core Coding Standards
    58  - Scrutiny on addition of new frameworks/transports
    59  
    60  ## Connector
    61  
    62  - Node.js / Java / Golang, etc.
    63  - Runs/scales independently from FF core
    64  - Coded in any language, OSS or proprietary
    65  - One runtime or multiple
    66  - HA model can be active/passive or active/active
    67  - Expectation is all plugins need a connector
    68    - Some exceptions exist (e.g. database plugin)
    69  
    70  ## Infrastructure Runtime
    71  
    72  - Besu, Quorum, Corda, Fabric, IPFS, Kafka, etc.
    73  - Runs/scales independently from FF Core 
    74  - Coded in any language, OSS or proprietary 
    75  - Not specific to FireFly
    76  - HA model can be active/passive or active/active