Understanding Centralized Systems
On our previous post: Our Path To Decentralization, we took a brief look at the evolution that applications have had since the invention of Distributed Ledger Technology.
Although throughout this series we will mainly be exploring the concept of decentralized applications – or dapps, it is important to first understand how applications have traditionally been built. In order to accomplish this, we will take a look at two common application design patterns:
Three Tier Architecture
One of the most common patterns when designing an application is the Three Tier Architecture.
In this pattern, developers define three big conceptual parts of any system:
- The Presentation Layer
- The Logic Layer
- The Data Layer
Each of the layers has a specific set of responsibilities and is decoupled from the other two, which allows for faster development and reduced maintenance costs because you can easily work on each of the layers in parallel.
Although this architecture may seem trivial for some readers, it’s very important to have a basic understanding of it in order to follow this blog series properly.
Client – Server Architecture
Another common pattern, that will help us understand how centralized applications are designed is the Client – Server architecture.
Client: Part of the application that interactsdirectly with the user, typically on a computer or a smartphone. The clientusually only performs lightweight calculations and relies on the server fordata processing.
Server: Part of the application that focuses on datamanagement and logic execution. The server is optimized for receiving requestsfrom the client, processing them, and storing and receiving information from adatabase
Because all data and logic resides in a protected environment, the server-client architecture allows companies to maintain full control over their Digital and Intellectual Property as well as optimize their hardware infrastructure for their specific usage.
On the other hand, this approach requires the users to completely trust the service provider since the users have no way to validate what’s happening on the server and has multiple security flaws, such as the issue of having all the user data on a single honeypot.
In the following posts we will take a deeper look the Radix approach to building dApps, and why it is much more powerful than the other options out there.
Thanks to the invention of Distributed Ledger Technology however, we are now able to build systems that don’t have a single point of failure. Although it’s sometimes hard to ensure that that is the case (ej, DNS systems), we can now benefit from this innovation, which will allow as to build cheaper, safer and more transparent applications.
However, not all DAPPs are equal, and their properties can change heavily depending on their architecture. In the next articles we will compare three different application architectures enabled by distributed application platforms.