(Note: Brassica used to use a rather complicated architecture involving linking Haskell to C++. I abandoned this approach since it proved very difficult to maintain on Windows, but in the meantime I linked to this document as a reference on how to do it. Though it is now outdated, you can still read that version of the document https://github.com/bradrn/brassica/blob/v0.1.0/ARCHITECTURE.md.)
The desktop version of Brassica has two components, which broadly follow a client/server architecture.
The logic and CLI are written in Haskell, while the GUI is written in C++.
The GUI runs the CLI with a --server argument:
this places it into a ‘server’ mode
where it accepts JSON requests on stdin and outputs JSON responses on stdout.
The requests and responses are undocumented,
but should be trivial to infer from ./app/Server.hs and ./gui/brassica-gui/brassicaprocess.cpp.
The only real subtlety here is synchronisation. The server uses incremental parsing, and outputs a response as soon as a full and valid JSON object is seen. The response is followed by the control character U+0017 (‘End Transmission Block’). The GUI reads from the server’s stdout until this character is seen, at which point a complete JSON response has been received for it to decode.
The web version, by necessity, takes a different approach.
It is possible to compile the CLI to WASM,
but difficulties in async IO support make it difficult to use in the browser
(see e.g. bjorn3/browser_wasi_shim#14).
Thus, the web version bypasses the CLI entirely.
Instead, ./gui/brassica-interop-wasm/ contains a library which is compiled to a WASI reactor.
The website in ./gui/brassica-web/ then calls into this reactor.