G-d willing
Hello,
I can’t seem to fully understand what exactly is a participant node. Is it hardware based, a software which the ledger API speaks to? Or is it a combination of the two?
G-d willing
Hello,
I can’t seem to fully understand what exactly is a participant node. Is it hardware based, a software which the ledger API speaks to? Or is it a combination of the two?
Hi @cohen.avraham and welcome to the Daml developer forum
In short, a participant node exposes the Ledger API that in turn talks to the underlying database or a network. You need to set up infrastructure (hardware) for it to run on.
Does this help?
Hi @nemanja, thanks for your quick reply .
So how does it work along with the JSON API?
According to my understanding, the JSON API and the Ledger API are physically installed on the same server. (Or maybe it isn’t?) So why is the Ledger API needed to be exposed to the JSON API by this “participant node”? Why can’t it speak directly to it?
I understand that technically the JSON API is not required in a solution, and I actually can implement my own layer which will speak directly to the Ledger API. So does it mean that the Ledger API cannot be accessed directly by users? Which means that the participant node is a software layer which does all the communication for us with the Ledger API?
Hi @cohen.avraham,
You can access the Ledger API in different ways, JSON API being one of them. From the docs:
You can access the Ledger API via the HTTP JSON API, Java bindings, Scala bindings or gRPC. In all cases, the Ledger API exposes the same services
Note that Scala bindings will soon be deprecated.
So does a Participant Node is basically the physical server in which the Ledger API is installed on?
Spot on
Thank you very much @nemanja
To clarify a bit: “participant node” is anything that exposes the gRPC Ledger API. From a client perspective, it’s basically an IP address, a port, and a promise that we can make a gRPC connection to it and expect it to understand the messages defined by the Ledger API spec.
There are many different implementations that could be the server behind that IP & port, and “participant node” is the generic term for them.
The JSON API is a normal (gRPC) Ledger API client. It is not special in any way; anyone could have written it, it can run on a separate server, etc. It happens to be a component we provide because it seemed to fit a relatively common use-case, but ultimately it’s not part of the core ledger model and it’s not more special than any application you would write against the (gRPC) Ledger API.
You could imagine a setup where the JSON API runs on the same server (or within the same internal network) as the (gRPC) Ledger API, and where the JSON API is the only one exposed “outside” that server/internal network. That’s a valid choice, though one in which you should remember that the JSON API does not expose the full power of the Ledger API, so clients that are forced to only go through it will be somewhat restricted in what they can do.
Thank you very much @Gary_Verhaegen for your detailed explanation.