Krater

I worked on Krater because debugging a Laravel app often took me outside the browser. A queue job could fail while the page looked fine. A command could print something useful and then exit. I wanted to inspect that work in a separate window and keep the output after the process ended.

Krater was the local debugging app in the MoonGuard project. The companion PHP package, Larvis, sent data from a Laravel application over HTTP. Krater received it and stored it in SQLite. You could close the app and return to the same records later.

We built the desktop app with Go and Wails, with a Vue and TypeScript interface. Wails let us use web components for the interface and call Go methods for the desktop work. GORM handled the database. The app targeted macOS, Windows, and Linux.

Most of the interface was for reading what had happened. Messages showed values sent through the larvis() helper. Exceptions had their own view, separate from HTTP requests. Query records included the SQL and its timing. Keeping these records outside the application under inspection meant a terminal command and a browser request could report to the same place.

The query tools went further than listing statements. Krater could connect to the application's database to inspect an execution plan and the related table structure. It had analyzers for MySQL, PostgreSQL, and SQLite. An OpenAI-backed chat used the query and that database information as context. The extra context mattered because a question about a slow query also needs information about the tables it reads.

Krater is retired. Its last release was in April 2024, and the MoonGuard site that distributed it is no longer available. The source remains public.

The part I would keep is the local history. A useful debugging record should survive the thing being debugged. I would also pay more attention to releasing Krater and Larvis together. Separating collection from inspection made each package easier to work on, but it left us responsible for keeping both ends compatible.