Have you ever asked yourself how Gunicorn works internally?

How does it actually serve your application?

What exactly happens when you run the command gunicorn module:app?

Gunicorn is a Python web server with millions of downloads and is used in production by many Python applications.

If you’re curious about its internal workings — like a code walkthrough of what happens at each step, from running the Gunicorn command to handling a client request — this repo walks you through all of it, with references to the actual Gunicorn source code.

In particular, it may be useful if you:

• use Gunicorn in production and want a clearer mental model of its internals
• are curious about process models, worker management, and request handling
• want to learn from a real-world, battle-tested code base
• enjoy reading source code and understanding why certain architectural decisions were made

Start reading by clicking here.

Originally published at https://romualdoluwatobi.substack.com.

If you are using stateless token-based authentication in your apps, your refresh token flow probably looks like this:

1. The client makes a request to a protected resource using the access token.
2. An error occurs because the access token has expired.
3. You make another request to the server to request a new token pair using the refresh token.
4. Once you have the new tokens, you make a new request to retrieve the resource.

There’s nothing wrong with this process.

The goal is still to get the data or perform the action the user requested.

However, we end up making three requests instead of one, with three round trips (a round trip is a request from the client to the server and back).

Let’s consider your access token has a short expiration time, as recommended.

This means that most user interactions with your app could require at least six network calls -or three round trips-before we get the final data.

That’s three times what it would take without a refresh token process — two network calls, or one round trip.

Here, I’m talking in terms of network calls, but the real issue is latency.

For example, if a client-server round trip takes 400ms, serving a single client request could take more than 1.2 seconds (1200ms).

And this latency scales as more users interact with your service.

It’s not just about optimizing your endpoints or application; it’s about how your authentication flow works.

So the question is:

Is this latency a problem in your typical application?

If so, here’s one way to handle it:

• Server side: When issuing tokens, include both the expires_in and created_at fields.
• Client side: When you receive the tokens, store both expires_in and created_at along with he tokens.
• Before each request requiring the access token: Check whether the access token is about to expire based on created_at and expires_in.
• Only if it’s about to expire: Include the refresh token in a custom HTTP header along with the usual request headers.
• Server side during token verification: Check if the verification of the access token failed due to expiration only, everything else should be valid
• If everything else is valid:
• Look for the custom header containing the refresh token.
• If present, verify that it’s totally valid and correctly paired with the access token (for example, via the user identifier).
• Only then allow the request to proceed as if the access token were valid.
• While responding to the client, create a new token pair and include it in the response, either in headers or the response body.
• Client side: Whenever a response includes new tokens, replace the old tokens with the new ones

This approach reduces your flow from three RTTs (round trip time) to one RTT while maintaining refresh token functionality.

The flow above is about the refresh token process not how every requests should be authenticated and does not replace an existing mechanism like rotation or blacklisting.

Of course, this implementation requires control over your authentication code: having a more granular control — and can design it carefully — than if you rely solely on a component or lib that handles everything for you without customization.

Question: What do you think is the best way to handle refresh tokens without tripling response time and impacting user experience?

PS: When optimizing the flow, always remember: security > latency.

Originally published at https://romualdoluwatobi.substack.com.

Are you still trying to find the “perfect” web server to improve your app’s responsiveness?

In most cases, it doesn’t have a real impact on your production performance.

I say real impact because the web server is still important and can become a bottleneck. But most of the time, it isn’t. Your own code is.

The web server, framework, and surrounding tools you use to serve your app are ultimately there to run your application. The real behavior, performance, and scalability come from what your code does.

So why this reminder?

Developers often overthink:

• The right web server to use
• The perfect configuration
• The ideal deployment setup

And forget that the server’s primary job is to handle the network layer between you and the client. The rest is your responsibility.

Most modern web servers do that job extremely well-often better than we assume.

So when you want to optimize your app’s responsiveness, your first step should always be to investigate your own application code.

Before anything else.

If you’re building a web API, for example, focus on endpoint processing time. That’s where you have the most control.

Greater control → Greater impact.

Your web server is a component of the building. It’s not what will magically make your app faster.

Your code is.

Think about that before redesigning your architecture or switching tools.

Originally published at https://romualdoluwatobi.substack.com.

English version:

CPU-bound and I/O-bound Execution: Explained for Developers with Real-Life Examples

CPU-bound : Le programme passe la majorité de son temps à utiliser le processeur plutôt qu’à attendre des ressources externes comme le réseau. Ces tâches sont limitées par la vitesse du CPU, par exemple les programmes intensifs ou le traitement de grandes quantités de données.

I/O-bound : Le programme passe la majorité de son temps à attendre des ressources externes plutôt qu’à utiliser activement le CPU. Ces tâches sont limitées par les opérations d’input/output, comme les requêtes réseau ou l’accès au disque.

Si vous n’avez pas totalement compris les définitions précédentes, alors ce tutoriel a été conçu pour vous.

Plongeons dans le sujet étape par étape.

Qu’est-ce que le CPU et quand est ce que le CPU est il actif ?

Le CPU (Central Processing Unit, ou processeur) est le composant de votre système informatique chargé d’exécuter les instructions.

Les instructions sont générées à partir de programmes écrits dans des langages comme Python, C, Rust, etc. Ces programmes sont finalement traduits en code machine, qui est la forme compréhensible et exécutable par le CPU.

Pour simplifier, résumons le travail du CPU à des opérations arithmétiques et logiques.

Lorsque vous écrivez un programme en Python, C ou dans tout autre langage et que vous l’exécutez, ce programme est transformé en code machine. Le CPU exécute ensuite ce code machine en effectuant des opérations arithmétiques et logiques afin que le programme réalise les actions nécessaires et produise les résultats attendus.

Autrement dit, le CPU est le composant principal de votre machine responsable de l’exécution des instructions générées par vos programmes Python, C, Rust, etc.

Le CPU est considéré comme actif lorsqu’il effectue des opérations arithmétiques et logiques pour exécuter ce code machine.

En résumé : le CPU est le cœur de votre machine. Il exécute les programmes pour produire des résultats et est actif dès qu’il effectue des calculs et des opérations logiques.

Qu’est-ce que l’I/O et quand les opérations d’I/O ont-elles lieu ?

I/O signifie Input/Output (entrée/sortie). Cela désigne les situations dans lesquelles votre programme fournit une entrée à un composant sur lequel il a peu ou pas de contrôle, puis attend que ce composant lui retourne quelque chose en réponse : la sortie.

Au sens très large, même l’appel d’une simple fonction avec un paramètre et la récupération d’une valeur de retour peuvent être considérés comme un mécanisme d’input/output. Toutefois, dans ce tutoriel, nous nous concentrerons sur les opérations d’I/O pendant lesquelles le CPU n’effectue pas activement d’opérations arithmétiques ou logiques.

Par exemple :

• Lorsque votre programme utilise une API pour effectuer une opération liée aux fichiers, comme l’écriture sur le disque, vous réalisez une opération d’I/O. Vous fournissez une entrée (les données à écrire) et la fonction vous renvoie une sortie (par exemple une confirmation ou le nombre d’octets écrits).
• Lorsque votre programme, en tant que client, effectue une requête HTTP vers un serveur afin de récupérer des données, il s’agit également d’une opération d’I/O. Vous envoyez une entrée à travers le réseau et attendez une sortie : les données renvoyées par un serveur ou un système externe.

En résumé, une opération d’I/O se produit lorsque vous fournissez une entrée à un système que vous ne contrôlez pas directement et que vous attendez qu’il vous renvoie une sortie. Pendant une opération d’I/O, le CPU est considéré comme inactif, c’est-à-dire qu’il n’effectue pas de calculs arithmétiques ou d’opérations logiques.

Lors d’une exécution CPU, le CPU est actif et réalise des opérations arithmétiques et logiques. Lors d’une opération/exécution d’I/O, votre programme continue d’exister, mais le CPU est inactif pour cette tâche : il attend simplement que l’opération d’I/O se termine.

Jusqu’ici, nous n’avons pas encore parlé d’exécution CPU-bound et d’exécution I/O-bound. Jusqu’à présent, l’objectif était de vous donner une vision claire de ce qui se passe lors d’une exécution CPU et lors d’une exécution I/O — il ne faut pas les confondre.

Manger vs faire la lessive : une analogie réelle

Utilisons un exemple réel pour illustrer la différence entre une exécution CPU-bound et une exécution I/O-bound.

Exemple 1 : Faire la lessive avec une machine

Commençons par la lessive à l’aide d’une machine. Le processus est généralement simple : vous prenez vos vêtements, vous les mettez dans la machine avec ce qu’il faut, vous démarrez la machine en appuyant sur quelques boutons, puis vous attendez qu’elle fasse son travail.

Le temps d’attente peut durer plusieurs minutes, et vous n’avez aucun contrôle réel sur le moment où la machine aura terminé. Une fois le cycle terminé, vous récupérez vos vêtements propres.

Dans ce cas, pour que la tâche soit complétée, il faut vous, les vêtements et la machine.

