Certains détestent farouchement les applications
Electron . Que l'application inclut le navigateur Chromium semble, pour le dire légèrement, étrange. Cette sensation est renforcée pendant le travail avec de telles applications. Ils consomment beaucoup de mémoire, se chargent lentement et n'ont pas un taux de réaction particulièrement élevé à l'exposition de l'utilisateur. Il n'est pas facile de développer une bonne application web. Pourquoi les technologies Web sont-elles entraînées dans l'environnement de bureau? Après tout, on a le sentiment que dans cet environnement, ils créent un tas de problèmes?
L'auteur du matériel, dont nous publions la traduction aujourd'hui, dit qu'il ne jouera pas le rôle de défenseur d'Electron, bien que tout parle du succès de cette plateforme. Certes, personne ne va ignorer les excès inhérents aux applications Electron. Est-il possible, en développant de telles applications, de tuer deux oiseaux avec une pierre en un seul coup?
Certains problèmes d'Electron (fichiers volumineux, chargement lent) sont un héritage des technologies sur lesquelles cette plate-forme est basée. Ils doivent être traités à un faible niveau. Des problèmes plus graves (consommation de mémoire, lenteur des interfaces) peuvent être résolus au niveau du développement des applications Electron. Cependant, résoudre ces problèmes n'est pas facile. Et s'il y a un secret, sachant que vous pouvez, en mode automatique, minimiser ces lacunes?
Si vous aimez lire le code du programme, vous pouvez immédiatement consulter
ce référentiel. Voici le projet qui sera considéré dans ce document.
L'essence du secret
Le secret du développement d'applications Electron de haute qualité est d'effectuer la majeure partie des calculs sur le système local, dans les processus d'arrière-plan. Moins vous comptez sur les services cloud et plus vous travaillez sur les processus d'arrière-plan, plus vous pouvez ressentir les effets positifs suivants:
- Chargement instantané des données. Les utilisateurs de l'application n'auront jamais à attendre que les données soient téléchargées sur le réseau. Les données sont téléchargées à partir du stockage local. Cela donne immédiatement à l'application une amélioration tangible des performances.
- Faible mise en cache. L'application client n'a pas besoin de se soucier particulièrement de la mise en cache. En effet, toutes les données dont il a besoin sont disponibles localement. Pour qu'une application Web atteigne un niveau de performances décent, elle doit généralement charger une quantité impressionnante de données dans son état local. C'est l'une des raisons de la très forte consommation de mémoire des applications Electron.
Je ne parle pas ici d'autres avantages du stockage de données local, par exemple, de la possibilité de travailler sans se connecter à un réseau.
Jetez un œil à la quantité de mémoire consommée par mon application Electron -
le gestionnaire des finances personnelles
d'Actual . Ce programme stocke toutes ses données localement. La synchronisation des données entre différents appareils est une fonctionnalité facultative, elle n'affecte pas la fonctionnalité principale. Je suppose, étant donné que cette application est conçue pour fonctionner avec de grandes quantités de données, ses chiffres de consommation de mémoire parlent d'eux-mêmes.
Consommation réelle de mémoireUne application qui n'effectue aucune action active occupe au total 239,1 Mo de mémoire. Cet indicateur peut être plus, cela dépend de ce qui se passe exactement dans l'application, mais il est possible de prendre uniquement le nombre spécifié comme base. Ce n'est pas parfait, mais pas si mal. Au moins - mieux que les 1371 Mo de mémoire requis sur mon ordinateur Slack. Je dois dire que Slack est un exemple atypique d'application Electron, caractérisé par des problèmes spécifiques. Il y avait une sensation autour d'Electron à cause de Slack. D'autres applications, telles que Notion ou Airtable, consomment environ 400 à 600 Mo de mémoire. Et cela signifie que ma candidature gagne bien à cet égard et ils l'ont fait.
Je dois dire que le chiffre de 239,1 Mo a été obtenu par moi avant toute optimisation. Je prévois de réécrire certaines des parties extrêmement importantes et gourmandes en mémoire de l'application dans Rust. Cela devrait réduire considérablement les besoins en mémoire de l'application.
Le serveur d'arrière-plan peut optimiser sa propre consommation de mémoire en ne chargeant dans la mémoire que les données nécessaires à un certain moment. Il est préférable d'utiliser quelque chose comme SQLite pour le stockage des données. Ce SGBD est déjà sérieusement optimisé pour résoudre de tels problèmes (sérieusement - utilisez simplement SQLite). De plus, il convient de noter que le déplacement de divers calculs vers des processus d'arrière-plan permet à l'interface utilisateur de l'application de répondre le plus rapidement possible aux influences de l'utilisateur.
Il s'est avéré que l'utilisation d'un serveur d'arrière-plan dans une application Electron offre au développeur des opportunités intéressantes. Dans la section suivante, nous parlerons de toutes ces choses incroyables qui peuvent être faites avec son utilisation.
Même si votre application est sérieusement liée aux données du cloud, vous devrez peut-être un processus d'arrière-plan si vous avez l'intention de travailler avec l'API Node.js. L'interaction avec ces API n'est possible qu'à partir de processus d'arrière-plan. En fait, quelle que soit votre candidature Electron, je pense qu'apprendre à connaître le projet que nous allons examiner maintenant peut vous donner quelques idées utiles.
Exemple d'électron avec serveur
J'ai créé l'application
électron-with-server-example afin de montrer tout ce qui doit être configuré pour développer des applications Electron vraiment locales en utilisant son exemple. Je l'ai fait dans le but de captiver les programmeurs en créant des projets similaires. J'aimerais rencontrer un projet similaire à un moment où je commençais à peine à travailler avec Electron.
Des informations techniques sur l'application sont disponibles dans le
README
. Voici un aperçu général du projet:
- Il crée le processus Node.js habituel, utilisé pour exécuter le code serveur en arrière-plan.
- Dans celui-ci, en utilisant node-ipc , un canal IPC est créé, qui est conçu pour organiser l'interaction directe entre le backend et l'interface utilisateur de l'application.
- Si le projet est lancé en mode développement, le serveur ne démarre pas en tant que processus d'arrière-plan. Vous pouvez interagir avec lui via une fenêtre de navigateur distincte. C'est à des fins de débogage.
Maintenant, ralentissons un peu et examinons de plus près le dernier élément de cette liste. En mode développement, pouvez-vous interagir avec le serveur via une fenêtre de navigateur distincte?
Parties client et serveur de l'applicationOui, ça l'est. Après avoir appris à démarrer les processus d'arrière-plan, j'ai réalisé, tout d'abord, que j'avais à ma disposition les outils du développeur Chromium. Et deuxièmement - j'ai réalisé que, à des fins de débogage, je peux les utiliser pour déboguer le code Node.js. Par conséquent, je parle du fait que vous pouvez interagir avec Node.js via un navigateur. Cela vous permet d'utiliser la boîte à outils du développeur de navigateur basé sur Chromium pour déboguer le code du serveur.
Voyons maintenant toutes les choses intéressantes que nous pouvons faire grâce à l'application du schéma de lancement d'application ci-dessus.
Utilisation de la console
J'ai ajouté des commandes pour la journalisation des demandes et des réponses dans le fichier
server-ipc.js
. Je peux les explorer en utilisant la console du navigateur.
Débogage des applications Node.js dans la console du navigateurExécution de code étape par étape
Lors du débogage côté serveur de l'application à l'aide d'un navigateur, vous pouvez utiliser l'exécution de code étape par étape. Cela ne veut pas dire que c'est quelque chose d'absolument fantastique. Mais il est très pratique que cette fonctionnalité soit toujours à portée de main et ne nécessite pas l'utilisation de programmes supplémentaires.
Exécution de code étape par étapeProfilage
C'est peut-être mon outil préféré. Il s'agit d'un outil standard génial pour rechercher les performances du code, qui vous permet de profiler le côté serveur de l'application.
Recherche sur les performances du code serveurEn utilisant les outils du développeur de navigateur, vous pouvez même explorer ce qui se passe lorsque le processus d'arrière-plan démarre (c'est probablement la partie la plus difficile du démarrage de l'application).
Pour ce faire, il suffit de démarrer le processus d'enregistrement des indicateurs et de recharger la fenêtre. Le redémarrage entraînera le redémarrage du serveur. Cela nous amène à la prochaine étape.
Redémarrage du serveur à l'aide de la combinaison de touches Cmd + R ou Ctrl + R
Une autre option de débogage du code serveur dans un navigateur est que, puisque le débogage du serveur est effectué dans une fenêtre de navigateur, le simple rechargement du contenu de la fenêtre provoque le redémarrage du serveur! Il suffit d'utiliser la combinaison de touches
Cmd+R
(ou, pour Windows,
Ctrl+R
), et à votre disposition sont les dernières modifications apportées au code du serveur. Dans ce cas, les données frontales sont enregistrées. Cela signifie que vous pouvez continuer à travailler avec la partie cliente de l'application, mais après avoir redémarré le serveur, la partie client fonctionnera déjà avec la nouvelle version du code serveur. Cela rappelle quelque chose comme un échange de code «à chaud» sur un serveur en cours d'exécution.
La figure suivante montre comment, en changeant le code du serveur, j'ai rechargé la page en appuyant sur
Cmd+R
Après cela, j'ai continué à travailler avec le client, qui interagit désormais avec la nouvelle version du serveur.
Redémarrage du serveurRecherche du côté serveur en cours d'exécution de l'application et du code d'échange à chaud
Habituellement, lors du débogage du serveur, j'ajoute simplement la commande
console.log()
aux bons endroits dans le code et je le redémarre. Mais parfois, dans des cas particulièrement difficiles, il arrive qu'il serait extrêmement utile de regarder ce qui se passe sur un serveur en cours d'exécution, plutôt que de le redémarrer. Il est possible non seulement de «regarder» à l'intérieur du serveur, mais aussi de changer quelque chose dedans afin de voir comment cela affectera le problème.
Dans la console, vous pouvez utiliser la commande Node.js
require
. Cela signifie qu'avec son aide, vous pouvez connecter n'importe quel module serveur et travailler avec lui dans la console.
Supposons que nous devions travailler avec le
server-handler.js
. Pour ce faire, il suffit d'exécuter la commande
let handlers = require('./server-handlers')
dans la console.
Créons un système pour stocker l'état du serveur. Dans notre cas, ce sera une liste de toutes les données passées à la fonction
make-factorial
(l'état du serveur de l'application réelle sera beaucoup plus compliqué):
handlers._history = [] handlers['make-factorial'] = async ({ num }) => { handlers._history.push(num) }
Vous pouvez
handlers._history
état du serveur à partir de la console en connectant le module approprié et en consultant
handlers._history
. Si vous le souhaitez, pendant l'exécution du programme, nous pouvons même remplacer complètement l'implémentation
make-factorial
!
Recherche sur l'état du serveurRésumé
Jetez un œil au référentiel
électron-with-server-example pour en savoir plus sur les détails de la mise en œuvre du projet et voir le code du côté serveur de l'application Electron.
Si vous utilisez Visual Studio Code, vous pouvez être habitué à une intégration de haute qualité des outils de développement avec le serveur Node.js. Avec cette approche, vous pouvez démarrer le serveur vous-même, séparément de l'application Electron. Après cela, vous pouvez dire à Electron que vous devez vous connecter au processus appartenant à VS Code. Cependant, je préfère utiliser les outils de développement Electron existants.
Cela signifie que le programmeur a la possibilité d'utiliser tous les outils d'édition de code tiers et en même temps d'avoir un accès complet à tous les outils de développement du navigateur.
Au cours des dernières années, j'ai développé l'application
Actual et j'utilise constamment ce dont je viens de parler. Et je veux dire que j'aime vraiment tout ça. Peut-être que le travail sur la partie Node.js de cette application est devenu la source de l'expérience de programmation la plus agréable que j'ai jamais connue.
De plus, il est très important que les principes décrits ci-dessus nous aident à développer des applications vraiment locales. Nous avons déjà toutes les technologies nécessaires pour cela. L'essentiel est de les utiliser correctement.
Chers lecteurs! Que pensez-vous des applications basées sur Electron?
