James Montalvo

From CLI to Electron to Web

2021-09-07

Maestro started as purely a command line app for converting procedures authored in YAML into Word documents. My initial belief was that this method would be a valid long term solution; we would be able to use an IDE with knowledge of the Maestro YAML schema and non-programmers would be able to author procedures without any additional user interface. I was very wrong. While writing simple procedures felt good in Maestro YAML, as soon as I started implementing a full EVA procedure it became difficult to follow sync points between actors. Thus, the requirement for an easy-to-use UI was born in late 2019.

Late 2019 was when I took over active development of the project. Prior to that point Maestro had been an idea of mine implemented by a few semesters of students. I was fortunate enough to know a computer science professor in need of project sponsors, and his students created the CLI-only version of Maestro (at that time called “Spacewalk”). Those teams of students did an excellent job building a prototype YAML-to-HTML converter. While in the final weeks prior to US EVA 55, the last EVA I developed and executed from Mission Control, I couldn’t help but compare the cumbersome Word-authored procedures to a future using Maestro. Experiences leading up to that EVA showed me how badly we needed a better solution and drove me to take what those students started and make it viable for actual procedure development.

In addition to improving the authoring experience, Maestro also needed to improve the editorial workflow. As stated in the prior post, I have been heavily involved with several open source projects, often collaborating with strangers on the other side of the world, but with EVA procedures it was difficult to collaborate with people I’ve known for a decade who sit just down the hall. Word documents have a strong tendency towards single-person authorship, which is unacceptable for modern tools. I therefore decided to store procedures in Git repositories and allow Maestro to be a wrapper on common Git workflows. This would keep it simple for all users, but allow experienced users to get the full power of Git. This concept of letting Git handle versioning was baked into the early concept, before students even began developing the initial CLI app.

Electron

Since Maestro needed to manipulate files on a user’s hard drive and I expected in the future that we’d want a web version, I built it as an Electron app. This provided a desktop app immediately, and provided a path to a web app in the future (a future post will discuss how Maestro’s isomorphic code is reused across Electron, web client, and web server). Users clone a Maestro “project” (a set of procedures) from our internal GitLab instance, make changes to it via the Maestro UI, and commit them back using the UI. As stated above, the goal is that all Git interaction be accomplished via the Maestro UI so no user has to learn Git. With our limited resources, however, Git integration hasn’t been as high a priority as making the rest of the app excellent, and being able to leverage existing Git tools without writing any code has been a big benefit.

In Summer 2021 a web version of Maestro came online purely as a viewer to follow along during procedure execution. A “leader” using the Electron app could mark steps complete and fully edit the procedure, and anyone viewing via the web version saw all the updates. Last week we did an NBL run with 70+ viewers, and this shared experience was great for maintaining situational awareness across the team.

Web

While the production web version currently is limited to viewing, we have demonstrated that editing and executing is possible on web, and at the moment is simply disabled as we determine the long-term architecture. Bringing the web version nearly on par with the Electron version has forced us to question whether the Electron + Git model is correct for Maestro. The three major issues are:

  1. Maintaining desktop applications is way harder than web applications. Users inevitably run into weird issues specific to their machine, and discovering and troubleshooting these issues can be difficult.
  2. Without Maestro fully abstracting Git (and at this point it definitely is not) users are expected to climb a steep learning curve, which could seriously hurt adoption.
  3. Friction in distribution is much higher for a desktop app where users have to download and install, compared to a web app where they just click a link.

The need for a desktop application also may not be as strong as it was initially. Pre-COVID, people brought their laptops away from NASA to work on procedures, and there was a much lower likelihood that they would use NASA VPN. Any tool needed to work without connection to the NASA network. Post-COVID, everyone VPNs daily.

Regarding Git: I have some users who feel strongly that maintaining procedures in Git is the way to go, but while I see their arguments I think there is a high likelihood we’ll move away from storing procedures in Git. It has served us very well in the early days of Maestro by allowing users to have a high quality versioning system at no extra development cost, but at this point it makes more sense to have an easy-to-use versioning system that integrates cleanly into the application. Before making this decision, however, I’ll be discussing it at length with users and making sure the proposed change meets their needs.

This post has described Maestro’s origins as a CLI app, transition to a desktop app, and possible future as a web-first app. This architectural history is important to understanding Maestro’s present and future. The other major force that has shaped Maestro in 2021 is procedure execution, which has been touched on but will be described in much greater detail in my next post.