¿Cómo organizar el backend de una aplicación móvil?

¿Que estamos haciendo? Servicio de registro y autorización de usuarios para una aplicación móvil

En los proyectos favoritos de cada desarrollador móvil, tarde o temprano llega un momento en que necesita crear un servidor para su aplicación de manera rápida y sin demasiados dolores de cabeza. No importa qué función debe realizar el servidor: si se trata de almacenamiento de datos o registro / autorización del usuario.

Como regla, al principio todos van (bueno, o la mayoría) por el camino de menor resistencia. Estamos buscando una solución llave en mano y vemos qué tan rápido se puede adaptar a nuestras necesidades.

En esta etapa, lo primero que puede "googlear" son los servicios de Firebase, cuyos límites gratuitos son más que suficientes para organizar el backend de una pequeña aplicación móvil. Pero en este caso, teniendo en cuenta exactamente al desarrollador ruso, corremos el riesgo de pisotear nuestra legislación: la transferencia de datos transfronterizos y el almacenamiento de los datos personales del usuario.

(Ley Federal 152 “Sobre Datos Personales”, Artículo 12, Capítulo 2) La

tentación de usar Firebase es grande, pero si queremos asegurarnos contra el alboroto innecesario con varias agencias de supervisión, comenzamos a buscar opciones alternativas.

La siguiente etapa es el uso de un servidor VDS con algún tipo de solución de código abierto o freemium, donde se toma como base el "servicio como servicio" ya preparado o una solución que permite implementar una funcionalidad similar.

Hace unos años, en Habré, ya escribí una guía detallada para configurar BaasBox (el artículo fue eliminado del público debido a información desactualizada) en un servidor alquilado y di un ejemplo del uso de varias llamadas en una aplicación iOS para el lenguaje Objective C. Pero BaasBox es realmente "pesado" y dicta Su mínimo para un servidor alquilado. Habiendo jugado un poco con él, se decidió usar una solución diferente. En ese momento, el servidor Parse fue recientemente puesto en desarrollo de código abierto por Facebook, no tenía tantos adaptadores como lo es actualmente, pero sus capacidades eran más que suficientes para proyectos personales y aplicaciones de clientes privados (muchos proyectos todavía están existir y trabajar de manera estable).

Para ser justos, vale la pena señalar que el servidor de análisis ha madurado mucho y se está desarrollando activamente. Por el momento, se ha recreado casi toda la funcionalidad que estaba disponible en un antepasado comercial. Puede escribir sus propios ganchos, notificaciones push localizadas, un administrador de procesos e incluso hay una suscripción para cambiar objetos basados ​​en sockets (ParseLiveQuery; si es interesante, escribiré un artículo separado sobre la configuración de ParseLiveQuery).

Pero el servidor de análisis dejó de ser interesante precisamente en el momento en que se requería implementar un tipo de datos no estándar, que es difícil de trabajar sobre la base de los tipos definidos en el sistema. También interfiere con el hecho de que, al no ser un desarrollador de servidores especializado, anteriormente no le daba importancia a una implementación más eficiente del entorno y muchos archivos de configuración se realizaban a mano, mientras que las acciones se repetían constantemente en cada nuevo servidor. Es en este momento cuando se comprende que una solución en caja no es una solución para todos los problemas, y debe pasar a la siguiente etapa de organización de su servidor para una aplicación móvil.

Recientemente, mi lenguaje principal de desarrollo es Swift.Por lo tanto, es él quien me interesa principalmente al escribir código del lado del servidor. Swift en sí mismo es fácil de instalar en un sistema Unix, pero no dará ninguna ventaja obvia. En esencia, se parecerá al desarrollo de una aplicación de consola con lógica compleja. Tomará mucho tiempo recrear los métodos básicos requeridos en el servidor.

Como en muchos otros idiomas, swift del lado del servidor tiene sus propios marcos y comunidades involucradas en el desarrollo de estas soluciones.

