Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node Component Architecture - Periodic Table of Elements #6

Open
peterbroadhurst opened this issue May 14, 2021 · 0 comments
Open

Node Component Architecture - Periodic Table of Elements #6

peterbroadhurst opened this issue May 14, 2021 · 0 comments
Assignees

Comments

@peterbroadhurst
Copy link
Contributor

peterbroadhurst commented May 14, 2021

See #4 for info on why this is in Git

What is a FireFly Node?

The Firefly Node

There are three zoom levels of this question, where the architecture matters:

  1. What fundamentally is a node - left on the picture
    • It is a multiple runtimes with a single unified HTTPS/Websocket API (exposed by the Core)
    • It has a private database, containing your private data, and data received from others in the network
    • It has connectivity out to other parties in the network, through runtimes (Blockchain, Shared Filesystems, Messaging etc.)
  2. What are the core runtime responsibilities, and pluggable elements - right on the picture
    • The core elements of function that FireFly performs, and which runtime is responsible
    • This means some insight into core itself, and the jobs it performs, but not full code structure
    • More importantly, what the split of responsibilities is between Connectors and Infrastructure Runtimes
      • Connectors are the bridging runtimes, that know how to talk to a particular runtime.
        • They run separately to the core (like a microservice architecture of an app)
        • They can be written in any language (not just Go) - Java, TypeScript, Rust, Python, .NET etc.
        • They can use any network transport (not just HTTPS/Websockets) - GRPC, AMQP, UDP etc.
        • They connect to the core with a Golang shim - see separate Plugin Architecture discussion
          • In some special cases (like the Database) the Golang shim does not need a connector runtime
      • Infrastructure Runtimes are the core runtimes for multi-party system activities
        • Blockchain nodes - Ethereum (Hyperledger Besu, Quorum, Geth), Hyperledger Fabric, Corda etc.
        • Public strorage - IPFS etc.
        • Database - PostreSQL, CouchDB etc.
        • etc.
  3. What is the code structure inside the core
  • The README.md is the reference for this
  • Developers contributing to FireFly, on the core, or building new plugins, need this level of detail
  • A reconciliation is underway to ensure the medium-level view correlates well with this code structure
awrichar pushed a commit that referenced this issue Jun 7, 2021
Allow gatewayEndpoint to be separate to API endpoint on IPFS

Signed-off-by: Peter Broadhurst <peter.broadhurst@kaleido.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants