add design document describing current issues

pull/813/head
Mina Galić hace 4 años
padre 5e17636b9d
commit 6935565efd
Firmado por: igalic
ID de clave GPG: ACFEFF7F6A123A86

@ -0,0 +1,33 @@
# Refactoring
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.
### PlumeRocket
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`
## Solution Attempts and their Problems
Cargando…
Cancelar
Guardar