El pasado 23 de febrero de 2018 pusimos punto y final a nuestro Bootcamp Mobile en KeepCoding, concretamente a la 4ª edición. En el camino aprendimos a crear y gestionar todo lo relacionado con una APP como podría ser Instagram, WhatApp o Facebook.
El último paso del Bootcamp fue presentar delante de nuestros compañeros, instructores y empresas el resultado de muchos meses de aprendizaje plasmado en un proyecto real. Para nuestro proyecto final formamos un grupo de 5 y, si en algo estábamos de acuerdo, era que queríamos desarrollar algo que fuera nuevo, actual y que sobre todo estuviera a la altura tecnológica de las aplicaciones más utilizadas hoy en día.
Synergy
Finalmente decidimos crear Sinergy: una plataforma para mejorar la motivación en las empresas. Un tema al que cada día se le da más importancia. Algunas empresas creen que juntando el talento es suficiente, pero si consigues que este talento además este motivado y remando hacia una misma dirección, se pueden conseguir excepcionales resultados.
No tuvimos mucho tiempo para explicar la parte técnica (la parte de la que estamos más orgullosos) así que aprovechamos para detallarla a continuación:
La arquitectura de los gigantes
Las empresas que aprenden a manejar más datos por segundo son las que consiguen ventaja competitiva. Es el caso de los líderes de la industria tecnológica. Los equipos de Facebook, Amazon, Airbnb o Netflix no nos dejan de sorprender con la cantidad de datos que son capaces de procesar , manteniendo a la vez la alta disponibilidad que las define. La grandeza de estas plataformas está en algo que los usuarios ni saben que existe; la arquitectura serverless utilizando microservicios.
Una arquitectura basada en microservicios es una forma de desarrollar aplicaciones como un conjunto de servicios modulares e independientes. Cada servicio ejecuta un proceso único, comunicándose entre ellos de forma ligera y bien definida para cumplir un objetivo comercial.
Nuestro backend
En el mercado existen varias opciones para crear una arquitectura serverless: AWS, Azure o Firebase son las más conocidas. Escogimos AWS porque nos ofrecía todo lo que necesitábamos y a la vez ha liderado durante muchos años el mercado del cloud.
Lo primero era crear nuestra API: AWS API Gateway es un servicio en AWS para la administración, creación, publicación y mantenimiento de una API a cualquier escala. Esta interfaz es nuestra puerta de entrada para que las apps puedan acceder a los datos y a la lógica de negocio. Las rutas creadas en API Gateway se pueden enlazar a una función Lambda o a cualquier aplicación web. Es capaz de aceptar y procesar hasta cientos de miles de llamadas API simultáneas, incluyendo la seguridad, la administración del trafico y la supervisión de las versiones.
La parte más importante de AWS API Gateway es que su escalabilidad es elástica, es decir, que su capacidad se amplia o disminuye según la cantidad de peticiones que recibe.
Lo segundo era crear nuestra lógica de negocio. AWS Lambda ofrece la posibilidad de ejecutar código sin tener la necesidad de mantener los servidores ni aprovisionar el código, solo se paga por el tiempo de ejecución que se consume. Para cada historia de usuario creábamos una función Node.js y la subíamos como una función Lambda. Está la enrutabamos en una nueva versión de la API Gateway y ya estaba accesible para ser ejecutada des de cualquier parte del mundo.
Al igual que API Gateway, AWS Lambda también escala de forma automática según el número de ejecuciones. El código ejecuta en paralelo y los procesa de forma individual, escalando según la carga de trabajo que le llega por las peticiones de la API Gateway.
También era necesario tener persistencia de datos. AWS ofrece varias posibilidades, pero nosotros nos decantamos por DynamoDB. Amazon DynamoDB es un servicio de base de datos NoSQL rápido y flexible para todas aquellas aplicaciones que requieren de una latencia de mili segundos a cualquier escala, perfecto para nosotros.
Nuestro trabajo fue el de crear las tablas y establecer las claves primarias y de búsqueda. Al igual que toda la arquitectura serverless, DynamoDB no requiere de una administración de servidores por nuestra parte. Se auto escala de forma dinámica y su respuesta es súper rápida.
A parte de la persistencia de datos también debíamos poder guardar ficheros, documentación, imágenes y todo lo que haga falta, por lo que configuramos Amazon S3 para poder guardar de forma segura los ficheros de nuestros clientes.
Y para finalizar debíamos hacer seguro todo nuestro backend, y escogimos utilizar AWS Cognito. Con Cognito pudimos crear y administrar todos los procesos relacionados con la autentificación en nuestros clientes mobile y web.
No fue fácil de configurar en todos nuestros clientes: web, iOS y Android, pero, una vez lo conseguimos, procesos como la recuperación de contraseña, la autentificación de doble paso o identificación por envío de código SMS ya los teníamos resueltos.
Hay que destacar que al inicio del proyecto, nuestra experiencia en AWS era poca. Pero el reto de poder crear toda una infraestructura serverless con AWS era muy motivador para todos los integrantes del equipo. No fue nada fácil porque muchas de las configuraciones que requerían nuestras historias de usuario necesitaban de un experto en AWS.
Finalmente conseguimos desplegar toda nuestra infraestructura y este es un esquema del resultado.
Nuestros clientes
3 actores; las empresas, los trabajadores de las empresas, y los proveedores. 3 clientes; un cliente web, un cliente iOs y un cliente Android. Cada actor tenía unos casos de uso totalmente distintos a los otros y cada cliente era distinto a cuanto funcionalidad.
El primer cliente que desarrollamos fue el “Manager para la empresa”. Este cliente web permite a la empresa registrarse, gestionar sus trabajadores, departamentos y crear actividades para su empresa.
Otro cliente necesario era el “Manager para los proveedores”. Este cliente totalmente diferenciado del de empresa, da la posibilidad a los proveedores de crear sus servicios y darlos a conocer en nuestra plataforma. También gestiona los pagos por parte de las empresas a los proveedores y permite tener una gestión de disponibilidad de las actividades. Cada manager está diferenciado, pero todos se conectan a nuestro backend vía las API Gateway.
Desarrollamos estos clientes web en Angular 4. Éste nos ofrecía la posibilidad de programar en Typescript que lleva integrada muchas características de ES2016+. Angular también nos ofrecía un alto rendimiento y capacidad de respuesta, que junto a nuestro backend con vitaminas proporciona una respuesta inmediata.
Los clientes mobile los desarrollamos de forma paralela. Cada cliente está desarrollado de forma nativa, utilizando Java para Android, y Swift para iOs. En ambos casos decidimos utilizar Clean Architecture ya que nos permitió crear diferentes implementaciones para cada caso de uso. Para cada uno de ellos creamos una implementación Dummy y una implementación connectada a nuestro Backend. De esta manera si el backend estaba caído por cualquier razón o todavía no estaba desarrollado, el compañero que estuviera trabajando en la app mobile podia seguir su desarrollo.
Aparte de la arquitectura también utilizamos librerías como RxSwift o Alamofire para ayudarnos en el desarrollo.
El equipo y metodología de trabajo
Durante todo el proyecto hemos trabajado con la metodología ágil SCRUM pasándonos el rol entre nosotros de Scrum Master y siendo nuestros instructores el Product Owner.
Hemos utilizado Gitlab para el control de versiones y nos hemos comunicado por Slack y hangout.
Estos han sido los integrantes del equipo:
- Eric Risco Web – Linkedin – Github
- Paco Cardenal Web – Linkedin – Github
- Eugenio Barquín Linkedin – Github
- Begoña Hormaechea Linkedin
- Alberto Galera Linkedin
¿Y ahora que?
4 sprints de dos semanas cada uno, largas horas nocturnas desarrollando, todo a un propósito: aprender. La experiencia que nos ha dado este proyecto no tiene precio. Y cuando hablamos de experiencia nos referimos a los fracasos y frustraciones pero sobretodo a todo lo que hemos aprendido superando y solucionando lo que no funcionaba.
El resultado es un MVP totalmente funcional, que a falta de afinar algunos procesos y un poco de diseño estaría preparado para el mercado. Todo esto teniendo en cuenta que la aplicación ya es autoescalable y tiene una alta disponibilidad, es decir, que podria soportar miles de usuarios recurrentes.
Por: Eric Risco de la Torre
Si tienes algo que deseas compartir o quieres formar parte de KeepCoding, escríbenos a [email protected].
