Interaction client/serveur

Ouvrir dans ChatGPT

La section suivante discute des différentes qualités de performance et des meilleures pratiques pour webforJ, ainsi que des détails de mise en œuvre pour le framework.

Lors de la création d'une application dans webforJ, le client et le serveur travaillent ensemble pour manipuler les données entre le client et le serveur, ce qui peut être divisé en grandes catégories :

1. Serveur au client

Les méthodes webforJ telles que setText() sont incluses dans cette catégorie. Une application webforJ s'exécutant sur le serveur envoie des données au client sans attendre de réponse. webforJ optimise automatiquement les batches d'opérations dans cette catégorie pour améliorer la performance.

2. Client au serveur

Cette catégorie couvre le trafic d'événements, comme la méthode Button.onClick(). La plupart du temps, le client envoie des événements au serveur sans attendre de réponse. L'objet événement contient généralement des paramètres supplémentaires relatifs à l'événement, tels que le code de hachage. Comme cette information est transmise au serveur dans le cadre de l'envoi de l'événement, elle est immédiatement disponible pour le programme dès que l'événement est reçu.

3. Serveur au client au serveur (aller-retour)

Les aller-retours sont effectués lorsque l'application interroge le client pour obtenir des informations dynamiques qui ne peuvent pas être mises en cache sur le serveur. Des méthodes telles que Label.getText() et Checkbox.isChecked() relèvent de cette catégorie. Lorsqu'une application webforJ exécute une ligne comme String title = myLabel.getText(), elle se fige complètement pendant que le serveur envoie cette demande au client, puis attend que le client renvoie la réponse.

Si l'application envoie plusieurs messages au client qui ne nécessitent pas de réponse (catégorie 1), suivis d'un message unique qui nécessite un aller-retour (catégorie 3), l'application doit attendre que le client traite tous les messages en attente, puis réponde au message final qui nécessite une réponse. Dans certains cas, cela peut entraîner un délai. Si cet aller-retour n’avait pas été introduit, le client aurait pu continuer à travailler en traitant ces messages en retard pendant que l'application s'exécutant sur le serveur passait à de nouvelles tâches.

Améliorer la performance

Il est possible d'améliorer considérablement la réactivité en évitant autant que possible les aller-retours de la troisième catégorie. Par exemple, changer la fonctionnalité onSelect du ComboBox de ceci :

private void comboBoxSelect(ListSelectEvent ev){
  ComboBox component = (ComboBox) ev.getComponent();

  // Va au client
  int selected = component.getSelectedIndex();
}

à ceci :

private void comboBoxSelect(ListSelectEvent ev){
  //Obtient la valeur de l'événement
  int selected = ev.getSelectedIndex();
}

Dans le premier extrait, l'exécution de ComboBox.getSelectedIndex() sur le composant force un aller-retour vers le client, introduisant un délai. Dans la seconde version, l'utilisation de la méthode ListSelectEvent.getSelectedIndex() de l'événement récupère la valeur qui a été livrée au serveur dans le cadre de l'événement d'origine.

Caching

webforJ optimise davantage la performance en utilisant la mise en cache. En général, deux types de données existent dans ce contexte : des données que l'utilisateur peut modifier directement et des données qui ne peuvent pas être modifiées par l'utilisateur. Dans le premier cas, lors de la récupération des informations avec lesquelles les utilisateurs vont interagir directement, il est nécessaire de consulter le serveur pour ces informations.

Cependant, les informations qui ne peuvent pas être changées par l'utilisateur peuvent être mises en cache pour éviter des pertes de performance supplémentaires. Cela garantit qu'un aller-retour n'a pas besoin d'être effectué inutilement, offrant une expérience utilisateur plus efficace. webforJ optimise les applications de cette manière pour garantir des performances optimales.

Temps de chargement

Lorsque l'utilisateur lance une application webforJ, elle charge juste un petit morceau (environ 2,5 kB gzip) de JavaScript pour initialiser la session. Ensuite, elle télécharge dynamiquement des messages individuels, ou des morceaux de JavaScript, à la demande au fur et à mesure que l'application utilise la fonctionnalité correspondante. Par exemple, le serveur envoie au client le JavaScript nécessaire pour créer un Button webforJ une seule fois, lorsque l'application crée son premier composant Button. Cela entraîne des améliorations mesurables du temps de chargement initial, ce qui se traduit par une meilleure expérience utilisateur.