Je dois écrire un µ-service en Rust et j'ai cherché pas mal de serveurs web permettant de le faire. Évidemment, la première chose que les moteurs de recherche nous remontent c'est Hyper. Pour faire simple, Hyper est une serveur HTTP 1/2 qui s'appuie sur le pool de threads asychrone Tokio.
Problème, Hyper reste assez bas niveau. Je recherchais donc quelque chose aux performances équivalentes mais bien plus simple d'utilisation et je suis tombée sur Actix qui à l'air de faire le café. Je regrette uniquement la reprise du annotation-driven-bullshit via les macros déclaratives mais en dehors de cela, tout va bien.
Exemple de hello world en Actix / Rust :
use actix_web::{get, web, App, HttpServer, Responder};
#[get("/")]
async fn index() -> impl Responder {
"Hello, World!"
}
#[get("/{name}")]
async fn hello(name: web::Path<String>) -> impl Responder {
format!("Hello {}!", &name)
}
#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| App::new().service(index).service(hello))
.bind(("127.0.0.1", 8080))?
.run()
.await
}
@Chlouchloutte je rebondis sur ton post (qui m'a fort bien aidé) et je te publie cet article de Cam Jackson sur le blog de Martin Fowler (merci à Philou pour le lien).
Dans l'idée, je comprends la notion de découpling entre les composants visuels mais il y a plein de choses qui me chiffonnent :
-
J'aime bien l'idée d'avoir un bundle unique où l’agrégation se fait au build. C'est certes contraignant vis-à-vis du cycle de release mais ça a le mérite de réduire le nombre de requêtes HTTP, de profiter des minifications globales, de mutualiser facilement les libs et de synchroniser leurs versions sans trop d'effort.
-
J'aime bien la solution au runtime via Web Component, mais il faut gérer le use-case des versions différentes, s'assurer que le bundle n'embarque par de libs partagées et de réduire le nombre de requêtes HTTP.
J'ai le sentiment que tant que nous n'avons pas une multitude d'équipes, les µ-Frontends sont encore trop jeunes pour être un concept vers lequel se tourner.