Previously we chatted about the basic principles and motivation behind the Melon Satellite subproject, and you were promised a more detailed description. Well, now we’re back to do just that!
By the end of this post you will have an understanding of Satellite’s general architecture, its components, and how they interact together. A quick warning that this piece is more technical than the last, but don’t let that deter you from giving it a read. :)(Re)introduction to Satellite
Our previous article gives an overview of what Satellite is meant to accomplish. Broadly, the goal is the provide a permissionless registry of Melon modules.Uplink: Module developer registers their module to Satellite, which acts as distribution; Downlink: Fund manager browses Satellite registry for modules to use in their portfolio
The project will ultimately be a user interface with the ability to register and browse third-party modules, along with auxiliary functions to interact with entries in the registry.
Concretely, the community effect of Satellite would be to ease interactions between module creators and module users (see diagram).Global architecture
The subproject will have to consider and manage interactions between:1. The client 2. The server 3. The blockchain
This sort of structure, especially the interplay of client and blockchain, is colloquially known as decentralized application (or DApp) architecture.
Though our application includes a server component, the core functions of the registry are completely independent of it, in the true spirit of decentralization. This means that our server could become the victim of a DDoS attack, but the Satellite registry will continue to work even while the server is offline!
Specifically, the server is more of a convenience component of the application; operations that need not interact with the blockchain are relegated to the server. This includes activities such as indexing...