Building Bug Graph

Initial development

With Rust, Actix, Yew and IndraDB

Every year SUSE gives its employees one week to work on whatever they want. This is referred to as Hack Week. Last year I used it to work on rselisp which is an Emacs Lisp interpreter written in Rust. I was quite happy with how that went, but stopped working on the project because I feel like there are more urgent things to work on than cloning Emacs.

In particular I spend a lot of time just matching test failures with existing Bugzilla entries. OpenQA has some facilities to automatically tag test failures with bug reports, but it is rather limited. Extending it would be possible, but I'd rather do it externally and using different technologies.

I considered using Elixir instead of Rust, but I think that Rust's performance and type system are better. Also, thanks to Actix, I can use the actor model with Rust. It is hardly as ergonomic as Elixir/erlang, but appears to work pretty well. Although the compiler throws out some pretty nasty type system errors due to the complexity of Actix's type gymnastics.

I have split the program into a number of actors, which, at least in theory, can independently fail and be restarted. They also run in different threads, so the application is naturally multi-threaded and should scale fairly well if the repository (repo) actor can be made to have multiple instances.

Of course I am also using Actix-web which is known to be very fast. On the client side I am using Yew which is also written in Rust and is compiled to WASM. This means the entire project is written in Rust with the exception of the Bulma CSS library. Yew also supports the actor model although I have not used that element of it. I really like having everything written in the same language and also not having to deal with Javascript runtime errors which can be caught at compile time in Rust.

The client is a single page application which communicates with the server over a single web socket connection. This is definitely not the easiest way to write a web application, but it is very lean and flexible. There is not much for me to say about Bulma other than it generally just works and is easy to use. I am even using it for this document, because it requires so little effort.

For the database I am using IndraDB, which is a graph database, and plain BTreeMaps from the standard library as a key-value store. Currently there is no persistence so at some point I need to add a persistent key-value store. I would like a pure Rust solution, so don't particularly want to use one IndraDB's existing backends with the exception of the in-memory data store which is also implemented using BTreeMap. I quite like the look of sled. There is also TiKV, but it looks like a more of a heavyweight solution.

I am quite happy to only use a graph database and key-value stores. For simple queries this may not be the easiest option, but having full control over the data structures and algorithms is beneficial for more advanced tasks while also achieving good performance. I may need to implement my own replication solution for scaling to multiple nodes (unless I use TiKV), but that is not an immediate concern.

So far there is not much one can do in Bug Graph except view a matrix of test results. Most of my time has been spent wiring the various parts of the application together or trying to understand how all these libraries and some Rust features work. However I think that most of the infrastructure is in place now so things should start to progress at a faster pace until I enter the next phase of the project

For large, long term projects, I am a big fan of reimplementing the wheel Vs having a huge messy dependency graph. So I am not so happy with the number of large dependencies the project has. With rselisp I barely had any dependencies and I felt like I spent a lot more time creating features than dealing with issues in third party libraries. However I also wasn't exposed to a lot of Rust functionality which has been heavily exploited by the likes of Actix and Yew. So at least from a learning perspective, using third party libraries has actually been beneficial on this occasion, when usually it exposes you to less opportunities to learn. The main reason for this is probably the immaturity of these projects, so I have spent a lot of time reading their code to figure out how to do something instead of just reading the docs.

For more info see the README which also contains the present state of the project and what tasks I am probably working on.