Exemple 2 : Manger

Voyons maintenant le cas où vous mangez. Ici, il n’y a que vous et la nourriture. Une fois que vous commencez à manger, vous n’avez pas besoin d’attendre qu’un élément externe agisse pour terminer votre repas.

Vous pouvez faire des pauses — regarder la télévision, attendre que quelqu’un vous apporte quelque chose — mais la complétion du repas ne dépend pas explicitement de quelque chose d'autre. Elle dépend uniquement de vous.

Cela signifie également que vous pouvez terminer votre repas en quelques secondes ou en plusieurs minutes : vous êtes totalement maître du timing.

Dans ce cas, pour que la tâche soit complétée, il faut vous et la nourriture, et c’est vous qui décidez du rythme.

La différence en pratique

Rendons la distinction claire :

• Dans l’exemple de la lessive, vous lancez la tâche puis vous attendez qu’elle se termine, car le résultat final dépend d’un système externe sur lequel vous n’avez pas de contrôle direct, la machine.
• Dans l’exemple du repas, vous lancez la tâche et la terminez à votre propre rythme. Il n’y a aucune dépendance externe : c’est uniquement vous et la nourriture.

Le lien avec CPU-bound et I/O-bound

Si l’on transpose cette analogie à l’informatique:

• Manger représente une exécution CPU-bound. C’est une tâche active pendant laquelle du travail est continuellement effectué, tout comme un programme qui réalise principalement des opérations CPU (arithmétiques et logiques) avec peu ou pas de dépendance à des systèmes externes.
• Faire la lessive représente une exécution I/O-bound. Vous initiez la tâche en fournissant une entrée, puis vous attendez qu’un système externe fasse le travail, avant de récupérer le résultat (la sortie). Pendant ce temps, vous attendez bien plus que vous n’agissez — exactement comme un programme en attente d’une opération d’I/O.

(Sous l’hypothèse que vous ne faites rien d’autre pendant que la machine fonctionne.)

Une chose importante à savoir

Lorsque vous appelez un serveur distant avec une bibliothèque cliente, ou que vous interagissez avec des bases de données comme PostgreSQL ou MongoDB pour effectuer des requêtes, ou plus généralement lorsque vous effectuez un appel réseau, il se passe quelque chose d’important : dès que la requête réseau est initié, le CPU de votre système devient inactif et ne recommence à travailler que lorsque la réponse est disponible.

Le même principe s’applique lorsque vous lisez ou écrivez sur un disque (SSD, HDD, etc.).

Un concept similaire existe pour l’accès à la RAM, mais ici le temps d’accès est si court qu’il peut généralement être ignoré.

Je tenais à clarifier ce point, car il constitue souvent un obstacle qui empêche de bien comprendre la différence entre les exécutions CPU-bound et I/O-bound.

Lors d’un appel réseau ou d’une opération sur disque, après que le CPU a initié le processus, il reste inactif jusqu’à ce que l’opération soit terminée.

Qu’est-ce qu’une exécution CPU-bound et I/O-bound ? Ou, qu’est-ce qui rend un programme CPU-bound ou I/O-bound ?

Exécution CPU-bound :

Un programme est CPU-bound lorsqu’il passe la majeure partie de son temps à utiliser le CPU plutôt qu’à attendre des ressources externes comme le réseau. Ce sont des tâches limitées par la vitesse du CPU, comme les calculs intensifs ou le traitement massif de données.

Comportement du programme dans ce cas :
Le CPU est très actif, effectuant en continu des opérations arithmétiques et logiques, avec peu ou pas d’activité I/O.

Exécution I/O-bound :

Un programme est I/O-bound lorsqu’il passe la majeure partie de son temps à attendre des ressources externes plutôt qu’à utiliser activement le CPU. Ce sont des tâches limitées par les opérations d’input/output, comme les requêtes réseau ou l’accès au disque.

Comportement du programme dans ce cas :
Le programme réalise beaucoup d’opérations I/O (appels réseau, opérations sur disque) et passe beaucoup de temps à attendre des systèmes externes. L’utilisation du CPU est relativement faible, ce qui signifie que moins d’opérations arithmétiques et logiques sont effectuées.

J’espère que cela est clair et vous permet de bien comprendre la différence entre ces deux modes d’exécution.

Tous les programmes sont I/O-bound

D’accord, ne vous laissez pas confondre. Voici la vérité :

si l’on y regarde de plus près, même lors d’un programme CPU-bound, intensif en calculs, on utilise beaucoup la RAM. Et l’accès à la RAM est, techniquement, une opération I/O.

Alors, si toute exécution CPU-bound est implicitement I/O-bound, pourquoi fait-on cette distinction ?

La raison est que l’accès à la RAM est extrêmement rapide, si rapide que le temps d’accès peut généralement être ignoré. On parle de nanosecondes, comparées aux microsecondes ou millisecondes nécessaires pour accéder à un disque ou effectuer un appel réseau.

En comparaison, la différence est énorme. L’accès à la RAM peut être des milliers de fois plus rapide que l’accès à un disque, et les appels réseau sont encore beaucoup plus lents. C’est pour cela que l’on considère les programmes CPU-bound comme CPU-bound, malgré l’I/O implicite que représente l’accès à la RAM.

Pourquoi est-il important de connaître l’exécution CPU-bound et I/O-bound ?

Vous vous dites peut-être : « On a juste besoin d’écrire des programmes et de livrer des produits. Pourquoi se soucier de CPU-bound ou I/O-bound ? »

Vous n’avez pas tort. Si votre objectif est simplement d’écrire un programme qui fonctionne et produit un résultat, connaître ces distinctions peut sembler peu utile.

Mais dans les applications réelles, utilisées par de vraies personnes sur de vrais systèmes, la performance et l’optimisation ne sont pas un simple “plus”, elles sont au cœur du système, car elles impactent directement l’expérience utilisateur.

Et comment optimiser quelque chose si vous ne savez pas ce qu’il faut optimiser ou comment le système se comporte ?

Reprenons nos exemples du monde réel et voyons comment rendre les tâches plus rapides :

• Manger : Si vous voulez finir de manger plus vite, il vous suffit de manger plus vite. Vous êtes en plein contrôle, et vous êtes le goulot d’étranglement. Plus vous êtes rapide, plus la tâche se termine vite.
• Faire la lessive : Si vous voulez que la lessive soit terminée plus rapidement, vous ne pouvez rien faire pour accélérer la machine. Il faut optimiser la machine elle-même. Ici, c’est la machine qui est le goulot d’étranglement, et votre capacité ne change pas grand-chose.

Vous voyez la différence ? En comprenant la nature de la tâche, vous savez quoi optimiser pour atteindre votre objectif.

C’est la même chose pour les programmes. Dans les systèmes réels, si vous voulez que votre application soit réactive :

• Pour un programme CPU-bound, il peut être nécessaire d’ajouter plus de core CPU pour gérer davantage de calculs plus rapidement.
• Pour un programme I/O-bound, il peut être nécessaire de prioriser la concurrence et de paralléliser les appels réseau pour améliorer les performances.

Dans de nombreux systèmes, la vitesse n’est pas un simple bonus, elle est cruciale. Imaginez effectuer une recherche sur Google qui prend plusieurs secondes à répondre, ou faire défiler votre réseau social préféré alors que le contenu met plusieurs minutes à charger. Quelle serait votre réaction ?

Comprendre les exécutions CPU-bound et I/O-bound vous aide à prendre des décisions éclairées sur la manière d’optimiser votre programme selon vos objectifs.

Merci d’avoir lu !

Si vous êtes développeur Python et que vous voulez explorer les différences d’exécution entre threads et asyncio pour les tâches CPU-bound et I/O-bound, consultez cet article:

Python CPU et IO bound exécution: Asyncio vs Thread vs Sync

À bientôt !

Version française:

Exécution CPU-bound et I/O-bound : Explications pour Développeurs avec des Exemples Concrets

CPU-bound execution: The program spends most of its time using the processor rather than waiting for external resources such as the network. These are tasks limited by the speed of the CPU, like heavy calculations or intensive data processing.

I/O-bound execution: The program spends most of its time waiting for external resources instead of actively using the CPU. These are tasks limited by input/output operations, such as network requests or disk access.

If you did not fully understand the statements above, then this tutorial is for you.

Let’s dive into it step by step.

What is the CPU, and when does CPU execution happen (active)?

The CPU (Central Processing Unit) is the component of your computer system that executes instructions.

Instructions are generated from programs written in languages such as Python, C, Rust, etc. These programs are eventually translated into machine code, which is the form the CPU can understand and execute.

To simplify things, we can reduce the work done by the CPU to arithmetic and logic operations.

When you write a program in Python, C, or any other language and execute it, the program is transformed into machine code. The CPU then executes this machine code by performing arithmetic and logic operations so that your program can produce the expected results.

In other words, the CPU is the main component of your machine responsible for executing the instructions generated by your Python, C, Rust, or other programs.

The CPU is considered active when it is performing arithmetic and logic operations to execute this machine code.

