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

     1  ---
     2  layout: default
     3  title: Node Component Architecture
     4  parent: Architecture
     5  nav_order: 1
     6  ---
     7  
     8  # Node Component Architecture
     9  {: .no_toc }
    10  
    11  ## Table of contents
    12  {: .no_toc .text-delta }
    13  
    14  1. TOC
    15  {:toc}
    16  
    17  ---
    18  
    19  ## What is a FireFly Node?
    20  
    21  The core architecture of a FireFly node can be broken down into the following three areas:
    22  
    23  * The various runtimes encapsulating the node.
    24  * The core runtime responsibilities and pluggable elements.
    25  * The actual code running inside the node.
    26  
    27  ![Node Component Architecture](../images/firefly_node.png "Periodic Table of Elements")
    28  
    29  ## Runtimes
    30  
    31  What fundamentally *is* a node - left side of the above diagram.
    32  
    33  * It is a collection of multiple runtimes with a single unified HTTPS/Websocket API (exposed by the Core).
    34  * It has a private database, containing your private data, and data received from others in the network.
    35  * It has connectivity out to other parties in the network, through runtimes (Blockchain, Shared Filesystems, Messaging etc.).
    36  
    37  ## Responsibilities & Pluggable Elements
    38  
    39  What are the core runtime responsibilities, and pluggable elements - right side of the above diagram.
    40  
    41  - The core elements of function that FireFly performs, and which runtime is responsible.
    42     - This means some insight into core itself, and the jobs it performs, but not full code structure.
    43     - More importantly, what the split of responsibilities is between `Connectors` and `Infrastructure Runtimes`.
    44        - `Connectors` are the bridging runtimes, that know how to talk to a particular runtime.
    45            - They run separately to the core (like a microservice architecture of an app).
    46            - They can be written in any language (not just Go) - Java, TypeScript, Rust, Python, .NET etc.
    47            - They can use any network transport (not just HTTPS/Websockets) - GRPC, AMQP, UDP etc.
    48            - They connect to the core with a Golang shim - see separate _Plugin Architecture_ discussion.
    49              > - In some special cases (like the Database) the Golang shim does not need a connector runtime.
    50        - `Infrastructure Runtimes` are the core runtimes for multi-party system activities.
    51           - Blockchain nodes - Ethereum (Hyperledger Besu, Quorum, Geth), Hyperledger Fabric, Corda etc.
    52           - Public strorage - IPFS etc.
    53           - Database - PostreSQL, CouchDB etc.
    54  
    55  ## Code Structure
    56  
    57  What is the code structure *inside* the core.
    58    - The [README.md](https://github.com/hyperledger-labs/firefly#readme) is the reference for this.
    59    - Developers contributing to FireFly, on the core, or building new plugins, need this level of detail.
    60    > - A reconciliation is underway to ensure the medium-level view correlates well with this code structure.