Backend as a Service (BaaS) vs Backend a medida: ¿Cuál es la mejor opción para un proyecto de app móvil?

Recientemente hemos heredado un proyecto de un cliente cuyo backend está desarrollado en Firebase. Esto ha reabierto en la empresa el debate sobre qué es mejor para un proyecto de app móvil (o una app en general): un backend a medida o utilizar una solución BaaS (Backend as a Service) como Firebase o Supabase. En este artículo, exploraremos cada opción con sus ventajas e inconvenientes y compartiremos nuestro punto de vista sobre cuándo optar por una u otra opción.

Un BaaS (Backend as a Service) es un servicio en la nube que proporciona infraestructura, herramientas y servicios backend preconstruidos para aplicaciones móviles y web. Las funcionalidades más comunes que ofrecen las plataformas BaaS incluyen:

• Almacenamiento de datos: Bases de datos NoSQL o SQL, almacenamiento de archivos y gestión de objetos.
• Autenticación y autorización: Sistemas de registro, inicio de sesión, gestión de perfiles de usuario e integración con proveedores de identidad (como Google, Facebook o Apple).
• Notificaciones push: Envío de notificaciones a dispositivos móviles o navegadores web.
• Funciones en la nube (Serverless): Ejecución de código personalizado sin necesidad de gestionar servidores.
• Gestión de APIs: Creación automática de APIs REST o GraphQL para acceder a los datos.
• Análisis y monitoreo: Herramientas para hacer un seguimiento del uso de la aplicación, métricas de rendimiento y comportamiento de los usuarios.
• Integración con otros servicios: Conexión con servicios externos mediante APIs o herramientas de automatización.

Algunas de las soluciones BaaS más populares son:

• Firebase: Proporcionado por Google, destaca por sus bases de datos en tiempo real (Firestore y Realtime Database) y su integración con Google Analytics y Crashlytics.
• Supabase: Una alternativa de código abierto a Firebase que utiliza PostgreSQL como base de datos, ofreciendo mayor flexibilidad para consultas complejas e integraciones.
• AWS Amplify: Una solución de Amazon Web Services que permite construir y desplegar aplicaciones escalables.
• Backendless: Otra opción con funcionalidades similares, incluyendo bases de datos, autenticación y funciones en la nube.

Ventajas de los BaaS

1. Barrera de entrada baja

Permite iniciar proyectos con una inversión inicial reducida, disminuyendo la necesidad de conocimientos técnicos avanzados y eliminando la complejidad de gestionar la infraestructura. Esto facilita la validación rápida de ideas y el lanzamiento de productos.

2. Implementación rápida

Una de las principales ventajas de los BaaS es la velocidad de implementación. Con pocas líneas de código se pueden configurar funcionalidades básicas como autenticación, bases de datos en tiempo real o notificaciones push.

3. Costos iniciales bajos

Al tratarse de un backend preconstruido, no es necesario contratar un equipo de desarrollo completo desde el inicio, invertir en la creación de funcionalidades desde cero ni dedicar recursos al mantenimiento de la infraestructura. Además, el modelo de precios basado en el uso permite escalar los costos a medida que el proyecto crece.

4. Escalabilidad automática

Los servicios BaaS gestionan automáticamente la escalabilidad de la aplicación, adaptándose a picos de tráfico o crecimiento de usuarios. Esta flexibilidad permite mantener el rendimiento sin necesidad de intervención manual o ampliaciones de infraestructura.

5. SDKs para múltiples lenguajes

Los BaaS proporcionan SDKs (Software Development Kits) para diversos lenguajes de programación y plataformas, tanto móviles como web. Esto facilita la integración y permite a los desarrolladores utilizar el lenguaje con el que se sientan más cómodos o el que mejor se adapte a las necesidades del proyecto.

6. Herramientas integradas

Plataformas como Firebase no solo ofrecen funcionalidades propias de un backend, sino también herramientas complementarias como Crashlytics (para el seguimiento de errores) y Google Analytics (para el análisis del uso de la aplicación). Esta combinación de herramientas en un único servicio simplifica mucho la gestión de la aplicación.

Inconvenientes de los BaaS

1. Limitaciones de personalización

Los servicios BaaS suelen ofrecer funcionalidades predefinidas para tareas comunes, pero pueden no permitir la implementación de lógica de negocio compleja. Esto puede obligarte a adaptar tu aplicación a las limitaciones del servicio o a buscar soluciones alternativas.

2. Escalabilidad limitada

Aunque muchos servicios BaaS prometen escalabilidad, pueden existir limitaciones técnicas o económicas a medida que tu proyecto crece, especialmente en aplicaciones con necesidades específicas o muy grandes.

3. Dependencia del proveedor (vendor lock-in)