Put simply: the CPU is the core component of your machine that executes programs to produce results, and it is active whenever it is performing arithmetic and logical computations.

What is I/O, and when does I/O execution happen?

I/O stands for Input/Output. It refers to situations where your program provides an input to a component over which it has little or no control, and then waits for that component to return something in response — the output.

In a very broad sense, even calling a simple function with a parameter and receiving a return value could be seen as an input/output mechanism. However, in this tutorial, we will focus on I/O execution during which the CPU is not actively performing arithmetic or logical operations.

For example:

• When your program uses an API to perform a file-related operation, such as writing data to disk, you are performing an I/O execution. You provide an input (the data to be written), and the function returns an output (such as a confirmation or the number of bytes written).
• When your program, acting as a client, makes an HTTP request to a server to retrieve data, this is also an I/O execution. You send an input over the network and wait for an output — the data returned by an external server or system.

In summary, I/O occurs when you provide an input to a system you do not directly control and wait for that system to produce an output. During an I/O execution, the CPU is inactive, meaning it is not performing arithmetic or logical computations.

During CPU execution, the CPU is active and performs arithmetic and logical operations. During an I/O execution, your program is still running, but the CPU is idle with respect to that task — it is essentially waiting for the I/O execution to complete.

So far, we haven’t yet discussed CPU-bound execution and I/O-bound execution, which is the main reason we are here. Up to this point, the goal was to give you a clear perspective on what happens during CPU execution versus I/O execution — don’t confuse the two.

Eating vs. Doing Laundry: a real-world analogy

Let’s use a real-world example to illustrate the difference between CPU-bound and I/O-bound execution.

Example 1: Doing laundry with a machine

Let’s start with doing laundry using a washing machine. The process is usually simple: you take your clothes, put them into the machine with everything needed, start the machine, and then wait for it to do its job after pressing a few buttons.

The waiting time can take several minutes, and you have no real control over when the process will finish. Once it’s done, you collect your clean clothes.

In this case, completing the task requires you, the clothes, and the machine.

Example 2: Eating

Now let’s consider the case of eating. Here, it’s just you and the food. Once you start eating, you don’t need to wait for something external to happen in order to finish your meal, right?

You might pause for distractions — watching TV or waiting for someone to bring something — but the completion of the task does not explicitly depend on something out of your control. It depends only on you.

This also means you can finish eating in a matter of seconds or take several minutes — it’s entirely under your control.

In this case, completing the task requires you and the food, and you decide everything else.

Spotting the difference

Let’s make the distinction clear:

• In the laundry example, you initiate the task and then wait for it to complete because the final result depends on an external system over which you have no direct control (the machine).
• In the eating example, you initiate the task and complete it at your own pace. There are no dependencies — it’s just you and the food.

Mapping this to CPU-bound and I/O-bound execution

If we map this analogy to computing:

• Eating represents a CPU-bound execution. It’s an active task where work is continuously being done, a program performing mostly CPU execution (arithmetic and logic) with little or no dependency on external systems.
• Doing laundry represents an I/O-bound execution. You initiate the task by providing an input, then you wait while an external system does the work, and finally you receive the result (the output). During this time, you are mostly waiting rather than actively doing work — just like a program waiting for I/O to complete.

(Assuming, of course, that you’re doing nothing else while the machine is running.)

One Important Thing You Need to Know

When you call a remote server using a client library, or interact with databases like PostgreSQL or MongoDB, performing queries, or more generally making any network request, something important happens: from the moment the network request is initiated, the CPU of your system becomes idle and only starts working again when the response comes back.

The same principle applies when you are reading from or writing to a disk (SSD, HDD, etc.).

A similar concept exists for accessing RAM, but here the access time is so short that it can generally be ignored.

I wanted to make this point clear because it is often a sticking point that can prevent a full understanding of CPU-bound vs. I/O-bound execution.

During a network request or disk operation, after the CPU initiates the process, it becomes idle until the operation completes.

What Is CPU-bound and I/O-bound Execution? Or, what makes a program CPU-bound or I/O-bound?

CPU-bound execution:

A program is CPU-bound when it spends most of its time using the CPU rather than waiting for external resources such as the network. These are tasks limited by the CPU’s speed, like heavy calculations or intensive data processing.

Behavior of the program in this case:
The CPU is highly active, continuously performing arithmetic and logic operations, with little or no I/O activity.

I/O-bound execution:

A program is I/O-bound when it spends most of its time waiting for external resources rather than actively using the CPU. These are tasks limited by input/output operations, such as network requests or disk access.

Behavior of the program in this case:
The program performs a high amount of I/O operations (network calls, disk operations) and spends a lot of time waiting for external systems. CPU usage is relatively low, meaning fewer arithmetic and logic operations are performed.

I hope this makes sense and helps you clearly understand the difference between these two execution modes.

Every Program Is I/O-bound

Okay, don’t let this confuse you. Here’s the truth:

if we look closely, even during a CPU-bound, CPU-intensive program, we are using RAM a lot. And accessing RAM is technically an I/O operation.

So if every CPU-bound execution is implicitly I/O-bound, why do we make a distinction?

The reason is that accessing RAM is extremely fast, so fast that the access time can generally be ignored. We are talking nanoseconds here, compared to microseconds or milliseconds for disk or network access.

By comparison, the difference is huge. Accessing RAM can be thousand of times faster than accessing a disk, and network calls are even slower by orders of magnitude. That’s why CPU-bound programs are considered CPU-bound, despite the implicit I/O involved in RAM access.

Why Does It Matter to Know About CPU-bound and I/O-bound Execution?

Right? You might be thinking: “We just need to write programs and ship products. Why worry about CPU-bound or I/O-bound execution?”

You’re not wrong. If your goal is just to write a program that runs and produces a result, knowing about these distinctions may not seem immediately helpful.

But in real-world applications, used by real people on real systems, performance and optimization are not just nice-to-have — they are at the heart of the system, because they directly impact user experience.

And how can you optimize something if you don’t know what to actually optimize or even how it behaves?

Let’s go back to our real-world examples and consider how we could make tasks faster:

• Eating: If you want to finish eating faster, the only way to achieve that is by eating faster yourself. You are in full control, and you are the bottleneck. The faster you are, the faster the task is completed.
• Laundry: If you want the laundry to finish faster, you cannot speed it up by doing anything yourself — you need to optimize the washing machine. Here, the machine is the bottleneck, and your speed doesn’t matter as much.

Do you see the difference? By understanding the nature of the task, you know what to optimize to achieve your goal.

It’s the same with programs. In real-world systems, if you want your application to be responsive:

• For CPU-bound programs, you might need to add more CPU cores to handle more computation.
• For I/O-bound programs, you might need to prioritize concurrency and parallelize network calls to improve performance.

In many systems, speed is not just a bonus — it is critical. Imagine performing a Google search that takes several seconds to respond, or scrolling through your favorite social media feed while content takes minutes to load. How would that feel?

Understanding CPU-bound and I/O-bound execution helps you make informed decisions about how to optimize your program for your desired outcomes.

Thanks for reading!

If you’re a Python developer and want to explore the differences in execution between threads and asyncio for CPU-bound vs. I/O-bound tasks, check out this article:

Python Concurrency Model Comparison For CPU And IO Bound Execution: Asyncio vs Threads vs Sync

See you there.

Pour les résultats complets du benchmark, rendez-vous ici (préparez un café et un peu de temps pour tout parcourir 😉) : https://github.com/Romulad/asyncio-vs-thread

Le projet utilise la version 3.12 de python

De la curiosité aux questions ? J’ai donc décidé de créer ce benchmark.

• Êtes-vous déjà demandé à quoi ressemblerait l’exécution d’asyncio à l’intérieur de plusieurs threads Python ?
• Ou encore entre threads et asyncio, lequel est réellement le plus performant ?

Oui, je sais — on nous a déjà donné les “bonnes” réponses :
Async pour l’I/O, threads pour la concurrence, sync pour la simplicité.

Mais, je voulais le voir de mes propres yeux.

Alors, j’ai réalisé cette expérience.

Et devinez quoi ?

Je m’attendais à ce que les threads python surpassent le code synchrone pour un programme lié au CPU… mais ils se sont révélés être les plus lents de tous.

Prêt ? Allons-y.

Les expériences

J’ai utilisé deux types d'exécutions:

• Exécution liée au CPU — purement computationnelle, sans I/O
• Exécution liée à l’I/O — avec de nombreuses requêtes HTTP, afin de mesurer la gestion de la concurrence et de la latence dans des scénarios réels.

À partir de là, j’ai comparé plusieurs modèles d’exécution — sync, asyncio, threads et une approche hybride (async + threads) — pour observer le comportement de chacun sous différentes conditions de charge.

Je ne montrerai ici que le graphique du temps d’exécution, mais vous pouvez consulter les expériences complètes et tous les graphiques ici.

CPU-Bound Task : Encodage de caractères

Programme: itérer sur 100 000 URL — string — et encoder chaque caractère afin de calculer sa représentation en octets.

Résultats clés:

