Understanding the architecture better

Questions
,
1

G-d willing

Hello,
I would like to know more about the components that make Daml complete. I have several questions since not everything adds up for me when I am trying to understand the exact flow when a specific request comes in from the front end.
First, in the documentation, there are mentions of the Ledger API and the gRPC Ledger API. Are they the same thing, or are they different components?
To my understanding, the participant node is an HTTP server that receives requests. Must the participant node be installed where the DAR files are, so the DAR files will be local to it? (According to the architecture diagram I understand that the DAR files are part of the participant node).
What exactly does the participant node do when a request arrives? Let’s say a request to create a contract comes in… How does the request flow between the different components in Daml? Can someone answer that by detailing the specific components and the way they communicate between themselves?

I am aware of the Daml Application Architecture, that architecture is quite a high level in some places, and I do want to know more about it.

According to the explanation about participant nodes in here, it stores the portion of the ledger for the relevant parties it hosts. So in this case, what is the Daml network exactly?

Thanks,

1 Like
2

I strongly recommend splitting multiple questions to separate threads. In that spirit I’ll address one of these:

In a sense, but not the “they must be on local disk” sense. Instead, the ledger API provides mechanisms for package management; packages that have not been registered with a participant in this way simply cannot be used in transactions, because it is impossible to interpret a Daml command without having all referenced Daml packages and their dependencies available. So the “file on disk” DAR is completely irrelevant; what matters is that it has been uploaded to the participant (and perhaps “vetted”).