This is document describes the Design Goals and Refactoring Strategies of our ongoing efforts to improve the architecture, and with it the stability and performance of Plume.
## Current Issues
Let's look at the current architecture's problems, and the attempts we've made at resolving them.
This data structure was [introduced by yours truly](https://github.com/Plume-org/Plume/pull/462) with the intent to please Clippy, reduce the number of arguments passed around (the main thing Clippy complained about).
We also tried reduce the amount of bytes being passed around, by using references.
At the time, this seemed like a good idea.
Right now, it's the main source of our problems.
This `struct` bundles `DbConn`, which makes it difficult migrate Plume to `async` Rocket:
Passing around a giant `struct` as `ref` in `async` world, means that different owners are waiting for it to be `.await`ed, so they can access them.
This makes working with such a `struct` very unwieldy, if not impossible sometimes.
### DbConn, Searcher and Post
`DbConn` and `Searcher` are deeply bundled via Post.
`Searcher` is called every time a `Post` is added/updated/deleted.
It needs access to `DbConn` to fill the data that `Post` does not have.
While removing one or the other from `PlumeRocket` is possible, complications still arise with `AsObject`:
Posts's `AsObject` APIs are called every time a Post is added/updated/deleted.
It builds on `PlumeRocket` as main `Context`, and so we'd have to touch every API if we split either `DbConn` or `Searcher` out of `PlumeRocket`