• Synchrone : terminé en environ 9,77 s, utilisant presque un core CPU complet. Mémoire RAM stable (~16 Mo).
• Asyncio : temps d’exécution pratiquement identique (9,78 s) mais avec une utilisation mémoire 44 % plus élevée (~23 Mo). Asyncio augmente l'utilisation de la ram sans aucun gain de vitesse.
• Threading (10 threads) : plus lent (12,35 s), utilisant environ 1,1 core CPU. Le changement de contexte dégrade les performances — le threading est moins adapté aux tâches liées au CPU en Python à cause du GIL.

Pour les tâches CPU-bound, il est meilleure d'utiliser l’exécution synchrone ou le multiprocessing. Asyncio ajoute une surcharge mémoire sans bénéfice de performance, et le threading dégrade activement les performances à mesure que le nombre de threads augmente.

IO-Bound Task: Requêtes HTTP

Programme: je fais un get request vers plusieurs URL(10,000+) et enregistre les données de réponse.

synchrone

• 100 URL : 18,16 s (~180 ms/requête), CPU utilisé (~3 %), fiabilité parfaite.
• 1 000 URL : 182,84 s, montée en charge linéaire, utilisation CPU toujours très faible.

Observation : le programme synchrone reste inactif en attendant chaque requête. Le CPU est presque pas utilisé.

Asyncio

• 10 000 URL : 14,08 s — ≈130× plus rapide que la référence synchrone
• 100 000 URL : 117,47 s — toujours très rapide, débit ~1 647 Ko/s
  L’utilisation du CPU et de la mémoire évolue avec la concurrence, tout en conservant les même performances et fiabilité (faible taux de requête échoué).

Observation : asyncio gère efficacement des milliers de requêtes simultanées avec un minimum d’échecs et une utilisation des ressources maîtrisée.

Threading

• 100 threads : 50,01 s pour 10 000 URL (3,5× plus lent qu’asyncio, mais 36× plus rapide que le synchrone)
• 1 000 threads : 61,63 s — rendements décroissants, utilisation du CPU plus élevée et quelques échecs

Observation : les threads aident modérément mais sont limités. Trop de threads dégradent les performances.

Hybride : Asyncio + Threads

• 10 threads + asyncio : 14,96 s — similaire à asyncio pur, mais légèrement plus d’utilisation CPU et mémoire
• 100 threads + asyncio : 27,40 s — performance qui s’effondre, pic d’échecs des requêtes (7,2 %)
• 1 000 threads + asyncio : 33,20 s — performances catastrophiques, 56 % des requêtes échouent

Observation : l'approche hybride ajoute de la complexité sans aucun bénéfices.

Pour les tâches liées à l’I/O:

- asyncio est clairement le meilleur choix — offrant les meilleures performances (14,08 s), un excellent débit (1 435 Ko/s) et une bonne fiabilité (0,06 % d’échecs).

- Le threading peut convenir pour des besoins de concurrence modérés (≤100 threads), mais les performance se dégrade a mesure que le nombre de thread augmente.

- L’approche hybride complique les choses sans avantage.

- L’exécution synchrone ne doit être utilisée que pour des scénarios IO simples et à faible volume. (Si non ton programme risque de dormir 😂)

Envie de voir le benchmark complet ?

La suite complète de benchmarking, les scripts et les graphiques sont disponibles sur mon dépôt : https://github.com/Romulad/asyncio-vs-thread.

Vous pouvez exécuter les benchmarks liés au CPU et à l’I/O, ajuster le nombre de threads et explorer les données par vous-même.

Cela vous a été utile ? Faites-moi part de votre avis dans la section des commentaires.

Merci de votre lecture !

For the complete benchmark results and experiment, head over here (you will need some coffee and time to cover it all 😉): https://github.com/Romulad/asyncio-vs-thread

This project use python version 3.12

From wondering to questions — and then, this benchmark was born.

Have you ever asked yourself: what would it look like to run asyncio inside multiple Python threads? And between threads and asyncio, which one is actually more performant?

Yeah, I know — people have told us the “right” answers. Async for I/O, threads for concurrency, sync for simplicity. But I wanted to see it with my own eyes.

So, I built an experiment.

And guess what? I expected threads to outperform sync code in CPU-bound tests… but it turned out to be the slowest of all.

Ready? Let’s dive into it.

The Experiments

I used two workloads:

1. CPU-bound execution — pure computation, no I/O, to test raw execution performance.
2. IO-bound execution— heavy on HTTP requests, to measure real-world concurrency and latency handling.

From there, I benchmarked multiple execution models — sync, asyncio, threads, and hybrid (async + threads) approach — to see how each behaves under different stress conditions.

I will only show time execution plot in this post, you can read the full experiments and see all plots here.

CPU-Bound Tasks: Character Encoding

Workload: Iterating through 100,000 URLs, encoding each character to calculate its byte representation.

Key Findings

• Synchronous: Completed in ~9.77s, using almost a full CPU core. Memory stable (~16 MB)
• Asyncio: Virtually identical execution time (9.78s) but 44% higher memory usage (~23 MB). Asyncio adds overhead but no speed advantage.
• Threading (10 threads): Slower (12.35s), using ~1.1 CPU cores. Context switching slows down performance — threading is worse for CPU-bound tasks in Python due to the GIL.

For CPU-bound tasks, use synchronous execution or multiprocessing. Asyncio adds memory overhead without performance benefits, and threading actively degrades performance as the thread count increases.

IO-Bound Tasks: HTTP Requests

Workload: Fetching thousands of URLs from an HTTP server, storing response data.

Synchronous Execution

• 100 URLs: 18.16s (~180ms/request), CPU barely used (~3%), perfect reliability.
• 1,000 URLs: 182.84s, linear scaling, still very low CPU usage.

Observation: Sync program waits idle for each request.

Asyncio

• 10,000 URLs: 14.08s — ≈130x faster than sync baseline
• 100,000 URLs: 117.47s — still blazing fast, throughput ~1,647 KB/s
• CPU and memory usage scale with concurrency and performance and reliability remain excellent.

Observation: Asyncio handles thousands of concurrent requests efficiently with minimal failures and active resource usage.

Threading

• 100 threads: 50.01s for 10,000 URLs (3.5× slower than asyncio and 36× faster than sync)
• 1,000 threads: 61.63s — diminishing returns, higher CPU overhead, some failures

Observation: Threads help moderately but are limited by context switching. Too many threads hurt performance.

Hybrid: Asyncio + Threads

• 10 threads + asyncio: 14.96s — similar to pure asyncio, but slightly more CPU and memory usage
• 100 threads + asyncio: 27.40s — performance collapses, failures spike (7.2%)
• 1,000 threads + asyncio: 33.20s — catastrophic performance, 56% request failures

Observation: Hybrid approaches add complexity without benefits. Pure asyncio for IO-bound tasks, optionally offloading blocking tasks to a small thread pool (≤100 threads).

For IO-bound tasks, asyncio is the clear winner — offering the best performance (14.08s), excellent throughput (1,435 KB/s), and outstanding reliability (0.06% failure rate). Threading can work for moderate concurrency needs (≤100 threads) but shows diminishing returns beyond that. The hybrid approach adds complexity without benefits. Sync execution should only be used for simple, low-volume scenarios.

Want the Full Benchmark?

The full benchmarking suite, scripts, and plots are available in my repo: https://github.com/Romulad/asyncio-vs-thread

You can run CPU-bound and IO-bound benchmarks, tweak thread counts, and explore the data yourself.

Did you find this useful? let me know what you think in the comment section. Thanks for reading!

Rien de plus excitant que de pouvoir mettre en place un environnement avec une simple commande; c'est exactement ce que permet Docker Compose.

Vous définissez comment votre application et les composants nécessaires doivent être configurée dans un fichier, et avec une simple commande comme “docker compose up -d”, tout se met en marche.

Plus besoin, par exemple, de configurer manuellement votre service backend avec la base de données, le frontend, le serveur proxy web ou d'autres services.

Voici comment cela fonctionne globalement :

1. Vous définissez les fichiers Docker pour les différents services qui composent votre application et son déploiement.
2. À la racine du projet, vous créez un fichier compose.yaml qui contiendra la manière dont les images et les conteneurs de votre application seront mis en place, ainsi que tout autre paramétrage nécessaire.
3. Ensuite, avec une seule commande, Docker Compose s'occupera de construire vos images puis d'exécuter les différents conteneurs pour chaque image.

Pour en savoir plus :

• Docker
• Docker Compose

Une bonne compréhension de Docker et une idée générale de Docker Compose sont idéales.

Dans la suite, nous allons voir à travers deux exemples comment utiliser Docker et Docker Compose pour mettre en place ou déployer une infrastructure.

Les langages ou frameworks utilisés ne sont présents qu'à titre d'exemple, et vous pouvez appliquer le principe à n'importe quel langage ou framework.

Dans le premier exemple, nous allons mettre en place un environnement avec Next.js et Nginx. Ensuite, dans le second exemple, un autre composée de FastAPI, React, Redis et Nginx.

Ready?