Estás sujeto a los cambios y tarifas del proveedor. Una modificación en los precios o en sus políticas puede afectar significativamente el proyecto. Un ejemplo claro es el cierre de Parse por parte de Facebook, que dejó muchos proyectos sin soporte, obligándolos a migrar de plataforma.

Además, si en algún momento deseas cambiar de plataforma o pasar a un backend a medida, la migración puede ser muy costosa, ya que los datos y la lógica de negocio pueden estar profundamente integrados con el BaaS utilizado.

4. Problemas de seguridad y privacidad

Almacenar datos sensibles en un proveedor externo puede conllevar riesgos de seguridad y problemas de cumplimiento normativo, especialmente en sectores con requisitos estrictos (como el sanitario o el financiero).

5. Costos variables

Si el proyecto crece o se utilizan muchos recursos, el coste del servicio puede aumentar de manera inesperada. Los precios pueden dispararse, especialmente en función del número de llamadas a la API o del espacio de almacenamiento utilizado.

6. Debugging y control del código

En caso de problemas con la API del proveedor, las opciones de depuración pueden ser limitadas y depender completamente del soporte técnico del servicio. Además, la documentación puede no estar siempre actualizada, dificultando la identificación y resolución de problemas.

Un backend a medida es una solución desarrollada específicamente para las necesidades de una aplicación o empresa. Las tecnologías más utilizadas en el desarrollo de backends a medida son:

• Python: Utilizando Django o Flask
• Java: Con Spring Boot
• JavaScript/TypeScript: Con frameworks como Express.js o NestJS
• C#: Principalmente con ASP.NET Core
• PHP: Con frameworks como Laravel o Symfony
• Ruby: Con Ruby on Rails

Esta opción ofrece control total sobre la arquitectura, la lógica del negocio, la seguridad i la integración con otros sistemas.

Ventajas de un backend a medida

1. Personalización y adaptabilidad

Un backend a medida permite adaptar cada detalle de la infraestructura y las funcionalidades a las necesidades de la empresa. Esta personalización garantiza que todos los procesos, flujos de trabajo y funcionalidades encajen perfectamente con los requerimientos del proyecto.

2. Escalabilidad y crecimiento

Facilita la evolución de la solución a medida que el negocio crece, permitiendo añadir nuevas funcionalidades, gestionar un mayor volumen de usuarios o datos y adaptarse a nuevas necesidades sin necesidad de rediseñar completamente el sistema. Esta escalabilidad protege la inversión a largo plazo, evitando cambios radicales en el futuro.

3. Seguridad avanzada y personalizada

Ofrece la posibilidad de implementar medidas de seguridad adaptadas al proyecto, como cifrado de datos, sistemas de autenticación específicos u otras soluciones de seguridad propias del sistema desarrollado.

4. Optimización del rendimiento y eficiencia

Un backend a medida se puede diseñar para maximizar la eficiencia de los recursos disponibles hasta el límite permitido por la propia tecnología, garantizando tiempos de respuesta mínimos y un buen rendimiento incluso en situaciones de alta carga.

5. Control total y mantenimiento simplificado

Al contar con un código limpio y desarrollado específicamente para el proyecto, o con un sistema de logging a medida, es mucho más fácil identificar el origen de un error, analizar su causa y solucionarlo. Esto reduce los tiempos de inactividad y minimiza el impacto de los errores en el funcionamiento del sistema.

Inconvenientes de un backend a medida

1. Coste inicial 

El desarrollo de un backend a medida suele implicar una inversión económica significativa, ya que requiere un equipo técnico especializado y la implementación de las funcionalidades necesarias. Esto puede ser un obstáculo para proyectos con presupuestos limitados.

2. Tiempo de desarrollo

Crear un backend a medida puede llevar semanas o incluso meses, dependiendo de la complejidad del proyecto. A diferencia de las soluciones estándar o prefabricadas, el tiempo necesario para diseñar, desarrollar, probar e implementar es considerablemente mayor.

3. Dependencia del proveedor

Si el backend es desarrollado por una empresa externa, la empresa puede depender de este proveedor para el mantenimiento, la resolución de problemas y las actualizaciones. Esto puede generar costos recurrentes y posibles dificultades si el proveedor deja de estar disponible.

Si en algún momento quieres cambiar de proveedor, será necesario encontrar a alguien que trabaje con las mismas tecnologías, lo cual no siempre es sencillo.

4. Riesgo de errores

El desarrollo a medida implica escribir nuevo código, lo que aumenta la probabilidad de introducir errores. Estos problemas pueden afectar el rendimiento del sistema y requerir más tiempo para su identificación y resolución.

5. Mantenimiento y actualizaciones

