This is a question that I hear often when introducing companies and developers to Daml and project:DABL. The story is clear - achieve much more through focusing on your application - but where to begin is not always so straightforward. There are some differences in building applications using Daml that have great returns when done properly.
This post will present an overview of preparing to build a Daml application — and queue up future posts — by looking at major ways your application architecture will be much easier to develop from its predecessors, how you should set it up, and what you can do with it.
It’s Part 1 of an ongoing series on Daml design best practices: “How to Make the Most of the Daml Application Framework.”
How Daml + DABL are different
Put simply, Daml + DABL does a lot for you.
In traditional application stacks, each layer requires a different skill set — and more importantly, a different focus.
UX and application features are contained in the layers most visible to end users. The deeper a development team goes in developing back-end functionality, the more opaque the technology becomes to those users, and the knottier the problems are.
Traditional programming requires a diverse engineering team to create a stack several layers deep. Daml and DABL reduce the number of layers you need to develop, handling much of the functionality itself; you only have to specify a UI at the front end and a Daml application at the back end.
You and your team spends time defining the behavior of the application — never wasting a minute on something your user won’t see. What’s more, any developer can access the application through its APIs without worrying about access to the API layer differing from the services or UI.
The Daml + DABL advantage
So how do these differences empower applications created in Daml and deployed within project:DABL?
Daml
An application built using the strongly typed Daml framework frees developers from the countless hours of tedium wrought by endless boilerplate and the minutiae of gluing together a hodgepodge of disparate components. And it frees the business of the anxiety of supporting a frankenstack with the everpresent tune of ‘but muh tech debt!’ Nevermind the Sisyphean task of hiring more and more engineers of different skills and competencies. All you really wanted to do was build a straightforward CRUD app and deliver some value via the internet.
Using Daml for your back-end code and DABL for your deployment environment allows you to focus on the features and business logic of your application — exclusively. Gone are the days of provisioning; maintaining; and accounting for huge, diverse software and infrastructure stacks.
project:DABL
DABL is a purpose-built cloud environment for Daml applications. When you load your Daml file, your application immediately goes live — ready to scale to your needs — without any complicated infrastructure configuration. That means no wrestling with servers; databases; load balancing; security; authorization; tokens; and many, many other functions your end users just expect to work.
project:DABL simplifies building an application down to writing a set of Daml and React or Typescript files.
Daml and DABL let businesses build lean engineering teams that are 100 percent focused on the value to their users.
Daml architecture in action
To round out this introduction, we’ll introduce four key differentiators that make Daml powerful and fast to build with:
- Strongly typed front and back ends that work together seamlessly
- An asynchronous, event-driven system hidden in an approachable language
- You only define the business logic. That means no devops and no systems code
- Daml’s and DABL’s auto-generated architecture, which gives you automatic APIs, automatic authorization, access control, and improved security
The following section will describe the benefits of these four differentiators in greater depth. It’s aimed at readers with intermediate to high command of programming concepts.
Seamless alignment of front and back ends. By leveraging a declarative paradigm for specification of business processes that champions the gains traditionally associated with referential transparency, an entire class of programming errors that are caused by incorrectly synchronized mutation of shared state is avoided, leading to enhanced productivity.
The rich development toolset (along with minimal boilerplate code) makes the development experience fun. It removes all the clutter and lets you dive right in to defining your data model and end-to-end workflow without losing focus. Then the rest of the development is simply glueing the UI with the auto-generated JSON APIs and making it look pretty.
An asynchronous, event-driven system. Applications are decoupled into event sources (including actions initiated by the end user) and event sinks (which receive incoming events). Splitting up these tasks creates a drastically simplified and compartmentalized model for application design that allows more events to run simultaneously, making applications faster and more flexible.
No devops, no system code. By focusing on Daml and UI developers, startups eliminate the need for a wide spectrum of engineering skills, such as security and devops … You go from struggling to field a team to creating a functioning product and finding customers.
Auto-generated architecture. Because we’re defining everything that can change in the system, we’re ready for APIs. Daml’s codebase creates external-facing APIs for you. You don’t have to build a role layer or an API layer, and you don’t have to think about scaling the system.
By providing a scalable and first-class abstraction for data storage that incorporates its own authorization model, Daml uses a common language and system of record to keep track of who is allowed to do what. This eliminates tricky security vulnerabilities caused by inconsistent mapping between authenticated principals and service component data access on behalf of users.
Any non-trivial business-use case will require a number of data state transitions which (almost always) are orchestrated by an external program or service. This service may fail halfway through managing those transitions. Correct recovery is a major challenge, especially when dealing with mission-critical data (like financial transactions or any other transfer of value). Daml lets you take that business logic and orchestration and put all of it (or as much as you want) in the body of the actual Daml templates. This guarantees you atomic state transitions with rich business logic. Either everything happens properly or nothing happens at all, which removes all the hassle of ever ending up with a corrupt or intermediate state.
Access control is beautifully baked into the language and distilled into a single native type named "party" with a few keywords around it that grant it rights and enforce obligations. Although this steepens the learning curve at first, it quickly pays off: If modeled properly, it completely eliminates erroneous edge cases or the possibility of bad actors corrupting data and ultimately the app.
Conclusion: The Daml/DABL difference
This post introduced some fundamental concepts behind designing applications in Daml and deploying them via project:DABL. At a high level, it also explained how this architecture changes engineering requirements and the focus of product development within your team.
Keep reading upcoming installments of “How to Make the Most of Daml Application Architecture” to dig deeper into the ways Daml and project:DABL revolutionize product design.
Daml has also a new learn section where you can begin to code online:
If you want to master Daml smart contracts, you should also read:
- Interoperability between different markets and how Daml fits,
- Programming Smart contracts - A look into Daml, Kotlin & Java
- How easy it is to learn Daml,
- Some of the reasons why Daml and not Java or Solidity,
- Daml brings a paradigm shift as a programming language,
- How privacy in Daml differs from the rest and why it’s better.