Exemple 1 : Next.js et Nginx

Il s’agit d’un tableau de bord de crypto-monnaie réalisé avec Next.js. Vous pouvez le consulter ici.

Le dépôt GitHub est disponible ici .

Imaginons que l’on nous donne un serveur pour un simple déploiement de notre application de crypto-monnaie afin qu’elle soit accessible sur internet :

Première méthode

Nous devrons nous connecter au serveur et, manuellement, exécuter les commandes nécessaires étape par étape pour :

• Build notre application Next.js puis l’exécuter sur le serveur avec Node.js.
• Configurer un proxy comme Nginx, qui gérera les requêtes et les redirigera vers notre application Node.js. Pour comprendre pourquoi utiliser un proxy comme Nginx, vous pouvez lire cet article.

Deuxième méthode

Une fois connectés au serveur, nous aurons simplement besoin de configurer Docker et Docker Compose, puis de déployer l’application avec une simple commande. En résumé, le code source de l’application inclut les instructions pour son déploiement.

Après avoir cloné le dépôt, vous trouverez un dossier nommé docker, qui contient des fichiers Docker permettant d’exécuter notre application en mode développement ou production.

À l’intérieur du dossier docker, le fichier prod.Dockerfile sera utilisé pour créer l'image nécessaire à la génération du conteneur qui exécutera notre application Next.js en mode production.

Le contenu du fichier :

FROM node:lts as builder

WORKDIR /tokena

COPY package*.json ./

RUN npm i

COPY . .

RUN npm run build

# production stage
FROM node:22-alpine

WORKDIR /app

## needed in production for image optimization; check this for more info: https://nextjs.org/docs/messages/sharp-missing-in-production
RUN npm i sharp

RUN addgroup -S nextjs && adduser -S tokena -G nextjs
RUN mkdir .next && chown tokena:nextjs .next

COPY --from=builder --chown=tokena:nextjs /tokena/.next/standalone ./
COPY --from=builder --chown=tokena:nextjs /tokena/.next/static ./.next/static

USER tokena

ENV PORT=8080
ENV NODE_ENV=production

EXPOSE 8080

CMD [ "node", "server.js" ]

Le fichier prod.Dockerfile permet de faire un build du projet, puis d’exécuter le résultat en mode autonome avec Next.js. La commande pour lancer notre application dans le conteneur est node server.js.

Nous avons également un fichier nginx.Dockerfile dans le dossier docker, qui sera utilisé pour créer l’image servant à exécuter Nginx en tant que serveur proxy pour notre application Next.js.

Le contenu de nginx.Dockerfile :

FROM nginx:1.26.2-alpine
COPY nginx.site.conf /etc/nginx/conf.d/nginx.site.conf

Le fichier nginx.Dockerfile utilise l’image Docker officielle de Nginx et copie une configuration contenue dans le fichier nginx.site.conf dans le dossier conf.d de Nginx à l’intérieur de l’image docker.

Le fichier nginx.site.conf se trouve également à la racine du projet. Nous reviendrons sur son contenu plus tard.

Ainsi, nous avons la configuration Docker des deux services qui composent notre application. Cela suffirait pour effectuer un véritable déploiement et éviter les configurations manuelles sur un serveur.

Cependant, nous avons toujours un problème : il nous faudrait nous souvenir de chaque détail nécessaire pour construire nos images et exécuter les conteneurs. Imaginez la complexité si vous aviez une infrastructure avec plusieurs configurations Docker ?

C’est à ce moment que Docker Compose intervient. Avec un simple fichier YAML, il nous permet de créer plusieurs images et d’exécuter plusieurs conteneurs simultanément de manière automatique.

À la racine du projet, vous trouverez un fichier compose.yaml et un autre compose.prod.yaml.

Le fichier compose.yaml sert de fichier de base pour les configurations communes. Vous pouvez en savoir plus ici.

Dans le fichier compose.yaml, nous avons ceci :

name: tokena

services:
  nextjs:
    image: tokena
    env_file:
      - ./.env

Dans compose.prod.yaml, nous avons:

services:
  nextjs:
    build:
      context: .
      dockerfile: ./docker/prod.Dockerfile
    container_name: nextjs
    networks:
      - tokena-net

  nginx-server:
    image: nginx-server
    build:
      context: .
      dockerfile: ./docker/nginx.Dockerfile
    ports:
      - 80:80
    depends_on:
      - nextjs
    networks:
      - tokena-net

networks:
  tokena-net:
    driver: bridge

À l’intérieur d’un fichier Compose

Le fonctionnement de base d’un fichier Compose repose sur des services. Les services représentent les différents composants qui forment l’application dans son ensemble, y compris ceux nécessaires au déploiement, si besoin.

Dans notre configuration, nous avons deux services : nextjs, qui sert notre application, et nginx, qui joue le rôle de proxy pour le trafic entrant et sortant.

Ainsi, nous devons définir ces deux services dans notre fichier Compose.

Un fichier Compose utilise la syntaxe YAML pour la définition des configurations.

Voyons comment définir les services dans un fichier Compose avec la syntaxe YAML :

services:
  nextjs:
    build:
      context: .
      dockerfile: ./docker/prod.Dockerfile
    container_name: nextjs
    networks:
      - tokena-net

  nginx-server:
    image: nginx-server
    build:
      context: .
      dockerfile: ./docker/nginx.Dockerfile
    ports:
      - 80:80
    depends_on:
      - nextjs
    networks:
      - tokena-net

La directive services dans un fichier Compose nous permet de définir chaque service qui compose une application.

Chaque service doit spécifier comment l’image Docker de l’application sera construite, ainsi que les configurations et paramètres nécessaires pour exécuter le conteneur issu de l’image.

Ici, au niveau de la directive services, nous avons la définition de deux services : nextjs et nginx-server.

Pour le service nextjs:

nextjs:
    build:
      context: .
      dockerfile: ./docker/prod.Dockerfile
    container_name: nextjs
    networks:
      - tokena-net

• la directive build indique à Compose que l'image pour ce service doit être construite à partir du fichier prod.Dockerfile, qui se trouve dans le dossier docker à la racine du projet. Pour cela, nous utilisons la directive context à l'intérieur de la directive build avec la valeur . (point), pour indiquer à Compose que le contexte de construction est le dossier actuel. Ensuite, avec la directive dockerfile, nous spécifions où se trouve le fichier Docker à utiliser pour la construction de l'image.
• Après avoir défini comment l’image doit être construite, la directive container_name permet de spécifier que le conteneur issu de cette image doit être nommé nextjs.
• Enfin, avec la directive networks, nous indiquons à Compose que le conteneur issu de notre image doit être exécuté dans un réseau appelé tokena-net. Ici, vous pouvez spécifier plusieurs réseaux en ajoutant des tirets et en indiquant le nom de chaque réseau.

Et voilà, nous venons de définir notre service pour exécuter Next.js.

En plus de Next.js, nous avons également un autre service, nommé nginx-server, défini sous la directive services de Compose, comme ceci:

nginx-server:
    image: nginx-server
    build:
      context: .
      dockerfile: ./docker/nginx.Dockerfile
    ports:
      - 80:80
    depends_on:
      - nextjs
    networks:
      - tokena-net

Pour le service nginx-server, nous indiquons à Compose :

• que l’image de notre service doit être nommée nginx-server à l'aide de la directive image.
• que l’image doit être construite à partir du fichier nginx.Dockerfile, qui se trouve dans le dossier docker à la racine du projet, et que le build context doit être le dossier courant où se trouve le fichier Compose lui-même.
• avec la directive ports, nous indiquons à Compose une liste de ports sur lesquels notre service sera accessible publiquement. Ici, nous avons spécifié le port 80.
• avec la directive depends_on, nous spécifions une liste de services dont le service actuel dépend. En d'autres termes, le service nginx-server chargé d'exécuter Nginx dépend du service nextjs. Cela signifie qu'avant que le conteneur du service Nginx ne soit exécuté, le conteneur du service nextjs doit déjà être en marche.
• encore une fois, avec la directive networks, nous indiquons à Compose que le conteneur issu de notre image doit être exécuté dans un réseau appelé tokena-net. Ici, vous pouvez spécifier plusieurs réseaux en ajoutant des tirets et en indiquant le nom de chaque réseau.

Super ! Nous avons maintenant la définition des deux services qui composent notre application.

Après la définition de nos services sous la directive services de Compose, nous avons une autre directive appelée networks.

Petit récapitulatif sur les réseaux

Après avoir créé une image et exécuté le conteneur issu de cette image, le conteneur s’exécute par défaut en isolation, c’est-à-dire qu’il n’est pas accessible par d’autres applications sur le système.

Pour permettre à d’autres applications de communiquer avec l’application qui s’exécute à l’intérieur du conteneur, on expose le port du conteneur où l’application est accessible.

L’exposition du port ouvre par défaut l’application à l’intérieur du conteneur au public, ce qui permet à toute application ou client ayant accès au système d’accéder également à l’application dans le conteneur.

