Deep Dive into PandApache3: Code de lancement

Vous êtes-vous déjà demandé a quoi ressemble un serveur web de l’intérieur ? Avez-vous déjà rêvé d'en créer un vous-même ? Vous êtes au bon endroit !

Bienvenue dans ce premier article technique consacré au développement de PandApache3.

Cet article et les suivants ont pour ambition de vous décrire le fonctionnement interne de PandApache3, un serveur web léger et minimaliste prêt à concurrencer Apache2 (Ici, nous sommes pour la retraite à 29 annuité).

Ces articles ne sont pas une documentation. Ils ne seront pas mis à jour au fil des évolutions de PandApache3. Leur objectif est plutôt de partager et d'expliquer du code et des choix de design.

Certaines parties du code seront simplifiées pour être plus digestes, afin de faciliter la compréhension générale de notre projet.

Avant d’aller plus loin, vous ne connaissez pas PandApache3 ? Vous pouvez si vous le souhaitez en apprendre plus en listant ce précédant article :

Que fait PandApache3 au démarrage du service ? Avant même d'accepter des requêtes HTTP et d'écouter sur un port, plusieurs tâches doivent être effectuées. Dans cette partie, nous nous concentrons sur les actions entreprises avant que la première connexion au service puisse être établie.

Notre méthode de démarrage s'appelle StartServerAsync, c'est la toute première méthode appelée lorsque notre serveur est lancé.

public static async Task StartServerAsync()

{

    Logger.Initialize();



    Server.STATUS = "PandApache3 is starting";

    Logger.LogInfo($"{Server.STATUS}");



    ServerConfiguration.Instance.ReloadConfiguration();



    _ConnectionManager = new ConnectionManager();



    TerminalMiddleware terminalMiddleware = new TerminalMiddleware();

    RoutingMiddleware routingMiddleware = new RoutingMiddleware(terminalMiddleware.InvokeAsync, fileManager);

    LoggerMiddleware loggerMiddleware = new LoggerMiddleware(authenticationMiddleware.InvokeAsync);

    Func<HttpContext, Task> pipeline = loggerMiddleware.InvokeAsync;



    await _ConnectionManagerWeb.StartAsync(pipeline);





}

La première étape consiste à initialiser notre logger. Le logger est une classe essentielle qui enregistre toutes les actions, erreurs et messages du serveur. C'est particulièrement crucial lors du démarrage, car il doit être prêt à signaler tout problème éventuel, comme illustré par l'enregistrement du statut "is starting" sur la troisième ligne.

Les informations de logs peuvent être disponibles à deux endroits selon la configuration choisie :

• Dans des fichiers de logs, qui est la configuration classique des services. Un fichier PandApache3.log est créé et chaque événement y est enregistré.


• Dans la console, ce qui est très utile pour voir les logs directement sur la sortie console ou le terminal, en complément ou en alternative aux fichiers de logs.

Ces deux options peuvent également être combinées, vous permettant ainsi de choisir comment vous souhaitez gérer vos logs selon vos besoins.

Entre nous

Pourquoi opter pour du NoLog ou des logs uniquement dans la console plutôt que dans un fichier ? À première vue, cela peut sembler étrange de ne pas conserver les logs dans un fichier. Cependant, cette décision est stratégique pour PandApache3, conçu pour être PaaS-friendly. Lorsque vous gérez une plateforme en tant que service (PaaS) avec des milliers d'instances, stocker les logs sur le serveur peut poser des problèmes d'accessibilité et d'espace disque. Il est donc plus judicieux de rediriger les logs générés par l'application depuis la console vers un système dédié tel que ADX ou Elastic Search.

Cette approche permet également d'obtenir rapidement des retours d'informations lors du développement de l'application.

Enfin, la possibilité d'utiliser NoLog avec PandApache3 (en désactivant l'écriture de logs à la fois dans le fichier et dans la console) est une conséquence directe de la flexibilité offerte par le service.

