Lesson 2: Daml Application Architecture

Captions as YouTube publishes them, usually machine-generated, so names such as Daml and Canton can be misheard.

1. 0:03

   in the previous lesson we learned about the infrastructure that a DL application runs on which includes Canton participant nodes and a synchronizer and the benefits with respect to non-repudiation and data sovereignty that these provide in this lesson we're going to look at the various components that need to be built and operated for a functional DL application we're going to learn what components a DL app typically consists of and how to decide on the component

2. 0:33

   architecture for your application as an architect of a DL solution you represent the app provider organization when we discuss the costs and benefits of various architectural options we consider them primarily from the app providers perspective although in some cases we also mention the costs and benefits for the app user organization your app typically requires these three kinds of components D models

3. 1:03

   app backends and app front ends which we will explain in turn the D models Define the Cross organization workflows and serve as an API definition for the components interacting with these workflows they are compiled into Dar files also known as DL packages these St files need to be uploaded to all Canton participant notes of your app app users the backends sit directly on top of the Ledger API and manage access to participant noes the backends utilize damel parties

4. 1:41

   representing the app provider and the app users and damel contracts to represent the state of the workflows between these organizations damel parties act on The Ledger and read from The Ledger at the level of an organization note that even though the diagram depicts the backend as single box it does not have to be implemented as a single monolithic component it's a logical component that can be implemented using a microservices architecture or any other service architecture preferred by the

5. 2:14

   development team the backends typically serve one or more of the following purposes to automate on Ledger workflows steps in on Ledger workflows that do not require human intervention are automated using the backend for example in a customer onboarding workflow of a financial services app the backend might listen to a new customer onboarding request on Ledger and Advance it automatically once the provider's off Ledger know your customer or kyc

6. 2:47

   compliance system gave the green light to onboard the customer to integrate with off Ledger systems for example running off Ledger anti-money laundering compliance checks or populating report reporting databases while processing on Ledger Financial transactions or initiating on Ledger Financial transactions from an off lger pre-trade analytics system it is crucial to understand the specific integration needs of your app users as well as the app provider

7. 3:17

   organization and put the backend infrastructure in place to serve these to provision higher level apis the participant nodes ensure that all your applications data is synch ized in real time across organizations however front ends and other systems often need to run particular queries over this data the backend's job is to serve these queries from application specific apis with appropriate access control and

8. 3:47

   performance characteristics it is important to implement these queries in a way that scales to your application needs using the participant query store or pqs with application specific indices is a good option to do it to serve reference data contracts a special case of provisioning a higher level API is to serve reference data contracts required by app users to submit their D transactions sometimes daml models include contracts that provide reference

9. 4:21

   data for example an app provider May store a directory of eligible counterparties for over-the-counter trades as on lger contracts another example is financial Market data such as a stock index closing value foreign exchange or interest rate fixing provided by an oracle party and stored as an on Ledger contract such contracts are typically not visible to the app users DL parties because maintaining their visibility on

10. 4:50

    ledger to app users parties is honorous and because contracts with many observers should be avoided for performance reasons in instead of managing the visibility of such contracts on Ledger a daml feature named explicit disclosure is utilized this feature allows the stakeholders of a contract to share it out of bounds with other parties so that these parties can include the contract with a damel transaction submission which in turn allows the submitting parties to access these contracts during

11. 5:23

    DL transaction processing with explicit disclosure a transaction that requires the submitting party to have visibility of a contract will succeed even though the submitting party is not a stakeholder on the contract front ends Empower human end users to efficiently interact with the business process of your app apps that purely serve as systemto system integration Solutions might not need a front end all other apps will need app front

12. 5:54

    ends to achieve non-repudiation it is key that all actions taken by an end user in the name of an app provider or an app user organization are submitted via that organization's participant node from a front end under their control otherwise the organization could always dispute a transaction record claiming that it doesn't correspond to the actions performed by the end user the app provider and each app user should thus serve the app front end from

13. 6:25

    a web server under their control to achieve the best possible non repudiation guarantees for the same reason each organization's front end should be configured to log in VIA that organization's IM am the IM will issue access tokens that can be used to submit commands to the organization's participant node there's no one size fits all architecture for DL apps instead there's a Continuum of possible architectures your role as a technical

14. 6:57

    solution architect is to consider the pros and cons of each architectural choice and to arrive at the architecture that provides the most suitable trade-offs for your case to be able to discuss the tradeoffs let's consider three distinct architectures the first is the architecture with the fewest components to build where app users only operate the front ends and only the app provider operates the back end on the opposite end of the spectrum

15. 7:27

    lies the most flexible architecture where each organization builds and operates its own front end and back end and in between these two architectures will consider the one where the app users operate the front ends and the backends built for them by the app provider when only the app provider operates the backend app users front ends submit commands to The Ledger using Ledger API or HTTP Json API to read from The Ledger app us

