Lesson 7: Daml Application Modularity

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

1. 0:00

   making your application modular is a critical step towards long-term maintainability and upgradability of your code there are several types of files in a typical demo project for example a project has packages that have modules which then have interfaces templates scripts and so on as your project grows you need to know how to structure all these components inside a project this lesson will discuss the structuring of packages and the related build files

2. 0:31

   to make your project modular smart contracts are developed in projects which you specify via daml.eml project files each project compiles to a single primary package which is bundled with all its binary dependencies and some meta information that bundle is called a Dar file which stands for demo archive file a Dar contains one or more packages if a Dar contains more than one package one of them is assigned to be a primary

3. 1:03

   package every Dar file is closed under dependencies so if your Dar contains package x and x depends on why then Y is also contained in the package a package contains one or more modules and a module contains one or more templates interfaces test scripts setup scripts or triggers a Dar is essentially a compiled package the difference between a simple folder and a package is that a package has its own project config file called

4. 1:36

   damil.yaml the yaml file specifies all that is required to compile the files in a package into a dar deploying an application on Canton Network requires deploying these Dar files on participant nodes you want to put only those templates in a Dar that are relevant for the parties hosted on a participant node that means you must think carefully about what goes in each dar you do not want to bundle everything in one Dart to make one monolithic

5. 2:07

   application you should make your packages as modular as possible by breaking down dependencies you need a packaging structure to gain three key benefits of modularity first is the separation of concerns you can keep the unrelated code of your application separated from each other to minimize dependencies for example test scripts should be kept in their own package since they should not be deployed in a production environment similarly triggers should be kept in a

6. 2:40

   separate package the second benefit is the ability to independently upgrade each component without impacting other components for example you can upgrade template A1 recompile package P1 into a new Dar and deploy that Dar without impacting other Dar files third is the ability to reuse packages across multiple DARS if for example triggers in package P3 need to use template A1 from package P1 then the demo.yaml in P3 must declare this

7. 3:14

   dependency that will allow modules from P1 to be imported into the code written inside triggers module let us take a look at the structure of files in the wallet sample lab project this is a reference app created specifically for learners its source code along with a detailed readme file is available at the get repo shown here you can clone this repo and explore its structure as you follow this lesson the project root is the folder wallet sample app there are several folders

8. 3:48

   inside the root and the folders of Interest are main triggers and UI inside main there are five folders account asset setup tests and users notice that each of them has a demo.eml file which indicates that each of them will be a package which gets compiled into a dar when a package is compiled into a Dar it receives a unique package ID which is a hash of the code bundled in it if you change anything in this package

9. 4:20

   and rebuild it it will get a new package ID let us now look at demo.yaml in the account package and first look at the blocks marked as dependencies and data dependencies the dependencies block lists the packages from other demo projects that need to be imported into this project an important limitation of these dependencies is that they should be built from the same SDK version as the importing project the top of the code section shows that

10. 4:51

    the SDK version is 2.5.3 which means that the three dependencies listed in the dependencies block should also be built using the same SDK version this applies not only to the three packages listed here but all the packages that these three packages May in turn depend on as well as the entire dependency tree if you want to import a package from a different version of SDK you can use data dependencies because of this flexibility data dependencies are more

11. 5:26

    often used when performing demo model upgrades this example shows that the David dependencies lists the asset dot Dar package under the asset folder as a dependency this means that for the account package to function the code from asset package should be compiled and available as asset.dar the demo.eml file in the setup package contains three data dependencies indicating that all three DARS should be available before the setup package can be built now that you have reviewed the package

12. 6:01

    structure let us see how to create their Dar files to create the DAR files follow the instructions provided in the readme of the wallet sample app repo as you do that observe five Dar files created for account asset setup user and triggers since the test package is not to be deployed the make script does not create its Dar file the wallet app has been designed as a single node application and can be run from a Canton sandbox hosted locally or it can be uploaded

13. 6:34

    onto demo Hub along with its UI components you can find out more about the steps to do that in the readme provided in the repo let us summarize demo provides a hierarchical structure to organize your demo application project files you can organize your code in packages by putting them in folders along with a demo.yaml file that is a project config file among other things a demo.eml file

14. 7:04

    contains the SDK version used for creating the DAR package name and its version and package dependencies there are two types of package dependencies the first are those listed under the dependencies Block in demo.yaml they are compiled with the same version as the SDK version of the package being built the second type are those packages listed under data dependencies they may be built from different SDK versions once the DAR files are built they can be

15. 7:37

    uploaded onto participant nodes on the Canton Network or on demo hub