Comment organiser le backend d'une application mobile?

Qu'est-ce que nous faisons? Service d'enregistrement et d'autorisation des utilisateurs pour une application mobile

Dans les projets pour animaux de compagnie de chaque développeur mobile, tôt ou tard, il arrive un moment où vous devez rapidement et sans trop de maux de tête créer un serveur pour votre application. Peu importe la fonction que le serveur doit effectuer: qu'il s'agisse de stockage de données ou d'enregistrement / autorisation d'utilisateur.

En règle générale, au début, tout le monde suit (enfin, ou presque) le chemin de la moindre résistance. Nous recherchons une solution clé en main et voyons à quelle vitesse elle peut s'adapter à nos besoins.

À ce stade, la première chose que vous pouvez «google» est les services Firebase, dont les limites gratuites sont plus que suffisantes pour organiser le backend d'une petite application mobile. Mais dans ce cas, compte tenu exactement du développeur russe, nous risquons de marcher sur le rake de notre législation - le transfert de données transfrontalier et le stockage des données personnelles de l'utilisateur.

(Loi fédérale 152 sur les données personnelles, article 12, chapitre 2) La

tentation d'utiliser Firebase est grande, mais si nous voulons nous assurer contre les tracas inutiles avec diverses agences de surveillance, nous commençons à chercher des options alternatives.

L'étape suivante est l'utilisation d'un serveur VDS avec une sorte de solution open source ou freemium, où le «service en tant que service» prêt à l'emploi ou une solution permettant de déployer des fonctionnalités similaires est pris comme base.

Il y a plusieurs années, sur Habré, j'ai déjà écrit un guide de configuration détaillé de BaasBox (l'article a été retiré du public en raison d'informations obsolètes) sur un serveur loué et a donné un exemple d'utilisation de divers appels dans l'application iOS pour le langage Objective C.Mais BaasBox est vraiment «lourd» et dicte votre minimum pour un serveur loué. Ayant joué un peu avec lui, il a été décidé d'utiliser une solution différente. À cette époque, le serveur Parse n'était soumis que récemment au développement open source par Facebook, il ne disposait pas d'autant d'adaptateurs qu'il l'est actuellement, mais ses capacités étaient plus que suffisantes pour les projets personnels et les applications de clients privés (de nombreux projets sont encore existent et fonctionnent de manière stable).

En toute honnêteté, il convient de noter que le serveur d'analyse a beaucoup mûri et se développe activement. À l'heure actuelle, presque toutes les fonctionnalités disponibles dans un ancêtre commercial ont été recréées. Vous pouvez écrire vos propres hooks, des notifications push localisées, un gestionnaire de processus, et il y a même un abonnement pour changer des objets en fonction des sockets (ParseLiveQuery - si c'est intéressant, j'écrirai un article séparé sur la configuration de ParseLiveQuery).

Mais le serveur d'analyse a cessé d'être intéressant précisément au moment où il était nécessaire de mettre en œuvre un type de données non standard, ce qui est difficile à travailler sur la base de types définis dans le système. Cela interfère également avec le fait que, n'étant pas un développeur de serveur spécialisé, je n'attachais auparavant pas d'importance à un déploiement plus efficace de l'environnement et de nombreux fichiers de configuration ont été créés à la main, tandis que les actions étaient constamment répétées sur chaque nouveau serveur. C'est à ce moment que la compréhension vient qu'une solution en boîte n'est pas une solution à tous les problèmes, et vous devez passer à l'étape suivante de l'organisation de votre serveur pour une application mobile.

Récemment, mon principal langage de développement est Swift.C'est donc lui qui m'intéresse principalement dans l'écriture de code côté serveur. Swift lui-même est facile à installer sur un système Unix, mais il ne donnera aucun avantage évident. À la base, il ressemblera au développement d'une application console avec une logique complexe. Il faudra beaucoup de temps pour recréer les méthodes de base requises sur le serveur.

Comme dans de nombreuses autres langues, swift côté serveur a ses propres cadres et communautés impliqués dans le développement de ces solutions.

À l'heure actuelle, il existe trois solutions les plus importantes pour développer Swift côté serveur:

• Parfait
• Vapeur
• Kitura

Il existe d'autres options, mais elles ne méritent pas d'être mentionnées en raison de leur développement interrompu depuis longtemps et de leur mort.

En termes de documentation et de support, j'aime plus Vapor, mais c'est une question de goût. D'autres solutions seront proches de quelqu'un. D'une manière ou d'une autre, dans de nombreux moments, ils sont similaires.

Naturellement, plus loin dans le cycle d'articles dans mes exemples, j'utiliserai Vapor. Sur cette base, nous mettons en œuvre le service d'enregistrement / autorisation des utilisateurs, l'envoi et la confirmation des e-mails, la possibilité de réinitialiser et de changer le mot de passe.



Vaut-il la peine de faire une implémentation sans bénéfice pratique?

Probablement pas! Par conséquent, nous ferons le service le plus adulte que vous puissiez prendre et utiliser pour organiser la logique de stockage des données utilisateur sur votre serveur.

Si la décision est adulte, elle implique le recours à des décisions délibérées. Nous devons simplifier la mise à l'échelle, implémenter la validation des données et prévoir le stockage de la session utilisateur, afin de ne pas l'obliger à saisir à chaque fois son identifiant et son mot de passe.

De quoi avons-nous besoin pour cela?

• VAPOR 4 (oui, toujours en version bêta, mais la sortie arrive bientôt, comme promis par les développeurs)
• PostgreSQL (il existe un excellent adaptateur pour travailler avec cette base de données)
• Nginx
• SSL (fermez toutes nos demandes du client au serveur à l'aide d'un certificat)
• Localhost (pensez à la méthode de développement localement, afin de ne pas vous attacher au réseau et travailler sur la route sans aucun problème)

Eh bien, nous emballerons tout cela dans Docker pour garantir le même travail, indépendamment de l'environnement d'exécution actuel.

Honnêtement, j'étais sceptique à l'égard du docker à un moment donné, mais j'aurais dû regarder de plus près cette technologie. Le but de l'article n'est pas d'expliquer son travail et d'apprendre à travailler avec lui (je soupçonne que je dois moi-même encore apprendre de nombreuses fonctionnalités intéressantes du docker). Mais ceux qui ne savent pas ce que c'est et comment travailler avec lui peuvent se familiariser indépendamment avec Docker via le lien officiel: www.docker.com Pour l'

avenir, je vais laisser un lien utile vers l'application Kitematic, qui est conçue pour simplifier le travail avec les conteneurs Docker : kitematic.com (indispensable pour ceux qui n'aiment pas utiliser le terminal).

Commençons donc par installer Docker sur un ordinateur Mac: suivez le

lien hub.docker.com/editions/community/docker-ce-desktop-mac et téléchargez Get Docker Desktop For Mac (Stable).



Ouvrez l'image résultante et n'installez rien diffère de la copie standard de l'application dans le répertoire du programme.



Après cela, lancez simplement l'application et attendez que le service soit complètement initialisé.



S'il n'y a pas encore d'ID Docker, alors il doit être créé sur hub.docker.com. Et si c'est le cas, connectez-vous simplement à l'application.



C'est tout, la préparation à l'utilisation de Docker est terminée. Il ne reste plus qu'à vérifier la version actuelle et les informations sur l'environnement.

> version


docker> info docker

Ceci termine la préparation du développement du service d'autorisation. Dans la partie suivante, nous verrons comment vous pouvez utiliser des conteneurs de divers services, nous traiterons de docker-compose pour automatiser l'assemblage de notre environnement et commencer à écrire du code.

PS: Un petit conseil d'expérience personnelle. Lorsque nous développons des services sur notre machine locale, Docker alloue des ressources par défaut à notre usage. Si nous voulons visualiser le comportement attendu du service sur un serveur distant, nous devons nous occuper des ressources sur la machine locale, au plus près des caractéristiques du serveur. Vous pouvez le faire dans les paramètres de l'application Docker Desktop, que nous avons téléchargée:



Auteur de l'article:
Vitaly Podolsky, professeur HackerU