16. 7:59

    user's front end uses app providers backend this architecture is the easiest to deploy and it's still provides non-repudiation and self- sovereignty of app data for app provider and app users however it doesn't allow integration with app users Off lger Systems and it limits the possibilities for automating on lger workflows in this architecture the backend can only submit commands to The Ledger on behalf of app providers Danel

17. 8:31

    parties app users DL parties can only send commands to The Ledger through the front end the next architecture is where app users operate the front end and the backend built for them by the app provider when the app users operate the app backends built by the app provider the app users gain the following benefits in addition to non- repudiation and self- sovereignty over app data that they get from operating a participant node self- Sovereign queries over app

18. 9:02

    data app users can rely on queries over their app data to be served by their own backends that are fed from their own copy of their app data whether this is a requirement for your app depends on your use case it might for example be required for app users that make very high stakes decisions in a low trust environment it might also be required for app users that must strongly control all their decision making infrastructure for compliance reasons app user system

19. 9:34

    integration if an app user needs to integrate their actions in the app with Off lger Systems under their control then they need to operate a local backend serving as a bridge between these systems and the application batched access to contended resources if there are many end users that access the same on Ledger resource owned by the app user then a backend might be required to batch access to that resource to provide higher throughput for example there

20. 10:04

    might be many traders that are allowed to allocate funds out of a company's on Ledger account a local backend allows app user to batch the trader requests and submit a single DL transaction that serves a 100 allocation requests in one go which results in an 80 to 100 times increase in speed compared to serving these allocation requests one after the other other fine grained and user permission management app users might require fine grained access control for

21. 10:37

    their end users with respect to reading on Ledger data and acting on Ledger using the damel parties that represent the app users organizations this is best implemented using a backend that controls access to the app users participant node and the damel parties hosted there the disadvantages of app users operating the backend built by the app provider include app user operating costs the app users need operating staff that take

22. 11:07

    care of monitoring and maintaining their backend multiversion deployments some app users will likely be slow to upgrade their app backend to a new release which means that multiple versions of the backend code will be running at the same time this makes it hard to change your app workflows and to test that upgrades will work as expected when the app provider develops the backend to be operated by the app users the app provider becomes a provider of

23. 11:38

    on-prem software which comes with the challenge of requiring app provider support staff the app provider needs to run a client facing support team to handle problems with backend operations during the app users business hours app provider release management the app provider needs to release software to customers for their operations on Prem managing these external releases requires extra communication and Care compared to managing app providers

24. 12:09

    internal releases finally the architecture where each organization builds and operates its own app front end and backend provides the most flexibility in implementing each organization's requirements for Automation and integration with Off lger Systems however this flexibility has a cost app users that not only operate their own backends but also build their own backends and or front ends gain additional benefits

25. 12:42

    customization the app user can build the app backend end or front end exactly to their needs one reason for that might be the need for custom system Integrations or custom F grained and user access controls lower software supply chain risk compared to running an app backend or front end built by the app provider or a third party this may be required in case the necessary audits of the third-party code are too expensive the disadvantages of the most

26. 13:13

    flexible architecture include app user software development cost the app provider always needs to build and operate its own front end and back end app users on the other hand may not need to when app app users build their own front end and backend they need budget and expertise for developing and maintaining their frontend and backend code requiring app users to develop their frontend and backend can thus severely limit the total addressable

27. 13:45

    Market of your app Cross organization software development both the initial development of your app and future changes require coordination across the app provider and app user organizations daml provides a great way to specify the apis of the workflows across organizations however the challenge of Cross organization software development should not be underestimated restricted app Evolution you should expect the app to evolve over time to cater for new

28. 14:19

    business requirements however app users may not be inclined to or capable of changing their front end and backend code which makes it hard to change change or decommission existing workflows this table summarizes the properties of each of the three architectures we considered remember that there's a Continuum of possible architectures in between app architecture can also evolve over time you may start with a simpler architecture that gives you the minimum

29. 14:51

    required set of properties and add to it later as the business requirements evolve and this table sum mizes the properties of the same three architectures from the perspective of cost and other software engineering concerns our recommendation is to favor the architecture that requires the least engineering and operations effort from your app users while satisfying their requirements a damel app typically requires three kinds of

30. 15:22

    components damel models app backends and app front ends Dam models need to be deployed on the app providers and each app users's participant node there are options for Who develops and operates the app backends and front ends and the architecture of the app can evolve over time we recommend to initially favor the architecture that requires the least software engineering and operations effort from your app users while satisfying their requirements this

31. 15:55

    allows to minimize the delivery risk and maximize the total addressable market for your app