When running Fluree, you are typically running a single 'network' and you have a transactor group configured to operate that network. Each network can have millions of ledgers, and you can think of a network like a top-level domain name, i.e. .com, .net, .org. It is the most coarse type of segmentation available in Fluree.
In Fluree, the role of a server handling queries (query server) is separated from that providing updates (a transactor). This serves several purposes:
Don't Have To Handle All, or Any Transactors
If running your ledgers decentralized, you don't control all the transactors processing updates -- or possibly any. Your apps will require a fast and responsive query engine and by running your own (or Fluree's hosted) query server, you have a dedicated server address you control to issue queries and coordinate transactions you might send it.
Allows Query Servers to Scale Linearly
This design allows your query servers to linearly scale to any query workload. You can add (or remove) servers as needed and have as much speed and redundancy desired where apps typically need it the most - querying. Transactions will in no way affect query performance, and vice versa, because they don't fight for the same resources.
Allows You To Run ledger As a Library
This design opens up the possibility of running your ledger as a library inside your own application (in-process). This has implications of how you code, as you ask for data as needed with results in the order of microseconds, instead of packaging up queries as monolithic requests to send over the wire for responses in the tens, hundreds, or even thousands of milliseconds. Using this pattern, your code becomes simpler, easier to understand, and more efficient.
For framework users, we will be offering a React wrapper and intend to release an Angular wrapper along with others. Reactive extensions can be used, but are essentially rendered redundant and unnecessary by Fluree, which just 'handles it' transparently for you.
The transactor server type handles updates. You can run a single server or set of servers in the role of transactor. If you run a set of transactors as a transactor group, they will act as a single node, as far as consensus is concerned. You can scale transactors in your transactor group as necessary.
If running Fluree in a decentralized manner, you need to choose a consensus algorithm. The consensus algorithm determines how each node in your network agrees upon a series of states (blocks).
The consensus algorithm for a network is specified in each ledger in the
We currently support Raft only, and you can learn more in the Consensus Algorithm section.