Muchas veces, surge la idea de tener dos proyectos de aplicaciones distintas dentro de un mismo proyecto; es decir, tener un proyecto de Delivery (conformada por 4 aplicaciones), y un proyecto de paquetería (conformado por 3 aplicaciones), todo esto en un proyecto que suma un total de 7 aplicaciones. Es de tener en cuenta que estas 7 aplicaciones comparten la misma base de datos en Firebase.
Alguna de las razones por las que no se sugiere realizar esta practica son las siguientes:
-
No podrás tener un manejo de tus gastos en tu cuenta de Firebase, al estar en el mismo proyecto, estos compartirán la misma base de datos, si de repente comienza a tener altas facturaciones de Firebase, no sabrás si esas facturaciones las causa la App de Delivery o la App de paquetería, por tanto, no podrías optimizarlas ya estando en producción, perdería visión en eso.
-
Pierdes los beneficios de las capas gratuitas tanto en Firebase como de Google API Key. Al tener dos proyectos en uno solo, los llamados a la base de datos de Firebase, como el consumo de los servicios de Google aumentan, lo que ocasiona que ambos proyectos salgan de la capa gratuita en menos tiempo a comparación de solo tener uno solo. Esto ocasionara que comiences a ver facturación por parte de Firebase y Google antes de lo pensado.
-
Se vuelve compleja la gestión de la base de datos a la hora de hacer modificaciones a una de las Apps y se puede cometer el error de tocar la lógica de la otra aplicación de forma involuntaria, ya que al estar compartida, si no se tiene diferenciada cada colección, podrías dañar la otra aplicación accidentalmente.