Je découvre un nouveau serveur web pour Rust. Bien plus rapide qu'Actix, son interfaçage avec le code est le même.
Je vais le tester et voir si cela vaut la peine de l'utiliser dans les nouveaux projets.
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
}
Pour @Lenny et @Kysofer qui doivent se servir de Netty.
EDIT 5: un cinquière tuto ici.
EDIT 4 : un quatrième tuto ici.
EDIT 3 : un troisième tuto ici.
EDIT 2 : un deuxième tuto ici.
EDIT : je viens de tomber sur ce tuto et quand je lis ce genre de code :
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.handler.codec.http.websocketx.BinaryWebSocketFrame;
import io.netty.handler.codec.http.websocketx.CloseWebSocketFrame;
import io.netty.handler.codec.http.websocketx.PingWebSocketFrame;
import io.netty.handler.codec.http.websocketx.PongWebSocketFrame;
import io.netty.handler.codec.http.websocketx.TextWebSocketFrame;
import io.netty.handler.codec.http.websocketx.WebSocketFrame;
public class WebSocketHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
if (msg instanceof WebSocketFrame) {
System.out.println("This is a WebSocket frame");
System.out.println("Client Channel : " + ctx.channel());
if (msg instanceof BinaryWebSocketFrame) {
System.out.println("BinaryWebSocketFrame Received : ");
System.out.println(((BinaryWebSocketFrame) msg).content());
} else if (msg instanceof TextWebSocketFrame) {
System.out.println("TextWebSocketFrame Received : ");
ctx.channel().writeAndFlush(
new TextWebSocketFrame("Message recieved : " + ((TextWebSocketFrame) msg).text()));
System.out.println(((TextWebSocketFrame) msg).text());
} else if (msg instanceof PingWebSocketFrame) {
System.out.println("PingWebSocketFrame Received : ");
System.out.println(((PingWebSocketFrame) msg).content());
} else if (msg instanceof PongWebSocketFrame) {
System.out.println("PongWebSocketFrame Received : ");
System.out.println(((PongWebSocketFrame) msg).content());
} else if (msg instanceof CloseWebSocketFrame) {
System.out.println("CloseWebSocketFrame Received : ");
System.out.println("ReasonText :" + ((CloseWebSocketFrame) msg).reasonText());
System.out.println("StatusCode : " + ((CloseWebSocketFrame) msg).statusCode());
} else {
System.out.println("Unsupported WebSocketFrame");
}
}
}
}
J'ai juste envie de pleurer (et je vais vous expliquer pourquoi). La programmation orientée objets reposent sur trois principes :
- L'encapsulation.
- Le polymorphisme.
- L'héritage (mais il faut l'oublier car c'est un anti-pattern).
Le polymorphisme, c'est le fait qu'une classe fille puisse se faire passer pour sa classe mère. L'idée étant que l'on doit organiser notre code de telle sorte que nous puissions TOUJOURS utiliser les super-types (classe mère abstraite ou interface). Or dès que l'on doit ajouter des conditions du type truc instanceof Class
c'est que l'on passe à côté du principale intérêt du polymorphisme : ne jamais avoir besoin de dépendre des implémentations.
Soyons clair, dans un code orienté objet je n'ai jamais eu besoin d'écrire des instanceof
et de toute ma vie, ce n'a dû m'arriver qu'une ou deux fois et parce que je dépendais d'un code aussi vieux que Java lui-même !
Bref, si vous codez en Java et que vous avez besoin des implémentations, pis encore des instanceof
et des casts, alors c'est que vous pensez en procédural et non en objet. Et pour tout ceux qui souhaitent apprendre à penser en objet, je les renvoie aux formations de Kysofer (car il m'a promis une com' si vous y aller de ma part :D) et il y a la pré-collection automne de Sezane qui me fait grave de l’œil si vous voulez...