Quel est le modèle Client / Serveur lors de l'utilisation d'Electron (Atom Shell)?
J'essaie de comprendre comment fonctionne Electron (anciennement Atom Shell)).
Je viens d'une application Web traditionnelle de style MVC où un navigateur appelle une action de contrôleur via une Système de routage , le contrôleur récupère ensuite les données d'un magasin (système de fichiers, base de données, ...) et affiche une vue , qui est renvoyé au navigateur. Certaines actions peuvent renvoyer JSON à la place, car elles sont appelées via JavaScript/AJAX au lieu que le navigateur y accède réellement.
Je veux créer cela, mais en tant qu'application de bureau multiplateforme. Je sais que Atom Shell combine à la fois un navigateur Chromium et un runtime Node.js/v8, mais je ne sais pas comment ils communiqueraient.
Je suppose que je pourrais exécuter un serveur Web complet (en gros, certains middleware HTTP Node.js comme Express ), mais cela crée un serveur accessible par le réseau (qui pourrait également déclencher des pare-feu) - l'un des les raisons pour lesquelles je veux créer une application de bureau sont précisément pour éviter d'exécuter un vrai serveur. Fondamentalement, comme le modèle MVP/MVVM dans une application de bureau "normale".
Quelqu'un peut-il me donner quelques points de départ pour ce que j'essaie de faire? Comment le navigateur parlerait-il au runtime du nœud (le "Client" comme ils l'appellent?) Pour lui dire "Hé, récupérez mon enregistrement avec l'ID 12345" et le Client retournerait-il du HTML rendu, ou le navigateur obtiendrait-il simplement un blob de JSON en arrière et le rendre via un moteur de template JavaScript?
Electron ne semble pas utiliser Node.js comme serveur Web mais simplement comme environnement pour exécuter du code JavaScript en arrière-plan, ce code peut utiliser des modules de nœuds pour accéder au système. En même temps, Chromium fournit une interface utilisateur pour l'application, il affiche des pages Web régulières qui exécutent le JavaScript bac à sable habituel. Les deux sont intégrés par l'exécutable Electron, le premier directement (Node.js peut être construit comme une bibliothèque statique), le second via libchromiumcontent . D'une certaine manière, Node.js est la partie contrôleur de l'application tandis que Chromium est la vue.
En règle générale, le concept utilisé pour les pages Web ici est celui de applications à page unique : une page Web représente une fenêtre d'application et, en tant que telle, elle reste présente tant que cette fenêtre est visible (souvent pour toute la durée de vie). de la demande). Chaque fois qu'il a besoin d'afficher quelque chose de différent, il demande des données au code d'arrière-plan exécuté dans Node.js, tout comme AJAX demandent des données au serveur. La page elle-même n'est pas rechargée, généralement les modèles JavaScript seront être utilisé pour mettre à jour le contenu.
Il n'y a pas vraiment de relation serveur/client ici cependant, la communication peut en fait aller dans les deux sens. Les deux parties peuvent utiliser le module ipc pour s'envoyer des messages ( processus principal , moteur de rend ). Ces messages peuvent avoir des arguments qui leur sont attachés, ils n'ont pas besoin d'être encodés explicitement (généralement cela est implémenté en utilisant JSON en interne pour encoder les paramètres, je n'ai pas vérifié si c'est le cas avec Electron). En interne, ce passage de message est implémenté via des mécanismes spécifiques à la plateforme IPC , en utilisant libuv pour être exact.
Nous avons implémenté un serveur nodejs entièrement fonctionnel et une interface utilisateur angular avec sqlite3, séquencer ORM en utilisant
*. https://github.com/theallmightyjohnmanning/electron-express
Certains des projets nous ont beaucoup aidés:
- Framework: https://github.com/angular-fullstack/generator-angular-fullstack Emballage Windows: electron-packager ":" github: electron-userland/electron-packager "
- Création de raccourcis et mise à jour automatique: "électron-écureuil-démarrage": "^ 1.0.0",
- Création de Release Installer: "electron-winstaller": "^ 2.3.4",