Vous devez penser à séparer l'application en tant qu'application de bureau autonome (qui agit comme une application côté client) par rapport au serveur pour votre API et votre logique backend qui sont hébergées par un fournisseur de cloud.
En faisant cela, vous pouvez vous concentrer sur la séparation des préoccupations pour l'application de bureau (électronique) ainsi que sur la garantie que les serveurs (tels que l'API, l'authentification et d'autres logiques backend) sont bien optimisés et servent de plusieurs travailleurs eux-mêmes.
Il y a des problèmes de sécurité avec le développement d'une application Electron si vous ne mettez pas régulièrement à jour votre version de Node (comme les attaques par débordement de la mémoire tampon).
Un autre problème à prendre en compte est la façon dont la communauté Electron sert et résout les problèmes d'autorisations pour l'application côté client et les autorisations de fichiers régulières qui sont accordées lorsque l'utilisateur installe votre application.
En tant que développeur, il vous incombe de vous assurer que les bibliothèques tierces n'endommagent pas l'ordinateur de l'utilisateur. (Imaginez l'installation d'une dépendance de bibliothèque dont le but est de supprimer de manière malveillante l'intégralité du système de fichiers).
Pour l'authentification, vous pouvez servir des réponses à partir de votre API en fonction des demandes/publications côté client que vous fournissez au service d'authentification. Vous n'avez pas nécessairement à fournir/installer le serveur d'authentification dans votre application Electron, car cela peut être quelque peu gênant pour l'utilisateur à mettre à jour, et cela expose votre service d'authentification à d'autres pour une ingénierie inverse/crack.
