Patrones en Backend de Servicios para Web y Móvil
Supongamos por un momento que necesitamos diseñar una aplicación con soporte para clientes Móviles y Web. También necesitamos que la solución sea escalable, elástica de acuerdo a la demanda de recursos, con alta disponibilidad de servicio, resiliente ante fallas y capaz de recuperar sus servicios en tiempos específicos de tolerancia. Además que sea tan flexible como para integrarle servicios extras.
Podemos acudir a los servicios en la nube para diseñar soluciones para cumplir ese tipo de requerimientos. Tenemos grandes proveedores de servicios en la nube tales como Google o Amazon. Este artículo es dedicado a los servicios proporcionados por Google a través de Google Cloud Platform.
Lo primero es saber qué, Google Cloud Platform cuenta con un extenso catálogo de servicios y por ende son múltiples las alternativas a la hora de diseñar un sistema en base a dichos servicios. Dependerá de la elección correcta de dichos servicios el proveer a los clientes móviles y web un backend de servicios que esté a la altura de los requerimientos.
Existen unos patrones comunes que pueden ser tomados como referencia para iniciar el diseño del backend de servicios de la solución.
El objetivo de este artículo es proporcionar una guía de los patrones comunes que podrían ser considerados a la hora de planear el diseño de una solución. Este artículo toma como referencia un artículo muy recomendado publicado por Google y conocido como Mobile app backend services.
Patrón 1: With Firebase and Client Library/SDKs
En este patrón, Firebase es la plataforma usada para la integración de Cloud Services. Servicios de almacenamiento, de base de datos, de analítica, de Inteligencia Artificial (IA), de operaciones, entre otros.
¿Por qué integrar los servicios a través de Firebase? Lo primero es saber qué Firebase es una extensión de GCP que permite adherir de una forma ágil y flexible a las soluciones Móviles o Web capacidades tales como Push notificaciones, Testing, Real time, entre otras. Capacidades muy comunes en soluciones móviles como autenticación y autorización a través de redes sociales e incluso servicios de AI pueden ser integrados rápidamente a través de Firebase.
La integración a Firebase se hace a través de Client Libraries y SDKs proporcionados por Google para cada una de los sistemas operativos, es decir, para Android, iOS y Web.
Como una mejora, podría implementarse en cada uno de los clientes un Rx wrapper capaz de llevar las operaciones al mundo Reactive. De tal forma que la capa de datos (data layer) de la aplicación cliente utilizaría las ventajas de Functional y Reactive Programming. Los wrappers podrían ser construidos con RxJava para los clientes Android, RxSwift para los clientes iOS y RxJS para los clientes Web. A través de la aplicación de buenas prácticas en la implementación con Rx (The Clean Way to Use Rx) podría obtenerse un buen diseño en la capa de datos. Hay otras alternativas tales como Coroutines para el caso de Android o Combine para el caso de iOS, sin embargo este artículo se refiere las extensiones Rx.
El lector podrá notar que la implementación de este patrón trae sus ventajas y desventajas. La principal ventaja obtenida al aplicar este patrón es dotar a los clientes Móviles y Web de un backend de servicios de forma ágil y flexible. Un patrón apropiado para una rápida implementación de un backend de servicios para efectos de un prototipo, validación de un producto o desarrollo rápido de un producto.
Quizás de las desventajas más evidentes es el hecho de requerir de implementación de lógica de integración en cada uno de los clientes sin la oportunidad de poder compartir la implementación, ya que recordemos qué, Firebase no aplica ninguna lógica en el ámbito de servidor o backend.
Para los casos en los que se requiere a través de Firebase ejecutar ciertos procesos en el ámbito de backend, se plantea el siguiente Patrón 2.
Patrón 2: With Firebase and Extended Capabilities
Este patrón es similar al Patrón 1 con una variante que permite extender las funciones de Firebase a través de los servicios de cómputo y contenedores.
En GCP dentro de la familia de servicios de cómputo encontramos Compute Engine, App Engine o Cloud Functions, entre otros. Y en la familia de contenedores encontramos Kubernetes Engine, Cloud Run, entre otros. A través de la adición de estas dos familias de servicios se puede dotar a la solución de capacidades para procesar, transformar, monitorear o ejecutar cualquier tarea necesaria en el ámbito de servidor.
Para crear un buen diseño es importante conocer cada uno de los servicios, ya que cada servicio tiene sus cualidades específicas, por ejemplo, si se elige Compute Engine se podría realizar actualizaciones de software a demanda con un mayor control sobre las instancias, sin embargo su capacidad de auto escalamiento y balanceo de carga no sería automática, habría que configurarla. Caso contrario sería al elegir App Engine por ejemplo, en donde estas capacidades son automáticas por ser entre otras cosas un servicio sobre el modelo Cloud Computing PaaS.
También de acuerdo a la naturaleza de la tarea se podría elegir servicios tales como Cloud Run o Cloud Function para aquellos casos en donde se requieren microservices en un modelo altamente administrable como FaaS o CaaS. Estos servicios también son adecuados para aquellas tareas a demanda que requieran solamente unos cortos tiempos de ejecución de forma desacoplada y asincrónica en un diseño Event-driven o Serverless.
La integración del lado del cliente se mantiene similar a la presentada en el Patrón 1, a través de Client Libraries, SDKs y Rx Wrappers.
Esta propuesta ofrece entonces las mismas ventajas que el Patrón 1 con la ventaja adicional de agregar capacidades de servidor para la operación de tareas. De igual forma mantiene la misma desventaja de delegarle parte de la lógica de integración a los clientes en capas no compartidas.
Patrón 3: With REST or gRPC API published on Server Side
Este patrón comparado con los dos anteriores tiene como variante la ausencia de Firebase. En este caso se delega la publicación de las APIs y los servicios de backend a las diferentes opciones de cómputo y contenedores proporcionados por Google Cloud Platform.
Estos servicios de backend pueden a la vez ser integrados con otros servicios de base de datos tales como Firestore, Cloud SQL, Cloud Spanner, entre otros. Servicios de almacenamiento tales como Cloud Storage, Filestore, entre otros. Servicios de analítica tales como BigQuery, entre otros. Servicios de operaciones tales como Cloud Monitoring, Cloud Logging, Error Reporting, entre otros.
Se usa REST o gRPC como los protocolos para integración de las APIs. Es importante analizar que los servicios elegidos soporte el protocolo deseado y tener en cuenta los lenguajes de programación que puede soportar cada servicio. Por ejemplo, App Engine proporciona dos opciones, Standard y Flexible, cada opción soporta un determinado conjunto de lenguajes de programación.
Del lado de la integración a los clientes, se podría usar las diferentes opciones de clientes REST que a la vez soportan Rx. Por ejemplo, del lado de Android se podría usar Retrofit y del lado de iOS se podría usar RxAlamofire las cuales son Client Libraries REST que incluyen el soporte de Rx. En el caso de los clientes Web, Angular por ejemplo, viene con el soporte de RxJS por defecto.
Una de las ventajas de este patrón es permitir que el diseño de la solución se ajuste al Cloud Computing Model más adecuado. Esto dependerá del tipo de servicio elegido que como sabemos podría ser IaaS, CaaS, PaaS o FaaS dependiendo si se elige Compute Engine, Kubernetes Engine, App Engine, Cloud Functions, por dar un ejemplo.
Otra ventaja es la posibilidad de compartir lógica de aplicación o negocio a través de los diferentes clientes por estar ubicada ahora del lado de servidor.
Como desventaja se podría mencionar que al no contar con Firebase, se estaría omitiendo las grandes capacidades que esta plataforma proporciona.
Patrón 4: With REST or gRPC API published on Server Side
Este patrón es similar al Patrón 4 con una variante que adiciona un gestor de APIs. Esta adición representa una mejora, ya que se le delega la administración de las APIs a otro componente y se extiende la capacidad de monitorear dichas APIs. Además se podría agregar una capa de seguridad a las peticiones realizas a la API. Google Cloud Platform provee las siguientes opciones para gestionar las API se encuentran Cloud Endpoints, Apigee o API Gateway.
La integración del lado del cliente se mantiene similar a la presentada en el Patrón 3, a través de Client Libraries que incluyen el soporte a Rx.
Conclusión
Esto claro es solo un rasguño de las posibles alternativas que podrían ser consideradas al momento de diseñar una aplicación Móvil o Web. A la hora de diseñar influirá notablemente los requerimientos funcionales y técnicos. Lo importante a resaltar es la gran variedad que los proveedores de servicios en la nube como los lo es Google Cloud Platform ofrecen y ponen a disposición. Es clave y fundamental conocer muy bien cada servicio, sus ventajas y desventajas, hasta dónde son adecuados elegirlos y sus tarifas de costos.
ConversionConversion EmoticonEmoticon