Strategy for creating DamlLedgerClient in backend application

Hey everyone!

I’m developing a backend application in Scala, for listening to the TransactionService from the Ledger API.
The application allows to add Parties during the runtime, what will result in a new subscription to the ledger, so each party will have its own subscription.
At first I was developing against daml sandbox without any authentication enabled, so I created one DamlLedgerClient for the whole application, so whenever a Party is added, I use ledgerClient.getTransactionsClient.getTransactions(...) and it works like a charm :slight_smile:

Then I enabled authentication, and I specify an access token for each party when using the ledgerClient.getTransactionsClient.getTransactions(..., accessToken), and now the problem I’m having is that I cannot connect to the ledger, because I don’t pass any access token when creating the DamlLedgerClient.

My question is what is the target pattern for using DamlLedgerClient when I need to have subscriptions for multiple parties? Should I create a client per Party? Maybe there is a way to connect to the daml without the token, and then the one from getTransactions(accessToken) will be enough?

Thanks, Grzegorz.

1 Like

Note that connecting to a ledger also requires a token, since upon connection the client issues a first call to retrieve the ledger identifier (so that you don’t have to provide it in all subsequent calls, which is required by the raw Ledger API), so you need to also provide the token as part of building the DamlLedgerClient, either by using the DamlLedgerClient.Bulder to progressively construct your client and calling the withAccessToken method to add the access token to your calls (Javadoc).

The way I would build it would be to model each party as an independent actor and reflect this in code by having a client for each party you need to have in your application. This also simplifies identity management, since you don’t need to have a token allowing a single actor in your system perform on behalf of many different parties.

(I mentioned “actors” as a term to refer to some entity that takes an action, nothing to do with the actor model)

2 Likes

Ok, I’ll create a client for each party. Thanks for the answer.

1 Like