add design document describing current issues
padre
5e17636b9d
commit
6935565efd
@ -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…
Referencia en una nueva incidencia