Spike: Backend as a service

[erikasv]

Para el módulo de indicadores nos gustaría explorar un servicio que nos sirva el backend, ya que es una estructura muy sencilla la que tenemos en este caso y potencialmente no es la definitiva.

Requerimos poder consultar registros de una tabla de datos alfanuméricos. Esta consulta se debe poder filtrar por otros campos de la misma tabla. No hay preferencias sobre los servicios, pero se recomienda usar algo similar a Firebase de google.

[erikasv]

Encontré varias opciones y aquí destaco las que me parecen mejor opción:

1. Parse: definitivamente la ganadora, es un framework opensource con una gran comunidad detrás para su mantenimiento, sin embargo no está alojada en ningún lado y toca desplegarla en infraestructura propia. El componente principal es el servidor, se puede ejecutar como una aplicación de node, pero también trae su dockerfile, pude construir la imagen y levantar el contenedor rápidamente y sin inconvenientes. Otro componente de mucha ayuda es el dashboard, que permite visualizar y administrar datos y otras cosas, como probar el API. Finalmente se complementa con modulos de la comunidad para extender las funcionalidades del servidor y muchos SDK para hacer la vida más fácil desde los clientes que van a usar el backend.

2. Agrupo en este punto 3 opciones, sólo analizadas desde las características que exponen en su página de precios, todas tienen un plan gratis y con respecto a ese se que las ordeno, de la más interesante a la menos.

   1. backendless: Es la opción gratis más generosa, pero hay una nota en ese plan que no logré descifrar, no sé si tenga algunas condiciones especiales para poder acceder a ella.
   2. back4app: Corre parse por debajo, y dice que trabajan con sólo open source
   3. Firebase: De los servicios más populares y que integra muchas (demasiadas) más funcionalidades y analíticas que pueden ser interesantes, pero que creo que para nosotros no (aún).

   Las características en las que más me fije fueron las siguientes:

   Servicio	Petitiones/mes	Almacenamiento de datos	Almacenamiento de archivos
   backendless	∞	200 tablas de 400k registros	1GB
   back4app	25k	250MB	1GB
   Firebase	Está separado en autenticación, escritura, lectura, eliminación	1GB	5GB

3. Finalmente no quise descartar el servicio de AWS Amplify porque es la nube que tenemos, pero no entendí muy bien cómo funciona, parece que se lograría tener un BaaS pero hay que armar las partes? 🤷‍

Los etiqueto a todos para que les llegue el comentario al correo. @danflop @cazapatamar @Trjegul84 @alegnaaived

[erikasv]

Hemos reabierto esta tarea para documentar una prueba de concepto con los 3 servicios listados, los repartimos de la siguiente forma:

• [x] @erikasv probará backendless
• [x] @alegnaaived probará back4app
• [x] @Trjegul84 probará Firebase

Por favor documentar las pruebas como comentarios en esta tarea.

[Trjegul84]

Se realizó una prueba con Firebase, consistió en un pequeño frontend que se conecta con un almacenamiento NoSQL Firestore. Se logró ejecutar con éxito las operaciones básicas CRUD sobre una colección.
La configuración es relativamente sencilla y fácil de realizar en el modo de pruebas. No se probó el modo desarrollo pero se identifica que en ese caso se deben tener en cuenta las credenciales de autenticación para acceder al backend Firebase. Además los cargos del tipo de plan.

Las ventajas que se observan de usar Firebase son su facilidad de uso, que tiene opciones de configuración de reglas para la base de datos, y para opciones para indices que permiten optimizar búsquedas más comunes en las colecciones. Además no requiere tarjeta de crédito para su configuración. Otro aspecto muy bueno es que se puede integrar fácilmente con Google Analitics y tener las gráficas en tiempo real de todos los parámetros de uso y operaciones realizadas en el backend.

Los costos son considerablemente bajos si se maneja un volumen de datos pequeño.

Si se hay documentación en la web, aunque en muchos casos esta desactualizada y se debe adaptar al framework usado. Para el caso de React fue necesario realizar varias pruebas hasta encontrar las funciones correctas para ejecutar acciones sobre las colecciones. Ver Documentación de Firebase

[alegnaaived]

WIP - Revisión de back4app;

La cuenta gratuita no necesita tarjeta de crédito y se encuentran alojados en AWS. No permite configurar SSL/HTML personalizado ni verificación de correo electrónico personalizada (pero sí tiene verificación de correo).

Tiene límite de carga de archivos hasta 20 MB y sólo en los planes de más de 200USD por mes se permite cambiar este límite. Permite sólo 1 Cron Job o Cloud Code en la versión gratuita. Sobre soporte, no tiene monitoreo continuo.

