Pourquoi votre API semble lente : toute l'idée en deux croquis

Un client m'a dit un jour : "le bouton d'inscription met 4 secondes, il faut réparer la base de données." La base de données n'y était pour rien. L'API envoyait un e-mail de bienvenue avant de répondre à l'utilisateur. Voici tout le problème en un croquis :

La solution : répondre d'abord, travailler ensuite

L'utilisateur n'a pas besoin que l'e-mail existe déjà pour voir "compte créé". Il a seulement besoin de la promesse qu'il existera. On sépare donc la chronologie : on répond tout de suite, et on pousse le travail lent dans une file qu'un worker traite en arrière-plan.

En Laravel, ça tient en trois lignes

On pousse le travail vers une tâche mise en file, et on répond tout de suite :

SendWelcomeEmail::dispatch($user); dans le contrôleur, php artisan queue:work sur le serveur, et QUEUE_CONNECTION=redis dans l'environnement. C'est tout le principe.

Chez Tamkeen, j'ai passé une bonne partie de six mois à sortir du travail des requêtes pour le mettre en file. Mêmes serveurs, même base de données, et des endpoints qui prenaient des secondes se sont mis à répondre en quelques dizaines de millisecondes.