NOTES D'INGÉNIERIE
Ingénierie d’un outil local d’analyse de poker avec Rust/WASM
Local-first ne signifie pas simplement « compilé sur WebAssembly ». Cela nécessite des domaines d'exécution explicites, une mémoire limitée, une annulation, une isolation des résultats obsolètes et une limite fiable entre les octets mis en cache et les conclusions affichées.
Rust est propriétaire des contrats mathématiques et de règles
L'encodage des cartes, l'état légal de la main, l'ordre des évaluateurs, l'énumération exacte, la construction de l'arbre de jeu, le CFR/DCFR, l'identité du point de contrôle et la vérification de la relecture appartiennent au code de base typé plutôt qu'à la logique d'interface utilisateur dupliquée.
Le navigateur doit afficher et orchestrer ces contrats, et non inventer silencieusement un deuxième moteur de poker.
Les travailleurs isolent les tâches de longue durée
La relecture des règles doit rester réactive pendant que le calcul exact de l'équité ou de la stratégie est actif. La propriété distincte des requêtes empêche une ancienne tâche de mettre à jour une configuration nouvellement modifiée.
Les erreurs Fatal Worker doivent rejeter immédiatement tous les appelants en attente ; la résiliation et l'annulation devraient produire un état terminal limité.
Le cache local n'est pas une preuve automatique
IndexedDB peut stocker un point de contrôle et un instantané, mais l'interface utilisateur ne doit pas faire confiance au texte localStorage comme recommandation qualifiée. La restauration nécessite des contrôles d'identité, une validation du hachage et une relecture par rapport à la session Rust/WASM correspondante.
Les enregistrements corrompus doivent pouvoir être supprimés afin qu'une résolution valide puisse réparer la même clé, tandis qu'un résultat simplement de qualité inférieure ne doit pas être classé à tort comme corruption.
Les pages éditoriales statiques permettent de conserver une échelle peu coûteuse
Les guides, exemples manuels, flux, index de recherche et métadonnées sociales sont générés au moment de la construction et servis sous forme de fichiers statiques. Ils ne nécessitent pas de base de données communautaire ni de solveur côté serveur.
Seules les routes d'application chargent les bundles Worker et WASM les plus lourds ; les pages de contenu restent rapides et explorables de manière indépendante.
CONTINUER SUR FLOPFORGE
Inspecter la méthodologie produit
Lisez la portée de calcul déclarée, les règles de preuve, les limites du cache et les conclusions non étayées.FAQ
Questions que cette page ne doit pas cacher
Pourquoi ne pas exécuter le solveur sur un serveur ?
L'exécution du navigateur évite une facture de calcul à distance et conserve les données saisies localement, mais nécessite des budgets de mémoire et de performances stricts.
Pourquoi utiliser plusieurs Workers ?
Un seul Worker sérialise les opérations de règles rapides derrière un travail long sur les actions ou le solveur. Des domaines distincts protègent le chemin d'interaction principal.
Les pages statiques peuvent-elles toujours être interactives ?
Oui. Les petites calculatrices et la recherche peuvent s'exécuter en tant que JavaScript local sans base de données, système de compte ou API de serveur.