Progressive Web Apps : nouveaux systèmes FE

Parfois, la connectivité devient un goulot d'étranglement.

Dans les environnements d'entreprise, nous considérons souvent une connectivité Internet stable comme une évidence. Cependant, les conditions réelles remettent souvent en question cette hypothèse, perturbant potentiellement les opérations commerciales critiques. Cet article détaille comment nous avons transformé un système ERP traditionnel uniquement en ligne en un système plus fiable doté d'une solution résiliente capable de fonctionner hors ligne. En tirant parti de solutions de stockage basées sur un navigateur telles qu'IndexedDB, en employant des mécanismes de synchronisation et en utilisant des applications Web progressives (PWA).

Au départ, le système suivait une architecture client-serveur traditionnelle où toute la logique métier résidait sur le backend. Bien que cette architecture fonctionne bien dans des environnements dotés d'une connectivité fiable, elle présentait plusieurs défis :

• Échecs de transaction lors d'interruptions de réseau
• Opportunités de ventes perdues lors de pannes
• Mauvaise expérience utilisateur avec des états de chargement constants
• Risque de perte de données lors d'opérations critiques
• Et surtout, perdre des clients faute de service rapide.

Donc, en définissant cela, nous avons dû improviser et voir comment nous pouvons améliorer les choses et également nous passer de la connectivité puisqu'elle n'est pas disponible au départ, nous avons implémenté un système hors ligne avec un peu d'Internet requis en utilisant des applications Web progressives (PWA), déplaçant efficacement les éléments critiques. logique métier au frontend tout en maintenant l'intégrité des données et la synchronisation avec le système ERP principal.

Quelques composants de base :

IndexedDB : Pour le stockage et la mise en cache des données hors ligne, nous avons utilisé IndexedDB via la bibliothèque Dexie.js pour fournir une base de données robuste côté client qui prend en charge le stockage de données structuré. ci-dessous un exemple simple de comment mettre en place une base de données avec Dexie

// Initialize IndexedDB using Dexie.js
import Dexie from 'dexie';

interface LocalUsers{
id:string;
name:string;
role:string;
dob:string;
phone_no:string
}

interface LocalTrx {
id: string;
syncId:string;
created_at:string;
amount:string;
isSynced:boolean;
modified:string;
}

export class ArticleDatabase extends Dexie {
  transaction!: Table<LocalTrx>;
  users!: Table<LocalUsers>;
  constructor(){
    super("articleDB")
    }

this.version(1).stores({
// define the fields you'll like to query by or find items by within the indexDB
    transactions: 'id, date, amount, isSynced',
    users: 'id, name, role'
 });
}
//create the db
export const db=new ArticleDatabase()

// Open the database
db.open().then(() => {
    console.log("Database opened successfully!");
  })
  .catch((error) => {
    console.error("Failed to open database:", error);
  });

// Adding a new transaction to IndexedDB
import db from ../db
async function addTransaction(transaction) {
try {
   const trx = await db.transactions.add(transaction)
   console.log("Trx added", trx)
} catch (err) {
    console.log("Failed creating trx", err)
}
}

Service Workers : Ceux-ci agissent comme un proxy entre l'application et le réseau, permettant des fonctionnalités hors ligne en mettant en cache les ressources et en interceptant les demandes pour garantir que les données critiques restent accessibles pendant la déconnexion.

//service worksr peut être configuré facilement, récemment, par défaut, les applications nextJS sont livrées avec service works avec vite, vous pouvez utiliser le plugin vite-pwa
Synchronisation en arrière-plan : Cela nous permet de synchroniser les données une fois que le réseau est à nouveau disponible, garantissant que les transactions ne sont pas perdues et que les mises à jour sont effectuées automatiquement une fois la connectivité restaurée.

Flux d'architecture système
L'architecture était divisée en trois phases principales : initialisation, traitement des transactions et synchronisation. L'organigramme ci-dessous montre comment les données circulent entre ces étapes.

*Phase d'initialisation *

Lorsque le système démarre, il vérifie la connexion réseau :

Si l'appareil est en ligne, il récupère les dernières données de base du serveur et met à jour l'IndexedDB local.

Si l'appareil est hors ligne, il charge les données d'IndexedDB, garantissant ainsi que les utilisateurs peuvent continuer à travailler sans interruption.

Traitement des transactions

Lorsque les utilisateurs effectuent une nouvelle transaction :

Les données locales sont validées et stockées dans IndexedDB.

Une mise à jour optimiste de l'interface utilisateur est utilisée pour montrer immédiatement le résultat à l'utilisateur, offrant ainsi une expérience fluide et réactive.

*Phase de synchronisation *

Lorsque la connectivité est restaurée :

Les données sont synchronisées par lots avec le serveur, soit en cliquant manuellement sur le bouton de synchronisation, soit après un certain délai.

