Chromia dapp overview

The diagram breaks a Chromia dapp into layers. As with a Web2 application, there is a frontend, a backend, and a database. You write the backend in Rell and deploy it to the Chromia platform, where nodes operated by a decentralized network of system providers run it. Your dapp's state lives in a database that the Chromia core software manages for you and replicates across several nodes. Every transaction that changes that data is recorded in a blockchain, which is replicated across several nodes as well.

Frontend

Users still reach your dapp through the frontend first, exactly as they would a Web2 app. You build the interface with the same tools you already know, such as HTML, CSS, and JavaScript, so user experience, responsiveness, and visual design stay central to your work.

Whenever your dapp needs to create or change data, it submits transactions to the Chromia blockchain network. The Chromia TypeScript client library, postchain-client, makes this feel much like posting data to an ordinary API. The next section walks through actual code that does this.

A transaction is only valid once it carries a signature made with the user's cryptographic keys. Think of the signature as a digital fingerprint tied to one specific transaction and one specific user. It proves the sender's identity and shows that nobody altered the transaction after it was sent.

Users usually keep their cryptographic keys in a wallet app on their device. When someone wants to send a signed transaction to your dapp on the Chromia network, your frontend calls the wallet app's API to request a signature. The frontend attaches that signature to the transaction, which makes the transaction valid and secure.

The whole flow is short: the wallet produces a signature, the signature goes onto the transaction, and the signed transaction is sent to a Chromia node that runs your dapp's backend. Moving from Web2 to Web3 on Chromia is a smaller step than you might expect. The next lesson covers this in more depth; first, here is how the backend works.

Backend

You write Chromia dapp backends in Rell, the platform's relational programming language. Rell aims to be quick to pick up and comfortable to work with for any developer, and SQL experience gives you a head start.

Your Rell code is deployed into what Chromia calls a container, and the Chromia network manages a dedicated blockchain for each dapp. Once deployment finishes, your frontend can start sending transactions and querying data. Deployment also creates the tables and relations your dapp needs to store its state in a PostgreSQL database, which the platform manages and replicates across several Chromia nodes without any action from you.

Talking to the backend works much like calling a conventional Web2 API. Submitting a transaction to a Chromia node corresponds to a POST request to a web service. You can also send read-only queries to a node, which correspond to GET requests. As a developer, that is all you need to keep in mind. If you are curious about what happens under the hood when a transaction arrives, read on.

The receiving node starts exchanging messages with the other Chromia nodes that run your dapp, called validators. The transaction is executed only after a "supermajority" of them agree that it is valid. You can compare this to a distributed Web2 system in which several servers cross-check a change before writing it to the database.

Consensus is reached when more than two-thirds of the validator nodes agree that the transaction is valid, and the transaction is then executed. Executing a transaction means running the operations it contains; the next section explains operations in detail. Those operations change the state in your dapp's database, just as database actions do in a Web2 backend. The transaction is also written to the blockchain, which makes it immutable and keeps it consistent across all nodes.

That covers the Chromia Web3 stack. It is not a completely foreign world: Web3 and Web2 share many concepts and much of the same vocabulary.