Tinyjobs apporte des tâches de fond sans dépendance à Python sur SQLite

L'utilisateur GitHub Piergiuseppe a publié tinyjobs, une bibliothèque légère pour gérer les tâches en arrière-plan et les planifications cron dans les applications Python. Publiée le 27 octobre 2026, ce projet permet aux développeurs d'exécuter des tâches asynchrones et synchrones en utilisant SQLite comme seul backend, éliminant ainsi la nécessité de courtiers de messages complexes comme Redis ou RabbitMQ pour les déploiements de petite et moyenne taille.

Ce qui s'est passé

La version introduit une approche sans dépendance pour la planification des tâches, visant les développeurs souhaitant éviter la charge opérationnelle liée à la maintenance d'une infrastructure séparée pour les files d'attente de tâches. Tinyjobs prend en charge les frameworks FastAPI et Django, s'intégrant directement dans leurs cycles de vie. Pour FastAPI, elle utilise le gestionnaire de contexte lifespan pour démarrer un worker au sein du processus serveur, garantissant que les tâches en cours se terminent proprement lors de l'arrêt. Dans Django, elle agit comme un backend pour l'API standard django.tasks introduite dans Django 6, permettant aux tâches de rester du code Python simple tout en tirant parti de tinyjobs pour l'exécution.

La bibliothèque gère des exigences courantes telles que les tentatives avec backoff exponentiel, la planification cron avec prise en charge des fuseaux horaires et la déduplication des tâches. Elle fonctionne selon un modèle de livraison au moins une fois (at-least-once), ce qui signifie que les tâches peuvent s'exécuter plus d'une fois si un worker plante après le traitement mais avant l'enregistrement du résultat. Pour atténuer cela, il est conseillé aux développeurs d'écrire des tâches idempotentes. Le système utilise un verrouillage basé sur des baux (leases) pour garantir que si un worker meurt, ses tâches assignées deviennent disponibles pour d'autres workers après une période d'expiration.

Détails clés

• Zéro dépendance : Fonctionne entièrement sur SQLite par défaut, ne nécessitant aucun service externe pour les configurations petites.
• Intégration aux frameworks : Prise en charge native de FastAPI via les hooks lifespan et de Django via le backend django.tasks.
• Modèle de concurrence : Prend en charge les tâches async def s'exécutant sur la boucle d'événements et les tâches def exécutées dans un pool de threads.
• Option Redis : Un backend Redis optionnel est disponible pour les déploiements multi-machines, utilisant des scripts Lua pour les opérations atomiques.
• Utilitaires de test : Inclut un backend en mémoire et une horloge figée pour des tests déterministes des tâches différées et des tentatives.
• Observabilité : Fournit des commandes intégrées pour vérifier les statistiques de la file d'attente et la santé du système, incluant la détection des tâches cron en retard.

Contexte

Les systèmes de tâches en arrière-plan permettent aux applications de décharger les tâches chronophages, telles que l'envoi d'e-mails ou la génération de rapports, du cycle principal requête-réponse. Traditionnellement, cela nécessite un courtier de messages comme Redis, RabbitMQ ou PostgreSQL, ce qui ajoute de la complexité au déploiement et à la surveillance. SQLite est souvent écarté pour les scénarios d'écriture concurrente, mais tinyjobs exploite des fonctionnalités SQL spécifiques comme RETURNING et les transactions immédiates pour gérer en toute sécurité les revendications de tâches entre plusieurs processus workers. Cette approche simplifie la pile technologique pour les applications qui n'ont pas encore besoin de l'échelle des systèmes distribués.

Pourquoi c'est important

Pour les équipes exploitant des logiciels auto-hébergés, réduire la complexité de l'infrastructure est un avantage significatif. Maintenir une instance Redis ou un cluster RabbitMQ nécessite des ressources dédiées, une surveillance et des stratégies de sauvegarde. En utilisant SQLite, tinyjobs permet aux petites et moyennes entreprises de garder l'ensemble de leur pile applicative dans un seul fichier de base de données. Cela réduit la surface d'attaque et simplifie les sauvegardes, car la file d'attente de tâches est incluse dans les dumps standards de la base de données. Cela abaisse également la barrière à l'entrée pour ajouter un traitement en arrière-plan aux projets existants sans refactoriser toute l'architecture.

Cependant, cette simplicité comporte des compromis. SQLite ne prend pas en charge les écritures parallèles réelles sur différentes machines, donc le backend par défaut est limité à un seul serveur. Bien que le backend Redis résolve ce problème, il réintroduit la dépendance que la bibliothèque vise à éviter. De plus, le modèle de livraison au moins une fois nécessite une conception minutieuse des tâches pour prévenir les effets secondaires dupliqués, tels que facturer deux fois un client. Les équipes doivent peser la facilité opérationnelle contre ces contraintes techniques lors du choix d'un planificateur de tâches.

Ce que vous pouvez faire

• Évaluer votre échelle : Si votre application tourne sur un seul serveur ou un petit cluster, testez tinyjobs avec SQLite pour voir s'il répond à vos besoins en débit.
• Vérifier l'idempotence : Examinez les tâches en arrière-plan existantes pour vous assurer qu'elles peuvent être relancées en toute sécurité sans causer de corruption de données ni d'actions dupliquées.
• Tester le comportement à l'arrêt : Utilisez les hooks lifespan fournis dans FastAPI ou Django pour vérifier que les tâches se terminent ou sont remises en file correctement lors des redémarrages de déploiement.
• Surveiller les baux : Configurez des délais d'expiration de bail appropriés basés sur vos tâches les plus longues pour empêcher une ré-exécution prématurée si un worker se bloque.
• Envisager Redis pour la croissance : Prévoyez une trajectoire de migration vers le backend Redis si vous anticipez une mise à l'échelle au-delà d'une seule machine, en vous assurant que vos tâches sont compatibles avec la latence réseau.
• Utiliser les vérifications intégrées : Implémentez des contrôles de santé réguliers en utilisant tinyjobs check pour détecter précocement les workers bloqués ou les planifications cron manquées.