Un backend a medida necesita mantenimiento continuo para garantizar su funcionamiento, seguridad, rendimiento y compatibilidad con otros sistemas. Esto implica dedicar recursos técnicos periódicamente para adaptarlo a nuevas necesidades o cambios tecnológicos.

Ahora que hemos revisado las ventajas e inconvenientes de cada una de las posibilidades, la siguiente pregunta que debemos hacernos es en qué casos vale la pena utilizar un BaaS y en cuáles es necesario desarrollar un backend a medida.

Cuándo optar por un BaaS:

• Prototipos y MVPs (Minimum Viable Product): Si necesitas lanzar rápidamente un producto al mercado para probar una idea.
• Aplicaciones sencillas o con funcionalidades estándar: Por ejemplo, chats, aplicaciones sociales básicas, formularios de datos o aplicaciones internas simples.
• Proyectos con un presupuesto reducido: Ahorra tiempo y costos en el desarrollo del backend.
• Aplicaciones con una duración temporal limitada: Si tienes claro que en el futuro no se añadirán nuevas funcionalidades.

Cuándo optar por un backend a medida:

• Aplicaciones con lógica de negocio compleja: Cuando se necesitan procesos complejos, reglas de negocio personalizadas o integraciones a medida.
• Requisitos de seguridad elevados: Cuando se tienen necesidades específicas en materia de seguridad o regulaciones (por ejemplo, datos sensibles, GDPR, HIPAA…).
• Necesidad de control total sobre la infraestructura: Si se quiere personalizar la base de datos, la estructura del servidor u optimizar el rendimiento.
• Evitar dependencias de terceros: Especialmente en proyectos a largo plazo donde se busca minimizar riesgos asociados a la dependencia tecnológica.

¿Tiene sentido una solución híbrida?

En algunos casos, puede ser interesante utilizar una combinación de ambas soluciones. Por ejemplo, se puede desarrollar un backend a medida para gestionar la lógica de negocio y los datos sensibles, mientras se utiliza un BaaS para funcionalidades más estándar, como:

• Autenticación y social login.
• Envío de notificaciones push.
• Análisis de uso.

Esta estrategia permite aprovechar la rapidez y simplicidad de los BaaS sin sacrificar la flexibilidad y el control de un backend personalizado.

Con la experiencia que tenemos en app2U, recomendamos utilizar un backend a medida como opción predeterminada para proyectos que busquen estabilidad y crecimiento a largo plazo. Un backend a medida permite tener todo el sistema centralizado y bien estructurado por capas, ofreciendo una base sólida para el desarrollo continuo.

Para nosotros, también tiene sentido implementar algunas funcionalidades directamente con un BaaS, como las que se plantean en la solución híbrida, pero siempre teniendo en cuenta que la base debe ser el backend a medida.

Dicho esto, ¿cómo podemos minimizar el impacto de los inconvenientes de desarrollar un backend a medida? Algunos consejos que aplicamos en cada proyecto:

1. Definir claramente los requisitos: Antes de comenzar el desarrollo, asegúrate de tener muy claras las funcionalidades y necesidades del proyecto. Una buena documentación inicial ayuda a evitar cambios imprevistos que pueden aumentar costos y tiempos.
2. Selecciona un proveedor de confianza: Busca empresas con experiencia demostrable, un buen historial de proyectos similares y capacidad para ofrecer mantenimiento y soporte a largo plazo. Aspectos clave a tener en cuenta:
   1. Confianza: Como hemos dicho, debe transmitir confianza, tanto a nivel empresarial como personal.
   2. Desarrollo iterativo: Es importante poder ver el resultado del proyecto a medida que avanza.
   3. Testing automático: El desarrollo de tests tiene que formar parte del propio desarrollo de la solución para asegurar que esta crezca sin romper nada.
   4. Documentación: Solicita que la documentación técnica esté incluida en el alcance del proyecto, ya que no siempre se hace por defecto.
   5. Propiedad del código: Asegúrate de que el código desarrollado es tuyo para evitar el vendedor lock-in.

A corto plazo, esto puede hacer que el proyecto sea más costoso, pero a largo plazo, estos aspectos pueden ahorrarte mucho dinero.

3. Prever mantenimiento y actualizaciones: El software a medida requiere dedicar recursos recurrentes al mantenimiento, al menos adaptativo, para garantizar que siga funcionando. Tenlo en cuenta.

Al principio del artículo hablábamos del proyecto heredado del cliente. La situación actual es que hemos migrado toda la capa de negocio a un backend a medida, y el resultado es que ahora tenemos mucho más control sobre lo que ocurre en la solución. La lógica de negocio está centralizada en un solo punto, los datos son más consistentes (Firebase permitía datos incoherentes) y, gracias a esto, el número de problemas se ha reducido drásticamente. 😊