Sobre el desempeño ante solicitudes es bajo según sus planes porque va hasta 10 solicitudes por segundo y en el plan pago más caro va por encima de 50 solicitudes por segundo.

Me registré y en 2 minutos estaba la configuración de prueba:

Me pareció muy bonito el recorrido que va haciendo de la herramienta:

Y en la misma guía de la herramienta hacen una demostración:

Me confundí con la documentación back4app, porque no sabía sobre los objetos de Parse. Después de leer sobre eso, comprendí que podía hacer esta prueba rápida con Javascript.

Al hacer pruebas, lo único que me pareció raro es que si no está creado el objeto en la base de datos, entonces Back4app o Parse deciden crear el objeto con los campos que están en el código:

• Vista en el navegador:

• Vista en el dashboard de Back4app:

Por último, para comparar precios, me parece que esta imagen compara y resume los tipos de planes:

[erikasv]

En el caso de backendless tampoco hubo necesidad de tarjeta de crédito y, la configuración inicial y la creación de la aplicación fue muy sencilla.

Para esquemas sencillos funciona muy bien y se pueden exportar las especificaciones del API a difrentes formatos, como swagger o postman collection. Las relaciones no funcionaron muy bien para nuestro caso de uso (no admite relaciones N:M)

La interfaz se siente un poco cargada con todas las opciones, pero es que tiene muchas funcionalidades, para ayudar con esto existen unos tutoriales interactivos que deberíamos hacer en caso de seleccionar eta opción. El código que genera para los clientes es un poco confuso, pero esto ocurre porque es muy general, igualmente se realizaron pruebas exitosamente desde insomnia.

La desventaja que le veo es que a pesar de manejar una base de datos NoSQL no admite que un campo sea de tipo arreglo, en ese caso toca manejar un text separado por comas o un json y tener doble llave.

Faltó probar la funcionalidad de importar datos, se puede explorar en caso de resultar seleccionado, para facilitar la carga de los indicadores que nos entregaron.

[Trjegul84]

En Firebase si se puede tener documentos con elementos de tipo array. Sin embargo, hay ciertas consideraciones que deben tenerse en cuenta como:

• Un arreglo no puede contener otro valor de arreglo como uno de sus elementos.
• En los arreglos, los elementos conservan la posición que se les asignó. Para ordenar dos o más arreglos, se debe realizar con base en los valores de sus elementos.
• Existe el operador array-contains para filtrar en función de los valores del arreglo.Puedes usar como máximo una cláusula array-contains por consulta. No puedes combinar array-contains con array-contains-any.
• Se puede usar el operador in para combinar hasta 10 cláusulas de igualdad (==) en el mismo campo con un OR lógico. Una consulta in muestra documentos en los que el campo dado coincide con cualquiera de los valores de comparación.
• Las consultas not-in excluyen los documentos en los que no existe el campo especificado. Un campo existe cuando se configura con cualquier valor, incluida una string vacía (""), null y NaN (no un número). Ten en cuenta que x != null se evalúa como undefined. Una consulta not-in con null como uno de los valores de comparación no coincide con ningún documento.
• Se advierte que una cláusula de consulta not-in puede coincidir con muchos documentos de una colección. Para controlar la cantidad o los resultados que se muestran.
• Los operadores in, not-in y array-contains-any admiten hasta 10 valores de comparación.
• Puedes usar como máximo una cláusula in, not-in o array-contains-any por consulta. No puedes combinar estos operadores en la misma consulta.
• No puedes combinar not-in con no es igual a !=.
• No puedes ordenar tu consulta por un campo incluido en una cláusula de igualdad (==) o in.
• Cloud Firestore proporciona compatibilidad limitada con las consultas OR lógicas. Los operadores in y array-contains-any son compatibles con un OR lógico de hasta 10 condiciones de igualdad (==) o array-contains en un solo campo. En otros casos, crea una consulta independiente para cada condición de OR y combina los resultados en tu app.
• En una consulta compuesta, las comparaciones de intervalo (<, <=, > y >=) y desigualdad (!= y not-in) deben aplicar filtros en el mismo campo.
• La suma de filtros, órdenes y la ruta del documento principal (1 para una subcolección o 0 para una colección raíz) en una consulta no puede ser mayor que 100.
• Inconveniente con función array Update. Esta opción no está disponible porque para actualizar un elemento en un array de Firestore necesitamos conocer su índice, y Firestore no tiene la capacidad de actualizar un elemento existente por su índice. Así que la única opción que tenemos para realizar una actualización es añadir un nuevo elemento al array usando arrayUnion() y eliminar un elemento existente usando arrayRemove() como se describe en la documentación.