Une application web qui ne peut pas gérer les opérations asynchrones n'est pas une application web. Les requêtes de base de données prennent du temps. Les requêtes réseau prennent du temps. Les interactions utilisateur sont intrinsèquement asynchrones. Si la VM bloque sur chaque opération d'E/S, l'application entière gèle.
La Session 033 a résolu cela en ajoutant la gestion d'état async et le support WebSocket au runtime de FLIN. Le résultat était une VM capable de gérer la communication bidirectionnelle en temps réel, de suivre le cycle de vie des opérations asynchrones et de mettre à jour l'interface utilisateur de manière réactive quand les résultats async arrivent.
Cet article couvre le modèle d'exécution asynchrone, l'implémentation WebSocket et comment ils s'intègrent au système de réactivité de FLIN.
Le modèle d'exécution async
FLIN n'a pas de green threads, de coroutines ou de syntaxe async/await au niveau du langage. Au lieu de cela, le comportement async est intégré dans la couche runtime. La VM exécute le bytecode FLIN de manière synchrone, et le runtime Rust gère les E/S asynchrones en dessous.
Cette conception était délibérée. FLIN cible les développeurs d'applications, pas les programmeurs systèmes. Le développeur ne devrait pas avoir besoin de raisonner sur la sécurité des threads, les courses aux données ou les interblocages. Il devrait écrire save user et le runtime gère le reste -- que cette sauvegarde soit synchrone (en mémoire) ou asynchrone (appel réseau vers une base de données distante).
Le pont entre le bytecode synchrone et les E/S asynchrones est l'enum AsyncState :
rustpub enum AsyncState {
Idle,
Loading,
Success(Value),
Error(String),
}Chaque opération asynchrone dans FLIN passe par ce cycle de vie :
- Idle -- l'opération n'a pas commencé.
- Loading -- l'opération est en cours.
- Success -- l'opération s'est terminée avec un résultat.
- Error -- l'opération a échoué avec un message d'erreur.
Support WebSocket
La Session 033 a ajouté un support WebSocket complet au runtime serveur de FLIN. Les WebSockets fournissent une communication bidirectionnelle, full-duplex sur une seule connexion TCP -- le protocole pour les fonctionnalités en temps réel comme le chat en direct, les notifications, l'édition collaborative et les tableaux de bord en temps réel.
La fonctionnalité la plus puissante de l'intégration WebSocket de FLIN est les abonnements aux changements d'entités. Un client peut s'abonner aux changements sur un type d'entité spécifique et recevoir des notifications en temps réel quand des entités sont créées, mises à jour ou supprimées :
javascript// Côté client
_flinWsConnect();
_flinWsSubscribe('Todo');
_flinOnEntityChange('Todo', function(change) {
// change.type: 'create' | 'update' | 'delete'
// change.entity: l'entité affectée
refreshTodoList();
});Cela signifie que quand un utilisateur sauvegarde un nouvel élément Todo, chaque autre utilisateur qui s'est abonné aux changements de Todo voit le nouvel élément apparaître en temps réel. Pas de polling. Pas de rafraîchissement manuel. Le changement en base de données coule à travers le WebSocket vers le navigateur vers le DOM automatiquement.
Résultats de tests
La Session 033 a ajouté 23 nouveaux tests, portant le total à 700 :
- Tests de handshake d'upgrade WebSocket
- Tests d'abonnement et de désabonnement
- Tests de notification de changement d'entité
- Tests de cycle de vie d'état async
- Tests de comportement de reconnexion
La session a aussi complété la Phase 11 (Rendu de vues) à 100 % -- les 30 tâches terminées. Le projet global était à 63 %.
Ceci est la partie 27 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont construit un langage de programmation à partir de zéro.
Prochain : [28] Le moteur de réactivité -- comment FLIN rend tout réactif avec le suivi automatique des dépendances et les mises à jour incrémentales du DOM.