Apicize Architecture
How Apicize is built with and why...
Apicize has two executables. The main one is [a Tauri desktop application](https://github.com/apicize/app), and the other is a Rust [CLI]((https://github.com/apicize/cli)). Both of these share a Rust library that actually dispatches HTTP requests and executes tests. HTTP requests are dispatched using the reqwest crate. JavaScript tests are executed using V8 engine via the rusty v8 crate.
The Tauri desktop UI is located in the app directory, and is built using React with Mobx for state management. Only those portions of the UI that interact with the file system, application window, etc. are impelemented in the Tauri app project. The vast majority of UI components are implemented in the @apicize/toolkit package, and are completely Tauri-agnostic. The idea here is that if somebody wanted to create something like a Visual Studio Code add-in, there would be a set of React components that could be used in any front-end.
Why these choices? Originally, the project was going to be built entirely using Electron and NodeJS. Electron was ok, but seemed to add a lot of overhead, and not everything worked great. For example, there was one long-standing bug with file dialogs in Linux that took forever to get resolved. And securely executing JavaScript tests was problematic. There was no straightforward way to execute JavaScript without access to the things like file system calls that presented potential security challenges. What if somebody gave you a workbook with tests that scanned your drive and sent the data somewhere? Electron does not provide great options here. Deno actually has a lot of flexibility in addressing this topic, but sadly, that doesn't help Electron apps.
I was curious about Rust and thought I could write a CLI tool to execute the requests and tests, and just have the Electron app call that. That initail foray into Rust proved easier than expected, and that's when I came across Tauri. It seemed leaner and I could call Rust code from it easily. I started playing around with Tauri right before their v2 announcement. At this point, I had rebuilt the UI prototype in Electron, Tauri v1 and now, Tauri v2.
With Tauri v2, the application was mostly running the way I liked, but I found Redux state management to be excrutiating to work with. Many people swear by Redux, so I'm sure the problem was just me, but I found it to be a ton of boilerplate, a gazillion "structuredClone" statements, and a lot of uncertainty around how to get the data store and UI updating each other consistently, which is the whole point. I came across MobX which, basically, "just worked". The hardest, and most joyous, part of implementing MobX has been deleting hundreds of lines of Redux reducers, now-unnecessary useSelectors, etc.
So that is currently where things stand, and I don't see any big changes coming. I've started to work on unit tests for Rust and will also start writing UI tests now that my design is mostly nailed down. The only other major features I would like to add at this point are muiltiple windows and better clpboard support for managing copying/pasting workbook elements.