Cependant, il arrive parfois que nous ne voulions pas que notre service soit accessible publiquement, et que seuls des services vérifiés puissent y accéder, comme d’autres conteneurs.

Dans ce cas, nous pouvons utiliser les réseaux Docker pour créer un cadre où deux conteneurs (ou plus) peuvent communiquer entre eux et échanger des données, tout en rendant cette communication non accessible publiquement.

Avec ceci dans notre fichier compose:

networks:
  tokena-net:
    driver: bridge

Nous créons un réseau appelé tokena-net en utilisant le conducteur (driver) bridge. Pour en savoir plus sur les réseaux, consultez cette documentation : Docker Engine Networking.

Avec cela, tout conteneur auquel nous assignons le réseau tokena-net pourra communiquer avec d’autres conteneurs du même réseau en utilisant le nom du conteneur.

Dans notre configuration, nous ne voulons pas que notre application Next.js soit accessible publiquement, mais uniquement le serveur web Nginx.

Pour ce faire, nous créons le réseau tokena-net, puis nous plaçons le conteneur exécutant l’application Next.js et le conteneur exécutant le serveur web Nginx dans le même réseau.

De cette manière, le conteneur exécutant Nginx pourra directement communiquer avec le conteneur exécutant Next.js en utilisant le nom du conteneur, sans avoir besoin d’exposer de port publiquement.

Nous exposons ensuite publiquement le conteneur exécutant Nginx sur le port 80, comme indiqué lors de la définition du service un peu plus tôt.

Revenons à la configuration de Nginx

Comme je l’avais mentionné, nous allons revenir sur le fichier nginx.site.conf. Ce fichier contient la configuration qui permet à Nginx de se comporter en tant que proxy pour notre application Next.js.

Le contenu du fichier nginx.site.conf est le suivant :

