P4Pillon/Krys4lide
4
2
Fork 0
Code Issues 27 Pull Requests 3 Actions Packages Projects 1 Releases Activity

feat: restructure project, implement askama templating #26

Merged
theo merged 21 commits from restructure-project into main 2024-07-26 14:42:03 +02:00
Conversation 1 Commits 21 Files Changed 51 +30 -22
1 changed files with 30 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit c2b4264f32 - Show all commits

40
crates/tauri/src/lib.rs
View File

@ -2,40 +2,43 @@ use core::panic;
use std::sync::Arc;
use tauri::{path::BaseDirectory, Manager};
use tokio::sync::Mutex;
use tokio::sync::{Mutex, MutexGuard};
use tower::{Service, ServiceExt};
async fn process_tauri_request(request: tauri::http::Request<>, router: axum:Router ){
let (parts, body) = request.into_parts();
let body = axum::body::Body::from(body);
async fn process_tauri_request(
request: tauri::http::Request<Vec<u8>>,
mut router: MutexGuard<'_, axum::Router>,
) -> tauri::http::Response<Vec<u8>> {
let (parts, body) = request.into_parts();
let body = axum::body::Body::from(body);
let request = axum::extract::Request::from_parts(parts, body);
let request = axum::extract::Request::from_parts(parts, body);
let response = match router.as_service().ready().await {
let response = match router.as_service().ready().await {
Ok(ready_service) => ready_service.call(request).await,
Err(_error) => panic!("Failed to get ready service"),
};
};
let response = match response {
let response = match response {
Ok(response) => response,
Err(_error) => panic!("Problem getting response from request."),
};
};
florian_briand marked this conversation as resolved Outdated
florian_briand commented 2024-07-24 08:42:53 +02:00
Outdated
Review
Copy Link

Est-ce que tu sais ce que font ces empilements de Arc / Mutex et pourquoi c'est là ? Ou bien c'est un copier-coller ?

J'avais justement essayé, dans la version précédente, de simplifier au maximum, pour éviter d'avoir une seule ligne de code qui viennent d'ailleurs et dont on n'ait pas la maîtrise.

Est-ce que tu sais ce que font ces empilements de Arc / Mutex et pourquoi c'est là ? Ou bien c'est un copier-coller ? J'avais justement essayé, dans la version précédente, de simplifier au maximum, pour éviter d'avoir une seule ligne de code qui viennent d'ailleurs et dont on n'ait pas la maîtrise.
florian_briand commented 2024-07-24 08:52:29 +02:00
Outdated
Review
Copy Link

De plus, le code était + découpé et + lisible dans la version précédente ; il me parait préférable d'itérer sur l'existant plutôt que de venir tout écraser avec une autre façon de faire

De plus, le code était + découpé et + lisible dans la version précédente ; il me parait préférable d'itérer sur l'existant plutôt que de venir tout écraser avec une autre façon de faire
theo commented 2024-07-24 10:22:56 +02:00
Outdated
Review
Copy Link

Le Arc<Mutex> est utilise pour faire de la communication async dans rust, on peut pas vraiment faire sans.

Pour Arc: "Arc is a smart pointer enabling sharing data between threads. Its name is a shortcut for "atomic reference counter". The way Arc works is essentially to wrap a value we're trying to share and act as a pointer to it. Arc keeps track of all of the copies of the pointer and as soon as the last pointer goes out of scope it can safely free the memory. "

Pour Mutex: " Mutexes in many languages are treated like semaphores. You create a mutex object and you can guard a certain piece (or pieces) of the code with the mutex in a way that only one thread at a time can access the guarded place. In Rust Mutex behaves more like a wrapper. It consumes the underlying value and let's you access it only after locking the mutex. Typically Mutex is used with conjunction with Arc to make it easier to share it between threads."

Donc c'en gros, vu qu'on veut une seul instance du router et qu'on fait de l'async, on peut pas faire sans.

Article qui en parle: https://itsallaboutthebit.com/arc-mutex/

Pour ta remarque sur la maitrise du code:
1 - L'interface entre les deux libraires ser inevitablement un point de complexite, on evitera de faire ca dans le futur.
2 - Je pense que si on se heurte a des limite dans nos connaissances, il faudrait qu'on se pose la question si cela ne vaudrait pas le coup d'approfondir :)

Le Arc<Mutex<V>> est utilise pour faire de la communication async dans rust, on peut pas vraiment faire sans. Pour Arc: "Arc is a smart pointer enabling sharing data between threads. Its name is a shortcut for "atomic reference counter". The way Arc works is essentially to wrap a value we're trying to share and act as a pointer to it. Arc keeps track of all of the copies of the pointer and as soon as the last pointer goes out of scope it can safely free the memory. " Pour Mutex: " Mutexes in many languages are treated like semaphores. You create a mutex object and you can guard a certain piece (or pieces) of the code with the mutex in a way that only one thread at a time can access the guarded place. In Rust Mutex behaves more like a wrapper. It consumes the underlying value and let's you access it only after locking the mutex. Typically Mutex is used with conjunction with Arc to make it easier to share it between threads." Donc c'en gros, vu qu'on veut une seul instance du router et qu'on fait de l'async, on peut pas faire sans. Article qui en parle: https://itsallaboutthebit.com/arc-mutex/ Pour ta remarque sur la maitrise du code: 1 - L'interface entre les deux libraires ser inevitablement un point de complexite, on evitera de faire ca dans le futur. 2 - Je pense que si on se heurte a des limite dans nos connaissances, il faudrait qu'on se pose la question si cela ne vaudrait pas le coup d'approfondir :)
theo commented 2024-07-24 10:42:54 +02:00
Outdated
Review
Copy Link

Pour ton deuxième commentaire,

Initialement, je pensais que la logique procédurale du code était claire et qu'il n'était pas nécessaire de la diviser en fonctions. Je préfère éviter d'ajouter des abstractions tant qu'elles ne sont pas nécessaires.

Cela dit, je comprends ton point de vue sur l'importance de ne pas imposer une méthode différente sans raison valable. Mon intention n'était pas de manquer de respect à ton travail.

Je vais proposer une version plus claire du code. J'attends tes retours :)

Pour ton deuxième commentaire, Initialement, je pensais que la logique procédurale du code était claire et qu'il n'était pas nécessaire de la diviser en fonctions. Je préfère éviter d'ajouter des abstractions tant qu'elles ne sont pas nécessaires. Cela dit, je comprends ton point de vue sur l'importance de ne pas imposer une méthode différente sans raison valable. Mon intention n'était pas de manquer de respect à ton travail. Je vais proposer une version plus claire du code. J'attends tes retours :)
let (parts, body) = response.into_parts();
let body = match axum::body::to_bytes(body, usize::MAX).await {
let (parts, body) = response.into_parts();
let body = match axum::body::to_bytes(body, usize::MAX).await {
Ok(bytes) => bytes.to_vec(),
Err(_error) => panic!("Problem converting response body to bytes."),
};
};
let response = tauri::http::Response::from_parts(parts, body);
let response = tauri::http::Response::from_parts(parts, body);
response
}
#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
tauri::Builder::default()
.setup(|app| {
// Create a router and adds it the the app state
let resource_path_buf = app
.path()
.resolve("assets", BaseDirectory::Resource)
@ -45,6 +48,8 @@ pub fn run() {
clego::get_router(resource_path_buf.as_path()).clone(),
));
// Adds the router to the application state
// This makes it so we can retrieve it from any app instance (see bellow)
app.manage(router);
Ok(())
@ -53,7 +58,10 @@ pub fn run() {
let router = Arc::clone(&app.state::<Arc<Mutex<axum::Router>>>());
tauri::async_runtime::spawn(async move {
let mut router = router.lock().await;
let router = router.lock().await;
let response = process_tauri_request(request, router).await;
responder.respond(response);
});
})