Mainframe OS Architecture Changes
In the past few months we’ve been working on a major refactoring of the Mainframe OS architecture, to serve as a solid foundation for our future plans.
Why refactoring?
Background
When we started building what is now Mainframe OS, we had lots of different ideas about what it could become but no certainty about what would be most relevant to our priorities.
In order to avoid getting stuck in a direction that would be hard to move from, we started building an architecture that would offer us a lot of flexibility, in part inspired by how Ethereum works:
- A background process that we called the daemon would be responsible for communicating with the underlying infrastructure (Ethereum and Swarm), managing the user’s private keys and exposing a JSON-RPC API for clients.
- An Electron-based desktop application called the launcher would be our first client, running apps leveraging Ethereum and Swarm by using the daemon.
Limitations
At first this architecture worked well and indeed provided us with the flexibility we wanted, but as we iterated over the UX and features we decided to provide in the launcher, additional logic was often needed to be added in the daemon.
This introduced more complexity in the system, as we still wanted the daemon to be generic enough to accommodate the needs of different clients, while wanting to provide the best UX possible in the launcher.
This architecture also made Mainframe OS more difficult to distribute, as it required the launcher to make sure the daemon is installed and running before the launcher itself can run.
These constraints, associated with our focus on Mainframe OS as a desktop application, lead to the decision to reconsider this architecture for our more specific needs.
What changed?
The new architecture can be summarized as merging the launcher and daemon together in an Electron application, using the following stack:
- Erebos is still used to interact with Swarm
- Rather than a custom data structure that we called the vault, responsible for holding the user data (wallets, apps, contacts…), we now use the RxDB local database, providing more powerful capacities.
- GraphQL is still used as the primary data interface between the UI and the database, but is now served by the Electron main process rather than the daemon.
These changes allow us to provide a more unified experience in Mainframe OS, while making the system easier to maintain by reducing its complexity and relying on mature libraries and tools.
What’s next?
One of our goals following this refactoring is to keep releasing a new version of Mainframe OS every quarter, as much as possible aligned with Electron’s releases schedule, in order to leverage the latest improvements and security updates.
We also want to make it easier for developers to not only develop apps running on Mainframe OS, but also contribute to the development of Mainframe OS itself. Having a simplified architecture should help people get started faster with the development of improvements to Mainframe OS.
Finally, these changes provide the necessary foundation to build forward-compatible protocols and data structures, by providing an easier way to define and change the internal data structures of Mainframe OS while supporting migration of existing data.