server {
    listen 80;
    server_name localhost *.play-with-docker.com;

    location / {
        proxy_pass http://nextjs:8080;
        proxy_set_header Host      $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

En savoir plus sur Nginx ici : Guide pour débutants de Nginx

Dans la configuration, portez attention à la ligne suivante :

proxy_pass http://nextjs:8080;

En gros, avec cette ligne, nous indiquons à Nginx que l’application pour laquelle il fait office de proxy se trouve à l’adresse http://nextjs:8080. De cette manière, lorsqu’il recevra une requête de l’extérieur, il la redirigera vers http://nextjs:8080.

Que constatez-vous dans l’adresse ?

Le nom de domaine utilisé est celui du conteneur qui exécute l’application Next.js. Nous l’avions défini lors de la configuration du service Next.js dans le fichier compose.

Super, nous sommes prêts à exécuter notre application !

Mais avant suivez le README ici pour plus de détails.

Il vous suffit de lancer la commande suivante à la racine du projet :

docker compose -f compose.yaml -f compose.prod.yaml up -d

Ensuite, vous pouvez accéder à l'application via http://localhost.

Exemple 2 : FastAPI, React, Redis et Nginx

Il s’agit d’une application de discussion instantanée que nous allons configurer avec Docker et Docker Compose.

Le dépôt GitHub.

Voici le fichier compose, essayez de l’expliquer par vous-même avant de continuer :

 name: open-chat-app
  
services:
  redis:
    image: redis:7.4.1-alpine
    container_name: redis
    restart: always
    networks:
      - open-chat-net

  api:
    image: api
    build:
      context: ./api
      dockerfile: ../docker/api.Dockerfile
    container_name: api
    networks:
      - open-chat-net
    env_file:
      - ./api/.env
    depends_on:
      - redis
    restart: on-failure:10
    
  web:
    image: web
    build:
      context: ./web
      dockerfile: ../docker/web.Dockerfile
    container_name: web
    networks:
      - open-chat-net
    depends_on:
      - api
      - redis
    restart: on-failure:10
  
  nginx:
    image: nginx-server
    build:
      context: ./nginx
      dockerfile: ../docker/nginx.Dockerfile
    container_name: nginx
    networks:
      - open-chat-net
    ports:
      - 80:80
    depends_on:
      - api
      - web
    restart: on-failure:5

networks:
  open-chat-net:
    driver: bridge

À travers le fichier compose, on peut voir qu’il y a au total 4 services : redis, api, web et nginx.

Après avoir cloné le projet, vous trouverez :

• Un dossier api, où se trouve l’application FastAPI, notre API qui utilise Redis comme base de données structurée.
• Un dossier web, qui contient le front-end de l’application, construit avec React.
• Un dossier docker, qui contient les différents fichiers Docker de l’application.
• Un fichier compose.yaml.

Le principe reste le même que précédemment : ces quatre services sont dans le même réseau, et seul le service nginx est accessible publiquement sur le port 80.

Je vous laisse jeter un coup d’œil au fichier compose pour solidifier votre compréhension.

J’espère que vous avez appris quelque chose et que cela vous a été utile.

Passez une merveilleuse année, pleine de progrès et de santé !

Merci de m’avoir lue 🤗

Code splitting : C’est le processus de rendre un composant React lorsqu’il doit être rendu, ni trop tôt, ni trop tard. Cela réduit ainsi le temps de chargement des fichiers JS par le navigateur.

Lorsque vous accédez à une application créée avec React, par défaut, le serveur renvoie tous les fichiers JavaScript qui composent l’application en entier à votre navigateur, qui à son tour fait des requêtes pour charger ces fichiers et afficher votre application.

Ce comportement est acceptable lorsque vous développez une landing page avec React, mais il dégrade les performances lorsqu’il s’agit d’une application avec plusieurs fichiers JavaScript, une application avec plusieurs pages.

Idéalement, vous souhaitez que seuls les fichiers et les composants nécessaires pour afficher la page qu’un visiteur consulte à un instant T soient rendus par le navigateur, et non tous les fichiers JavaScript et les composants de votre application, ce qui est le comportement par défaut.

C’est exactement à ce moment que le code splitting entre en jeu. C’est le processus de rendre un composant React lorsqu’il doit être rendu, ni trop tôt, ni trop tard, exactement lorsque l’utilisateur en a besoin. Cela réduit ainsi le temps de chargement des fichiers JS par le navigateur.

React.lazy

Pour servir uniquement le nécessaire à l’utilisateur, on utilise la fonction lazy de React qui nous permet de charger un composant en mode paresseux.

Au lieu d’utiliser les importations de manière traditionnelle pour les composants avec import, on utilise lazy de React avec l’import de JavaScript.

Traditionnellement :

import Component from "./component"

Avec lazy de React :

const Component = lazy(() => import("./component"))

Avec lazy, le composant sera importé, donc chargé, une seule fois et uniquement lorsqu’une partie de l’application essaiera de le rendre.

Fonctionnement :

• lazy prend en entrée une fonction qui retourne une Promise ou un objet JavaScript avec la méthode then.
• lazy renvoie la valeur .default de la Promise en tant que composant React. Cela signifie que le composant doit être exporté avec le mot-clé default depuis le fichier où il a été défini.
• La valeur retournée par lazy est un composant qui peut être affiché dans l’application.

Ceci étant dit, voyons un exemple concret avec un site créé avec React.

Nous allons sur une landing page qui a été construite avec React.

Lien GitHub : lien

L’application par défaut n’utilise pas lazy pour importer les composants React, ce qui est normal car il s’agit d’une application à une seule page.

Nous allons supposer que nous voulons que les composants qui composent l’application soient chargés uniquement pendant que l’utilisateur est en aura besoin. Nous allons également observer les performances avant et après l’utilisation de lazy au niveau du navigateur.

L’application par défaut charge tous les composants lors du premier chargement du site.

Commencez le serveur avec npm run dev à l'intérieur du dossier de l'application. L'application est configurée avec Vite par défaut.

Visitez l’URL affichée avec votre navigateur web. Pour cet exemple, je vais utiliser Chrome.

Maintenant, ouvrez les outils de développement. Cliquez avec le bouton droit de la souris et choisissez “Inspecter”.

Ensuite, allez à l’onglet “Network” (Réseau) et sélectionnez uniquement l’onglet concernant JavaScript (JS) comme ceci :

Lorsque vous allez ouvrir l’onglet Network pour la première fois, il se peut que vous ne voyiez rien. Rafraîchissez la page pour voir les informations, comme sur l’image.

Au niveau du tableau qui s’affiche, intéressez-vous spécifiquement à deux colonnes : name, type, et plus spécifiquement au type script.

Au niveau de la colonne name, vous verrez plusieurs fichiers js, jsx avec le type script ont été chargés par Chrome. Immédiatement et à mesure que vous faites défiler, vous verrez les noms des fichiers tels que : Header.jsx, RecentWork.jsx, WhyUs.jsx, Services.jsx, etc.

Tous les composants qui composent le site ont été chargés par le navigateur pour pouvoir afficher la page.

Faisons une expérience où nous allons supposer que les composants sont rendus sous condition et que cette condition est fausse pour certains composants, ainsi ils ne doivent pas être affichés.

À partir du fichier main.jsx, rendez-vous dans le composant Home, et remplacez le code de tout le fichier par ce code :

import React, { useEffect, useRef, useState } from "react";
import Header from "../header/Header";
import IntroSection from "../introSection/IntroSection";
import Trust from "../Trust";
import HowItWork from "../howitwork/HowItWork";
import Services from "../services/Services";
import WhyUs from "../why-us/WhyUs";
import RecentWork from "../recentWork/RecentWork";
import Help from "../help/Help";
import Process from "../process/Process";
import ClientReviews from "../reviews/ClientReviews";
import FooterSection from "../FooterSection";
import "./main.css";
import { isVisibleByC } from "../../utils";

export function MessageContainer({msgColor, setMessageActive}){
    const containerRef = useRef(null);
    const progressRef = useRef(null);
    const [msg, colorClass] = msgColor.split(';');

    useEffect(()=>{
        setTimeout(() => {
            let increment = 10;
            let progressWait = (msg.length/1.3) * 10;
            containerRef.current.classList.add('show-message');
            let current = 10;
            
            let int = setInterval(() => {
                    if(current >= 100){
                        clearInterval(int)
                    }else{
                        progressRef.current.style.width = `${current + increment}%`;
                        current += increment
                    }
            }, progressWait);

            setTimeout(() => {
                containerRef.current.classList.add('hide-message');
                containerRef.current.classList.remove('show-message');
                setTimeout(() => {
                    setMessageActive('')
                }, 200);
            }, progressWait*increment*1.2);

        }, 300);       
    }, [])

    return(
        <div className={`message ${colorClass}`} ref={containerRef}>
            <p className="mb-0 p-3">
                {msg}
            </p>

            <div className="message-border mt-3" >
                <div className="message-border-inner" ref={progressRef}></div>
            </div>
        </div>
    )
}

export default function Home(){
    const [messageActive, setMessageActive] = useState([]);
    const firstInputRef = useRef(null)

    useEffect(()=>{
        document.addEventListener('scroll', ()=>{
            document.querySelectorAll('.Tr-1').forEach((el)=>{
                if(isVisibleByC("", el.id, false, true)){
                    el.classList.add('An-4')
                }
            });
        });
    }, [])

    function onContactBtnClick(){
        firstInputRef.current.focus();
    }

    function messages(){
        let msgCount = 0;
        if(messageActive){
            const allMessages = messageActive.map((msgColor)=>{
                let key = `${msgCount}-${msgColor}`
                msgCount += 1;
                return(
                    <MessageContainer 
                        msgColor={msgColor}
                        setMessageActive={setMessageActive}
                        key={key}
                    />
                )
            })
            return allMessages
        }
        return(
            <></>
        )
        
    }
    const messageResult = messages();
    
    return(
        // avoid rendenring some components
        <>
            <Header onContactBtnClick={onContactBtnClick}/>
            <IntroSection 
            setMessageActive={setMessageActive}
            firstInputRef={firstInputRef}/>
            { false && <Trust /> }
            { false && <HowItWork onContactBtnClick={onContactBtnClick}/> }
            { false && <Services onContactBtnClick={onContactBtnClick}/> }
            { false && <WhyUs /> }
            { false && <RecentWork /> }
            { false && <Help /> }
            { false && <Process /> }
            { false && <ClientReviews onContactBtnClick={onContactBtnClick}/> }
            { false && <FooterSection /> }
            {messageResult}
        </>
    )
}

J’ai explicitement utilisé le mot-clé false de JavaScript pour éviter que ces composants ne soient rendus par le navigateur.

D’abord, videz tout le cache de votre navigateur pour voir les choses actuelles.

Ensuite, rafraîchissez la page et vous devriez voir que seules deux sections s’affichent dans votre navigateur : le menu et la première section de la page.

Mais chose surprenante, si vous vous rendez dans votre outil de développement au niveau de Network, vous verrez que tous les fichiers précédents ont été chargés par le navigateur juste pour afficher nos deux sections.

Ajoutons le lazy load à l’importation de nos composants pour voir ce qui se passe.

La partie qui changera est les importations, comme ceci :

import React, { useEffect, useRef, useState, lazy } from "react";
import "./main.css";
import { isVisibleByC } from "../../utils";

const Header = lazy(() => import("../header/Header"));
const IntroSection = lazy(() => import("../introSection/IntroSection"));
const Trust = lazy(() => import("../Trust"));
const HowItWork = lazy(() => import("../howitwork/HowItWork"));
const Services = lazy(() => import("../services/Services"));
const WhyUs = lazy(() => import("../why-us/WhyUs"));
const RecentWork = lazy(() => import("../recentWork/RecentWork"));
const Help = lazy(() => import("../help/Help"));
const Process = lazy(() => import("../process/Process"));
const ClientReviews = lazy(() => import("../reviews/ClientReviews"));
const FooterSection = lazy(() => import("../FooterSection"));

Encore une fois, assurez-vous de vider le cache de votre navigateur ou simplement d’ouvrir un nouveau navigateur.

Rendez-vous dans votre outil de développement dans Network, puis rafraîchissez la page à nouveau. Vous devez voir que les fichiers chargés par le navigateur ont drastiquement diminué, comme le montre l’image :

Il n’y a plus de RecentWork.jsx, WhyUs.jsx, Services.jsx, etc., mais uniquement ceux que nous avons voulu afficher par défaut.

Il s’agissait de rendre le code quand il le faut, au moment idéal.

Rappelez-vous que trop utiliser quelque chose n’est pas toujours une bonne idée ; utilisez lazy quand il le faut, et non pour importer tous vos composants.

Cas d’utilisation

C’est encore plus important lorsque vous développez une application avec plusieurs routes, une application divisée en plusieurs pages accessibles avec des URLs, en utilisant par exemple react-router.

Vous ne voulez pas que lorsque l’utilisateur visite une page, toute l’application soit chargée par le navigateur, mais uniquement ce qui est en train d’être vu par l’utilisateur.

Rien de plus simple pour améliorer les performances.

De plus, il est souvent très utile d’utiliser le composant suspense de React afin de notifier à l’utilisateur que quelque chose est en train de se faire en arrière-plan.

Le principe est que lorsque vous utilisez lazy pour importer des composants, vous devez utiliser suspense pour englober toute votre application afin d’afficher un rappel lorsque des opérations asynchrones se feront en arrière-plan, comme ceci :

ReactDOM.createRoot(document.getElementById('root')).render(
  <React.StrictMode>
    <Suspense fallback="Loading....">
      <Home />
    </Suspense>
  </React.StrictMode>,
)

Le fallback peut être un composant React.

Pour finir, il est souvent hyper utile de créer une Error Boundary lorsque vous utilisez lazy, afin de notifier l’utilisateur lorsqu’une erreur survient au niveau du chargement du composant ou à l’intérieur.

Lorsque vous utilisez react-router, ceci est pris en charge.

Pour l’implémenter manuellement, vous devrez créer un composant basé sur les classes. Je vous encourage à faire plus de recherches sur les Error Boundaries.

Abonnez-vous ici pour les prochains articles. Retrouvez-moi sur GitHub ici.

Merci et à la prochaine !

Auteur

Romuald Oluwatobi, développeur Django et ReactJS. Besoin d’un développeur compétent ? Je vous accompagne dans la création d’une application web moderne dans l’atteinte de vos objectifs business.

Il est courant lors du développement d’applications que, lorsqu’un événement spécifique se produit, des actions doivent en découler.

Des événements peuvent être :

• La création d’un nouvel utilisateur
• Le début d’une requête HTTP venant du client
• La fin d’une requête HTTP prête à être envoyée au client
• La suppression d’un objet de la base de données
• Etc.

Imaginons que, pour l’événement de création d’utilisateur, vous souhaitiez effectuer plusieurs actions, comme créer des informations supplémentaires, ajouter l’utilisateur à un groupe, envoyer un email, et d’autres actions spécifiques pour le bon fonctionnement de votre application.

De manière traditionnelle, vous allez créer des méthodes ou des fonctions responsables de ces actions, et chaque fois que vous créez un utilisateur dans votre application, que ce soit depuis l’interface principale ou ailleurs, il faudra vous rappeler d’exécuter ces fonctions ou méthodes. Ou, dans le cas où les logiques dépendent les unes des autres de manière à ce qu’une fonction/méthode doive s’exécuter avant qu’une autre ne le fasse, il faudra vous rappeler de cela minutieusement.

Vous comprenez déjà l’idée : se rappeler de toutes les actions nécessaires à exécuter et de l’ordre d’exécution après qu’un événement spécifique s’est produit. Vous devez sûrement avoir des souvenirs si vous avez déjà été dans une telle situation.

Maintenant, imaginez un système où Django vous donne la possibilité d’être notifié lorsqu’un événement qui vous intéresse se produit dans votre application. Cela signifie que vous n’avez plus besoin de vous rappeler manuellement de tout ce qu’il faut faire après qu’un événement spécifique s’est produit. Par exemple, lorsque vous créez un utilisateur manuellement, vous n’avez plus besoin de vous rappeler de toutes les méthodes/fonctions à appeler, Django s’en charge.

De manière simple, vous dites à Django : lorsque telle ou telle chose se produit dans mon application, je veux que tu appelles cette fonction X. Encore plus simple, au lieu de simplement créer une fonction que vous devrez vous rappeler d’appeler, vous créez la fonction et lui donnez la possibilité d’être appelée (notifiée) lorsqu’un événement spécifique se produit.

Pas génial ? C’est à cela que servent les signaux dans Django. Ils vous permettent d’enregistrer une fonction qui sera appelée lorsqu’un événement se produit dans votre application, comme la création d’un modèle utilisateur.

Voyons comment tout cela fonctionne concrètement. Nous allons créer une fonction qui sera appelée en réponse à un événement spécifique.

Note : Lorsque je parle d’événement, d’action ou de signal, je parle typiquement de la même chose. Vous pouvez vous référer à celui que vous comprenez déjà.

Création d’un récepteur

Le système est divisé en deux parties : les émetteurs (senders) et les récepteurs (receivers). Un émetteur émet un événement et appelle (notifie) le(s) récepteur(s) (fonctions) qui se sont enregistrés pour cet événement.

Le processus commence par la création d’une fonction ou méthode réceptrice qui doit être appelée lorsqu’un événement se produit dans votre application. Comme ceci :

def my_receiver(sender, **kwargs):
    print("I'll be called in response to an event")

Une fonction/méthode réceptrice :

• Prend en premier argument le sender, l'objet Python qui émet l'événement en question.
• Prend un **kwargs, qui contient les arguments que l'émetteur peut potentiellement passer aux récepteurs. Potentiellement, car il peut arriver que certains émetteurs n'incluent pas d'argument. Mais Django nous impose de toujours mettre cet argument, car un récepteur doit être en mesure d'accepter des arguments à tout moment.

Après la création de la fonction réceptrice, nous avons maintenant besoin d’un moyen pour l’enregistrer en tant que récepteur pour l’événement ou l’action souhaitée. Pour ce faire, nous pouvons utiliser le décorateur receiver de Django, comme ceci :

@receiver(signal, **kwargs)
def my_receiver(sender, **kwargs):
    print("I'll be called in response to an event")

Le décorateur :

• Prend un événement/signal ou une liste d’événements/signaux auxquels la fonction réceptrice qu’il décore doit répondre.
• Prend des **kwargs pour les arguments supplémentaires à passer à la fonction réceptrice.

Et la dernière étape est de modifier la fonction ready dans la configuration de notre application pour que Django prenne connaissance de notre fonction réceptrice.

La fonction my_receiver sera appelée chaque fois que le signal passé à la fonction receiver de Django sera déclenché. Et c'est tout ce qu'il faut pour éviter les maux de tête liés à l'appel de fonctions en réponse à une action spécifique dans Django.

Cool, voyons un cas concret avec un projet Django où nous allons créer une fonction réceptrice qui sera appelée en réponse à la création d’un nouvel utilisateur dans notre application.

Le code final se trouve ici sur GitHub : lien

Nous allons commencer avec un environnement virtuel, installer Django et exécuter :

django-admin startproject .

Ensuite, je vais créer une nouvelle application Django que je vais appeler user :

django-admin startapp user

Enregistrer l’application au niveau des paramètres .

Nous allons créer un nouveau modèle utilisateur que je vais appeler MyUser, qui héritera de django.contrib.auth.models.AbstractUser, dans le fichier models.py de la nouvelle application créée.

Ajoutez cette ligne au niveau des paramètres pour enregistrer le modèle en tant que modèle utilisateur par défaut :

AUTH_USER_MODEL = "user.MyUser"

Ou adaptez-la en fonction si vous n’avez pas utilisé les mêmes noms que moi.

Enfin, exécutons makemigrations et migrate pour appliquer les migrations dans la base de données.

Passons maintenant à la création de nos récepteurs. Pour cela, dans l’application user, je vais créer un dossier que je vais nommer signals, et à l'intérieur de ce dossier, je vais créer un nouveau fichier que je vais appeler model_signals.py. La structure du projet ressemblerait à quelque chose comme ceci :

Dans ce fichier, nous allons définir une fonction qui ajoutera un nouveau utilisateur créé à un groupe appelé “favorite_user”.

Nous devons nous intéresser à l’événement/signal qui sera déclenché lorsqu’un nouvel enregistrement du modèle MyUser se fera dans notre base de données.

Pour cela, nous utilisons le signal django.db.models.signals.post_save, qui nous permet d'être notifiés lorsqu'un nouvel enregistrement est effectué dans la base de données pour un modèle particulier.

Commençons par importer le signal et le décorateur de fonction receiver avec ces lignes :

from django.dispatch import receiver
from django.db.models.signals import post_save

Continuons maintenant avec la définition de notre fonction réceptrice. Je vais l’appeler add_user_to_group, comme ceci :

def add_user_to_group():
    pass

Rappelez-vous, notre fonction réceptrice doit prendre des arguments : le sender et **kwargs. Réécrivons-la ainsi :

def add_user_to_group(sender, **kwargs):
    pass

Pour être reconnue en tant que récepteur, elle doit être décorée par la fonction django.dispatch.receiver de Django. Cette fonction prend en argument le signal/événement pour lequel notre fonction doit être appelée. Dans notre cas, nous voulons que la fonction soit appelée après la création d'un nouvel utilisateur.

C'est pourquoi nous utilisons le signal post_save (django.db.models.signals.post_save), qui est déclenché chaque fois qu'un modèle est enregistré dans la base de données.

Donc, notre définition sera maintenant avec le décorateur receiver comme ceci :

@receiver(post_save)
def add_user_to_group(sender, **kwargs):
    pass

Constatez-vous un problème ? Oui ?

Nous voulons que notre récepteur soit appelé uniquement lorsqu’un nouvel utilisateur est ajouté à notre base de données, pas lorsque n’importe quel modèle enregistre un nouvel enregistrement. N’est-ce pas ?

Nous pouvons spécifier cela à la fonction receiver de Django en utilisant l'argument sender.

En lui indiquant que oui, nous voulons être notifiés lorsqu'un enregistrement est effectué dans la base de données, mais uniquement lorsqu'il s'agit du sender que nous avons spécifié. Et le sender dans notre cas sera notre modèle utilisateur.

Notre code ressemblera à quelque chose comme ceci :

@receiver(post_save, sender=MyUser)
def add_user_to_group(sender, **kwargs):
    pass

Jusque-là, le fichier ressemblerait à ceci :

from django.dispatch import receiver
from django.db.models.signals import post_save

from ..models import MyUser

@receiver(post_save, sender=MyUser)
def add_user_to_group(sender, **kwargs):
    pass

Faisons une dernière chose avant d’implémenter la logique de notre récepteur : faire connaître notre récepteur à Django. Pour cela, rendez-vous dans le fichier apps.py de l'application user et modifiez-le pour avoir ceci :

from django.apps import AppConfig

class UserConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'user'

    def ready(self) -> None:
        from .signals import model_signals

Nous avons ajouté la méthode ready, et à l'intérieur, nous importons notre fichier qui contient nos récepteurs. La méthode ready est appelée lorsque Django commence le serveur.

La logique de notre récepteur ressemblerait à ceci :

@receiver(post_save, sender=MyUser)
def add_user_to_group(sender, **kwargs):
    created = kwargs.get('created', False)
    user_model = kwargs.get('instance', None)

    try:
        group = get_object_or_404(Group, name="favorite_user")
    except Http404:
        group = Group.objects.create(
            name="favorite_user"
        )

    # Check if the instance is newly created
    if created:
        user_model.groups.add(group)
    else:
        pass

Comme dit précédemment, les émetteurs peuvent appeler une fonction réceptrice avec un nombre d’arguments donné. Le signal django.db.models.signals.post_save passe un certain nombre d'arguments à la fonction réceptrice, dont :

• Un booléen appelé created qui indique si un nouvel enregistrement a été ajouté à la base de données.
• Un argument appelé insance qui contient l'objet qui a été créé.

Et d’autres arguments que vous pouvez consulter ici : lien

Ainsi, nous avons besoin de ces arguments pour ajouter le nouvel utilisateur créé à un groupe.

L’heure est venue de tester.

Vous pouvez ouvrir votre terminal et créer un super utilisateur ; il sera automatiquement ajouté au groupe “favorite_user”. Vous pouvez également utiliser votre shell avec manage.py shell ou simplement lancer votre serveur Django.

Vous verrez un joli formulaire pour créer un utilisateur (cela n'a rien de joli en soi, mais vous pouvez créer un utilisateur avec 😉).

Si vous voulez savoir comment créer vos propres signaux dans Django, consultez ce lien : lien

Abonnez-vous ici pour les prochains articles. Retrouvez-moi sur GitHub ici.

Merci et à la prochaine !

Auteur

Romuald Oluwatobi, développeur Django et ReactJS. Besoin d’un développeur compétent ? Je vous accompagne dans la création d’une application web moderne dans l’atteinte de vos objectifs business.