Por el momento, hay tres soluciones más importantes para desarrollar swift del lado del servidor:

• Perfecto
• Vapor
• Kitura

Hay otras opciones, pero no vale la pena mencionarlas debido a su desarrollo prolongado y su muerte.

En términos de documentación y soporte, me gusta más Vapor, pero es cuestión de gustos. Otras soluciones estarán cerca de alguien. De una forma u otra, en muchos momentos son similares.

Naturalmente, a lo largo del ciclo de artículos en mis ejemplos, usaré Vapor. En base a esto, implementamos el servicio de registro / autorización de usuarios, enviando y confirmando correos electrónicos, la capacidad de restablecer y cambiar la contraseña.



¿Vale la pena hacer una implementación sin beneficio práctico?

¡Probablemente no! Por lo tanto, haremos el servicio más adulto que pueda tomar y usar para organizar la lógica para almacenar datos de usuario en su servidor.

Si la decisión es adulta, implica el uso de decisiones deliberadas. Debemos simplificar la escala, implementar la validación de datos y proporcionar el almacenamiento de la sesión del usuario, para no obligarlo a ingresar su nombre de usuario y contraseña cada vez.

¿Qué necesitamos para esto?

• VAPOR 4 (sí, todavía en beta, pero el lanzamiento llegará pronto, como prometieron los desarrolladores)
• PostgreSQL (hay un excelente adaptador para trabajar con esta base de datos)
• Nginx
• SSL (cierre todas nuestras solicitudes del cliente al servidor utilizando un certificado)
• Localhost (considere el método de desarrollo localmente, para no conectarse a la red y trabajar en la carretera sin ningún problema)

Bueno, empacaremos todo esto en Docker para garantizar el mismo trabajo, independientemente del entorno de ejecución actual.

Honestamente, era escéptico sobre el acoplador alguna vez, pero debería haber examinado más de cerca esta tecnología. El propósito del artículo no es explicar su trabajo y aprender a trabajar con él (sospecho que yo mismo todavía tengo que aprender muchas características interesantes de la ventana acoplable). Pero aquellos que no saben qué es y cómo trabajar con él, pueden familiarizarse de forma independiente con Docker a través del enlace oficial: www.docker.com

Mirando hacia el futuro, dejaré un enlace útil a la aplicación Kitematic, que está diseñada para simplificar el trabajo con los contenedores docker : kitematic.com (debe tener para aquellos a quienes no les gusta usar el terminal).

Entonces, comencemos instalando Docker en una computadora Mac: siga el

enlace hub.docker.com/editions/community/docker-ce-desktop-mac y descargue Get Docker Desktop para Mac (Estable).



Abra la imagen resultante y luego no instale nada difiere de la copia estándar de la aplicación en el directorio del programa.



Después de eso, simplemente inicie la aplicación y espere hasta que el servicio esté completamente inicializado.



Si todavía no hay una ID de Docker, debe crearse en hub.docker.com y, si existe, simplemente inicie sesión en la aplicación.



Eso es todo, la preparación para usar Docker está completa. Solo queda verificar la versión actual y la información sobre el entorno.

> versión


docker> información de docker

Esto completa la preparación para el desarrollo del servicio de autorización. En la siguiente parte, veremos cómo puede usar contenedores de varios servicios, trataremos con docker-compose para automatizar el ensamblaje de nuestro entorno y comenzar a escribir código.

PD: Un pequeño consejo de experiencia personal. Cuando desarrollamos servicios en nuestra máquina local, Docker asigna recursos predeterminados para nuestro uso. Si queremos visualizar el comportamiento esperado del servicio en un servidor remoto, debemos ocuparnos de los recursos en la máquina local, lo más cerca posible de las características del servidor. Puede hacerlo en la configuración de la aplicación Docker Desktop, que descargamos:



Autor del artículo:
Vitaly Podolsky, profesor de HackerU