Skip to main content

DApp architecture

Introduction​

This article explains the architecture of DApps on Hathor platform. We will cover:

  • the definition of a DApp;
  • an overview of a DApp’s architecture;
  • the components of a DApp; and
  • the interactions of a DApp.

TL;DR: see section key takeaways.

What is a DApp?​

Decentralized application (DApp) is an application that runs on a blockchain system.

An application is considered decentralized when the core part of its business logic is implemented as smart contracts, and users submit blockchain transactions to perform operations on it. Not all components of a DApp need to be decentralized. Usually, the DApp team provides the front end as a web application hosted on a central server and/or as a native application published on major mobile application stores (e.g., Google Play and Appstore).

Overview​

On Hathor, DApps follow the same architectural pattern as those on conventional public blockchain platforms. The following diagram presents the typical architecture of DApps on Hathor platform:

DApp architecture

Credits: icons created by annisa luthfiasari, Trevor Dsouza, rendicon, Juicy Fish, and Ralf Schmitzer from the Noun Project; and smashingstocks and, Ahmad Roaayala from Flaticon.

A DApp consists of three main components:

  • Front end
  • Nano contracts
  • Complementary services

In the next section, we will describe these components in detail. Following that, we will explain how they interact with each other, the user, and their wallet.

Components​

(1) The DApp front end comprises the application(s) (web and native) provided to users by the project (DApp) team. (2) The DApp back end comprises Hathor Network and complementary services. (3) The core business logic of the DApp is implemented as one or more nano contracts. (4) Hathor Network acts as the main part of the back end, running the core business logic, whereas its ledger (blockchain) act as the main database.

(5) Complementary services encompass all the DApp’s needs outside the scope of blockchain control. These may include meeting functional requirements, such as off-chain storage, and non-functional requirements, such as blockchain indexers. Complementary services can be decentralized, such as the indexing solution "The Graph", or centralized, such as the back-end service used in many DApps.

Interactions​

(6) A person accesses the DApp front end via a browser or by installing a native application on their device. The DApp front end can be provided in a centralized manner — via conventional web servers and application stores — or in a decentralized manner — e.g., IPFS and Filecoin.

Once initialized on the user's platform (web browser or native), the DApp front end establishes two connections. (7) (8) The first connection is with the back end. The connection with the back end can be made directly to Hathor Network or mediated by a centralized back-end component.

(7) In its simplest form, the DApp back end does not have a centralized service, and the front end connects directly to Hathor Network. In this case, the DApp front end alone reads the blockchain and provides functionalities to the user.

(8) For reasons such as user experience and scalability, many DApps use centralized back-end services. In this case, the DApp front end provides only the UI and connects to a centralized back-end service (9) that mediates all interactions with the blockchain.

(10) The second connection is with the user’s wallet. (11) Since it does not have access to the user’s private key, the DApp front end relies on this connection to enable the user to perform operations.

(10) Additionally, the type of connection between DApp front end and wallet depends on the user’s environment. Specifically, whether both use a web browser as a platform — e.g., DApp front end as a web application and wallet as a browser extension (like MetaMask) — or are autonomous processes, and whether or not they are on the same device — e.g., DApp front end running on a desktop web browser whereas wallet on a mobile device.

Key takeaway​

In its simplest form, a DApp on Hathor consists of:

  • Front end: web and/or native applications that integrate with the blockchain and the user's wallet.
  • Back end: one or more nano contracts (smart contracts) that implement the core business logic.

Some project teams opt to implement only the UI and wallet integration in the DApp’s front end, relying on a centralized back-end service to manage interactions with Hathor Network.

What's next?​