Thread by @santicarmuega

From a developer standpoint... WTF is a dApp?

- Is it synonym for smart contract?
- does it need a backend server?
- does it run entirely in a browser / mobile app?
- is it really decentralized if it uses a cloud provider?

some thoughts about it👇🧵

#Cardano #BuildingOnCardano

The way I see it, a dApp is a distributed system that incorporates particular non-functional requirements in order to make it "decentralized".

but it isn't a binary quality, it's a spectrum where different components of the same app might be more or less centralized than others.

My understanding of non-functional requirements for a dApp:

📌no censorship: no single entity can arbitrary limit my access

📌self-accountability: I can autonomously verify the correctness of my interactions

📌resilience: it's resistant to technical and social disruptions

A DEX for example: the on-chain component controlling the swaps is censorship-resistant, but the frontend might be hosted in a cloud provider.

It's a valid approach, but this describes a dApp where we find different levels of decentralization for its constituent components.

I find it easier to understand distributed systems by describing their "topology".

In software architecture, a topology refers to the layout or arrangement of components in a system. It describes how these components are connected and how they communicate with each other.

Each dApp is unique, would be impossible to describe every topology, but I do find some reoccurring patterns that we're trying to describe in this @txpipe_tools RFC:

rfcs.txpipe.io/0004-dapp-topo…

It's far from complete and there's room for improvement, feedback is much appreciated♥️

Instead of having very long names or cryptic acronyms for each topology, we named each pattern after pizza toppings (toppings ~ topology)🤷

Here're some examples👇

🍕Pepperoni: app where the bulk of the business logic resides server-side. Users interact with a frontend running on their device. User's light wallet is leveraged for signing transactions. Server-side acts as a gateway to the blockchain. Relies on on-chain validators.

🍕Hawaiian: app where all of the business logic resides client-side. Users interact with a frontend + business logic running on their device. Light wallet is leveraged for signing transactions. 3rd-party RPC provider is used for querying blockchain data and submitting transaction

🍕Bacon: aims at full self-accountability by running a full node client-side. Frontend and business logic also run client-side. Interactions between app and blockchain happen locally, directly against the node. Relies on on-chain validators.

🍕Mushrooms: usually referred to as a "headless app". All of the logic resides server-side, exposed as an API. 3rd parties, different from the dApp developer, can build independent frontends or provide new functionality by composing APIs.

(my personal favorite)

Why should I care as a developer?

Because architectural patterns are general, reusable solution to a commonly occurring problems. There's no silver bullet, every solution has trade-offs. By identifying the options, we're better suited to find the right solution for our use-case.

There's a lot more to be discussed:
- trade-offs in each topology
- libs & tools for each approach
- how to make the "cloud" component more decentralized

If you're interested in these discussions, @txpipe_tools discord is a nice place to hang out:

discord.com/invite/ZTHcHUy…