Skip to content

4 Candidate Architectures

Colfax Selby edited this page Feb 17, 2021 · 1 revision

This is where the architectures should go. An "architecture" here is a very simple high-level view of the system, in a basic building-block fashion. It is not a design, which is a low-level breakdown of the exact implementation details for an architecture. Try to describe the components, how they interact, and how they achieve the requirements.

I'm not going to fill these in for real - that's up to the team, I'll just put some examples down. Obviously you can mix and match the frontend and backend components to come up with a whole host of different candidate architectures. I'm just trying to give you ideas about what constitutes an architecture.

Note that some of these are silly and would never work. That's okay! Write down as many as you want, and explain why they're stupid in the trade study. It'll help catalyze the vision for the best architecture.

Example Candidate 1

  • Write the frontend in a web framework, run it on a NodeJS server locally
  • Use the rocket pool backend to deploy the clients
  • Use docker to host the ETH1 and ETH2 clients

Example Candidate 2

  • Write a desktop app in .NET with Avalonia as the UI framework
  • Build the backend from scratch in the same app
  • Don't use docker, deploy directly to the local system

Example Candidate 3

  • Write an Android / iOS app as the frontend
  • Connect to a custom backend server that's running on the node machine
  • Use docker for the ETH2 client, but install the ETH1 client locally

Trade Study

This is where you analyze the pros and cons of each architecture, and decide which one to pursue. It's also common to Frankenstein a bunch of pieces from each one together to create an entirely new architecture once you understand the various strengths and weaknesses. Normally I'd put this in its own separate page but it's easier to refer to the architectures when they're right above this.

Architecture 1

Pros:

  • Uses well-known technology, easy to find developers
  • Re-use of rocket pool will probably save development time
  • Docker makes it easy to clean up during uninstall

Cons:

  • Only works on x64 (no Raspberry Pi) because the Geth and ETH2 client maintainers don't keep ARM64 images on Docker Hub
  • Installing Node is hard for non-technical users

Architecture 2

Pros:

  • Can build the entire thing as a single standalone app
  • C# is my favorite language, yay
  • Works on any platform, because most client vendors host binaries for them on Github

Cons:

  • Have to redesign the backend from scratch, no reuse
  • Have to make sure security settings get done correctly
  • Uninstalling is harder in non-docker environments, lots more safety checks required
  • Adds extra overhead, since it has to run on the staking machine as the front and backend are coupled into a single app

Architecture 3

Pros:

  • Everyone with enough ETH to stake has a phone, and they use them all the time
  • Decent way to work with headless units and/or cloud-based VPS hosts
  • Backend being API-only means you can access it from other machines, reduces overhead
  • Probably forces us into a UX that's really easy to use
  • Lots of mobile developers out there

Cons:

  • Hard to provide the details necessary for advanced users
  • Sucks for people that don't want to use a phone
  • Might be hard to install the backend properly
Clone this wiki locally