Si la synchronisation échoue (par exemple, en raison d'une connexion lente), la transaction est ajoutée à une liste de transactions ayant échoué et réessayée plus tard.

Puisque nous gérons tout sur le frontend, dans quelle mesure notre service est-il tributaire de la sécurisation des informations clients.

Authentification et autorisation
Dans tout système d’entreprise, la sécurisation des informations sensibles des utilisateurs est essentielle. Notre solution garantit que :

L'authentification basée sur JWT est utilisée pour les sessions utilisateur sécurisées.

Contrôle d'accès basé sur les rôles garantit que seuls les utilisateurs autorisés peuvent effectuer des actions spécifiques.

Le stockage sécurisé des jetons est géré à l'aide de mécanismes basés sur un navigateur tels que localStorage pour plus de sécurité.

Pour atténuer les risques liés à l'utilisation de jetons stockés localement, nous :

Déclenchez la suppression sécurisée des jetons utilisateur lors de la déconnexion.

Assurez-vous que les données sensibles sont supprimées d'IndexedDB à la fin de la session ou lorsque l'utilisateur se déconnecte du système. Remarque : si les transactions ne sont pas synchronisées, nous l'affichons à l'utilisateur connecté et l'obligeons à se synchroniser avant de se déconnecter.

Intégrité des données et résolution des conflits

La synchronisation des données entre le client et le serveur introduit des problèmes potentiels d'intégrité des données, en particulier si plusieurs appareils ou utilisateurs apportent des modifications aux mêmes données hors ligne. Pour résoudre ce problème :

Nous validons tous les détails des transactions (par exemple, quantités, montants) avant la synchronisation pour nous assurer qu'il n'y a pas d'écarts.

Nous attribuons des identifiants uniques à chaque transaction pour éviter la duplication lors de la synchronisation.

Des stratégies de résolution de conflits sont utilisées pour gérer les situations dans lesquelles des modifications de données sont apportées sur plusieurs appareils hors ligne. Par exemple, nous utilisons une approche d'horodatage.

//nous essayons de nous assurer que le hors ligne est pris en compte en premier, car c'est l'élément important du système.

// Initialize IndexedDB using Dexie.js
import Dexie from 'dexie';

interface LocalUsers{
id:string;
name:string;
role:string;
dob:string;
phone_no:string
}

interface LocalTrx {
id: string;
syncId:string;
created_at:string;
amount:string;
isSynced:boolean;
modified:string;
}

export class ArticleDatabase extends Dexie {
  transaction!: Table<LocalTrx>;
  users!: Table<LocalUsers>;
  constructor(){
    super("articleDB")
    }

this.version(1).stores({
// define the fields you'll like to query by or find items by within the indexDB
    transactions: 'id, date, amount, isSynced',
    users: 'id, name, role'
 });
}
//create the db
export const db=new ArticleDatabase()

// Open the database
db.open().then(() => {
    console.log("Database opened successfully!");
  })
  .catch((error) => {
    console.error("Failed to open database:", error);
  });

// Adding a new transaction to IndexedDB
import db from ../db
async function addTransaction(transaction) {
try {
   const trx = await db.transactions.add(transaction)
   console.log("Trx added", trx)
} catch (err) {
    console.log("Failed creating trx", err)
}
}

Sécurité du réseau
Étant donné que les données sont transmises sur le réseau une fois la connectivité rétablie, nous avons assuré :

Limitation du débit pour éviter les abus et garantir qu'un trop grand nombre de requêtes ne submergent pas le serveur avec une réponse 429, d'où la raison pour laquelle nous avons initialement travaillé avec des mises à jour par lots.

Cryptage des données pendant le transit via SSL/TLS.

Expiration des jetons et gestion sécurisée des jetons, garantissant que les jetons périmés ou expirés sont automatiquement supprimés du stockage côté client.

Alternatives à PWA et IndexedDB

Bien qu'IndexedDB soit un choix solide pour le stockage de données côté client dans les PWA, il existe d'autres options disponibles en fonction de la complexité et des exigences de l'application :

SQLite via WebAssembly (WASM) : Certains développeurs choisissent d'utiliser SQLite via WASM pour une gestion de données plus avancée, en particulier lorsqu'ils traitent des ensembles de données plus volumineux ou des requêtes complexes. Cependant, l'intégration de SQLite via WASM introduit une complexité supplémentaire, telle que des problèmes de performances et de compatibilité des navigateurs (par exemple, comment SQLite a rendu Notion plus rapide).

API Web Storage (localStorage/sessionStorage) : Pour les applications plus simples qui ne nécessitent pas de requêtes complexes ou de grands ensembles de données, l'API Web Storage peut être une alternative viable. Il est plus facile à mettre en œuvre mais présente des limites en termes de capacité de stockage et de capacités d'interrogation.

Regard vers l’avenir : tendances futures en matière de PWA

À mesure que les technologies Web continuent d'évoluer, les possibilités d'applications comme celle-ci évoluent également. Les tendances émergentes incluent :

• WebAssembly et SQLite
• Edge Computing
• Protocoles de synchronisation avancés : protocoles émergents tels que les CRDT (Conflict-Free Replicated Data Types) et DeltaSync

J'ai moi-même hâte d'explorer comment ces technologies vont transformer le paysage des applications hors ligne et distribuées. Avec les progrès rapides des machines et des ordinateurs portables puissants, nous avons la possibilité d’exploiter cette puissance de calcul accrue pour fournir aux utilisateurs des logiciels encore plus sophistiqués et efficaces. Dans le même temps, nous ne devons pas oublier l’importance de répondre aux besoins des appareils mobiles et des appareils moins performants, en garantissant que nos solutions sont accessibles et optimisées sur toutes les plateformes. Le potentiel est énorme et je suis ravi de continuer à repousser les limites de ce qui est possible avec les PWA.

Remarque : quelle est la prochaine étape

Nous allons reprendre les choses. En utilisant Djuix.io comme backend et React/Angular pour notre frontend, nous implémenterions un flux de base approprié. Restez à l'écoute pour plus de mises à jour alors que nous continuons à améliorer notre approche pour créer des applications étonnantes.

Quoi qu'il en soit, j'espère que vous avez apprécié cela et appris quelque chose de nouveau. Je l’ai certainement fait. J'aimerais également entendre vos pensées et vos expériences.

En attendant.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!