Plongée dans la configuration:

Le cœur de notre serveur PandApache3 réside dans son gestionnaire de connexion, représenté par l'objet ConnectionManager.

_ConnectionManager = new ConnectionManager();

Cet objet relativement simple possède deux attributs clés : le TcpListener et le pipeline.

public TcpListener Listener { get; set; }

private Func<HttpContext, Task> _pipeline;

Le TcpListenerest un composant fondamental qui permet aux clients de se connecter à notre serveur via le protocole TCP. Quant à notre variable _pipeline, elle représente une fonction asynchrone qui prend en paramètre un contexte HTTP (HttpContext) et retourne une tâche (Task). De manière imagée, notre pipeline est une série d'actions que nous souhaitons exécuter sur chaque requête HTTP. Chaque action est exécutée par ce que l'on appelle un Middleware.

Justement, dans la suite de notre code nous mettons en place les middlewares à utiliser pour chaque requête HTTP reçue :

TerminalMiddleware terminalMiddleware = new TerminalMiddleware();

RoutingMiddleware routingMiddleware = new RoutingMiddleware(terminalMiddleware.InvokeAsync);

LoggerMiddleware loggerMiddleware = new LoggerMiddleware(authenticationMiddleware.InvokeAsync);

Func<HttpContext, Task> pipeline = loggerMiddleware.InvokeAsync;

Nous avons donc trois middlewares ici :

• TerminalMiddleware


• RoutingMiddleware


• LoggerMiddleware

Chaque middleware appelle le suivant dans une chaîne bien définie (Logger appelle Routing, puis Routing appelle Terminal). Cette chaîne de middlewares (notre pipeline) est affectée à notre gestionnaire de connexion (ConnectionManager).

Maintenant que tout est en place, nous pouvons démarrer notre gestionnaire de connexion :

await _ConnectionManagerWeb.StartAsync(pipeline);

La fonction StartAsyncconfigure simplement notre TcpListenerpour écouter sur le port et l'adresse IP définis dans la configuration, puis le met en marche :

public async Task StartAsync(Func<HttpContext, Task> pipeline)

{

    Listener = new TcpListener(ServerConfiguration.Instance.ServerIP, ServerConfiguration.Instance.ServerPort);

    Logger.LogInfo($"Web server listening on {ServerConfiguration.Instance.ServerIP}:{ServerConfiguration.Instance.ServerPort}");

    Listener.Start();

    _pipeline = pipeline;

}

Voila, notre serveur est désormais démarré et prêt à recevoir des connexions entrantes.

Entre nous

Ce que font les middlewares n'est pas crucial pour le moment. Ce qu'il faut retenir, c'est que notre ConnectionManager, chargé de traiter les connexions reçues sur son TCP listener, les fera passer toutes à travers cette chaîne de middlewares et dans cet ordre.

Cependant, les noms sont assez explicites et vous pouvez deviner le rôle de chaque middleware :

• Logger : Enregistre la requête entrante dans les logs.


• Routing : Dirige la requête vers la bonne ressource.


• Terminal : Le dernier middleware dans la chaîne, qui ne fait rien de
  particulier mais qui est là.

Toujours entre nous

Une requête qui traverse les middlewares le fait à l'aller, mais aussi au retour (dans le sens inverse). Dans notre exemple, cela signifie que la requête est d'abord loggée par le premier middleware, puis la réponse obtenue est également loggée par ce même middleware devenu le dernier dans la chaîne.

Merci infiniment d'avoir exploré les coulisses de PandApache3 avec moi ! Vos réflexions et votre soutien sont essentiels pour faire évoluer ce projet. 🚀

N'hésitez pas à partager vos idées et impressions dans les commentaires ci-dessous. Je suis impatient d'échanger avec vous !

Suivez mes aventures sur Twitter et me rejoindre lors de sessions de codage en direct sur Twitch pour des sessions passionnantes et interactives. À bientôt derrière l'écran !