mirror of
https://github.com/Pagwin-Fedora/website.git
synced 2025-07-18 10:55:41 +00:00
final changes to the new blog article
This commit is contained in:
parent
8759383b3f
commit
d89025bef1
1 changed files with 6 additions and 5 deletions
|
@ -26,16 +26,17 @@ I put it this all toegether with copious usage of FFI to connect the Rust, Go an
|
||||||
|
|
||||||
## Problems
|
## Problems
|
||||||
|
|
||||||
But recently I've decided that all of that is dumb and unnecessary. Initially it made sense to use the somewhat unwieldy FFI setup because the backend was going to take a struct instead of a string and structs cannot be passed via stdin. Once I realized how hard and unnecessary that was due to FFI things I dropped it. With that my architecture was just passing around strings and I realized that my setup is overly complicated for that. So instead of FFI and TCP spaghetti instead I'm going to have ~~subprocess spaghetti~~ each component of the application be separate executables of some kind or another.
|
But recently I've decided that all of that is dumb and unnecessary. Initially it made sense to use the somewhat unwieldy FFI setup because the backend was going to take a struct instead of a string and structs cannot be passed via stdin<sup>[citation needed]</sup>. Once I realized how hard and unnecessary that was due to FFI things I dropped it. With that my architecture was just passing around strings and I realized that my setup is overly complicated for that. So instead of FFI and TCP spaghetti instead I'm going to have ~~subprocess spaghetti~~ each component of the application be separate executables of some kind or another.
|
||||||
|
|
||||||
## The New Architecture
|
## The New Architecture
|
||||||
|
|
||||||
This description is going to suck so I recommend clicking off if you get bored. For my new architecture there will be 4 components
|
This description is going to suck so I recommend clicking off if you get bored. For my new architecture there will be 5 components
|
||||||
|
|
||||||
1. The init script
|
1. The init script
|
||||||
2. The frontend
|
2. The frontend
|
||||||
3. the middleware
|
3. the front-to-back middleware
|
||||||
4. and The backend.
|
4. the back-to-front middleware
|
||||||
|
5. and The backend.
|
||||||
|
|
||||||
The original repository that held all the code will have it all removed as the frontend, middleware and backend are developed in separate repositories which are had as git submodules in the main repository which will be where an init script and a build script will be held.
|
The original repository that held all the code will have it all removed as the frontend, middleware and backend are developed in separate repositories which are had as git submodules in the main repository which will be where an init script and a build script will be held.
|
||||||
|
|
||||||
|
@ -49,7 +50,7 @@ The frontend will accept user input and print it to stdout in a manner understoo
|
||||||
|
|
||||||
### The middleware
|
### The middleware
|
||||||
|
|
||||||
The middleware will take messages from the frontend and parse them for the backend to understand and vice versa. In order to check functionality of the middleware to ensure it is passed messages from the end(s) it wants the init process will do a brief feature check of the middleware by running it with the `--features` cli option.
|
The front to back middleware will take messages from the frontend and parse them for the backend to understand and vice versa for back to front.
|
||||||
|
|
||||||
### The backend
|
### The backend
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue