Capítulo 3 — Creación y organización de proyectos en Firebase¶

Recursos visuales propuestos¶

Antes de desarrollar el capítulo, conviene seleccionar recursos visuales que acompañen la parte práctica sin saturar al lector con diagramas innecesarios. En este tema, varias ideas son operativas y pueden explicarse mejor con imágenes educativas, mientras que las relaciones estructurales sí justifican SVG.

Imágenes didácticas¶

Pantalla de creación de un proyecto. Se recomienda como imagen didáctica porque el objetivo es familiarizar al lector con la experiencia de la consola y reducir la fricción inicial. Aquí no hace falta modelar una arquitectura compleja, sino reconocer una interfaz y entender qué decisiones se toman en ella.[cite:2]
Comparación Spark vs Blaze. Se recomienda como imagen didáctica porque funciona mejor como cuadro visual de contraste entre modelo sin costo inicial y modelo de pago por uso. El lector necesita claridad rápida, no un diagrama técnico.[cite:1]
Organización Development → Testing → Production. Se recomienda como imagen didáctica porque el concepto principal es pedagógico: visualizar separación de ambientes y progresión del trabajo. Una ilustración educativa transmite mejor esta idea que un SVG demasiado cargado.
Ejemplo de estructura profesional de proyectos. Se recomienda como imagen didáctica porque resume una recomendación organizativa para empresas o equipos pequeños. Su finalidad es comparativa y orientativa.

Diagramas SVG¶

Relación entre Firebase Project y Google Cloud Project. Se recomienda como SVG porque representa una relación estructural precisa: un proyecto Firebase es también un proyecto de Google Cloud, comparte identificadores, permisos, facturación y recursos.[cite:2][cite:3]
Flujo de organización de múltiples ambientes. Se recomienda como SVG porque muestra cómo se separan desarrollo, pruebas y producción, y cómo se conectan con despliegues y equipos. Aquí sí existe flujo técnico y jerarquía.
Arquitectura de proyectos empresariales. Se recomienda como SVG porque involucra múltiples proyectos, miembros, roles, entornos y posibles integraciones con Google Cloud. Su valor está en la precisión estructural y en la posibilidad de crecer sin perder legibilidad.

Objetivos de aprendizaje¶

Al finalizar este capítulo, el lector será capaz de:

Comprender qué es un proyecto de Firebase y por qué representa la unidad organizativa superior de la plataforma.[cite:2][cite:3]
Explicar la relación entre Firebase Project y Google Cloud Project, incluyendo identificadores, permisos y facturación compartidos.[cite:2][cite:3]
Crear un proyecto desde cero en Firebase Console entendiendo el propósito de cada decisión inicial.[cite:2]
Diferenciar correctamente los planes Spark y Blaze, y saber cuándo conviene pasar de uno a otro.[cite:1]
Diseñar una organización profesional con múltiples ambientes para desarrollo, pruebas y producción.[cite:2]
Definir convenciones de nombres, estructura de equipos y configuración inicial antes de escribir la primera línea de código.

Introducción¶

Crear un proyecto en Firebase parece una tarea simple, pero en realidad es una decisión arquitectónica temprana. Desde ese momento quedan definidos el contenedor de recursos, la relación con Google Cloud, la forma en que se organizarán las aplicaciones, la estrategia de permisos y, en muchos casos, la base de costos y despliegue del sistema.[cite:2][cite:3]

Por eso, un enfoque profesional no consiste solo en pulsar Create project. Consiste en entender qué se está creando, cómo afectará el crecimiento futuro de la aplicación y por qué una mala organización inicial suele traducirse en errores de seguridad, confusión operativa, entornos mezclados y costos innecesarios.

En este capítulo se creará el proyecto oficial que acompañará todo el libro. La meta no es solo tener un proyecto activo, sino dejarlo correctamente preparado para crecer de forma ordenada durante el resto del manual.

Desarrollo completo¶

¿Qué es un proyecto de Firebase?¶

La documentación oficial define el proyecto de Firebase como la entidad de nivel superior de la plataforma. Dentro de un proyecto se registran las aplicaciones web, Android o Apple, y se aprovisionan los recursos y servicios que esas aplicaciones compartirán, como Hosting, Authentication, Cloud Firestore, Cloud Storage o Cloud Functions.[cite:2]

Una idea clave es que un proyecto Firebase funciona como un contenedor lógico de aplicaciones, configuración y servicios. Todas las apps registradas en el mismo proyecto comparten acceso a los mismos recursos backend y a la misma propiedad de Google Analytics, donde cada app actúa como un flujo de datos independiente.[cite:2]

Esto tiene una consecuencia práctica importante: elegir correctamente el proyecto significa elegir correctamente la frontera de compartición. Si dos aplicaciones comparten proyecto, comparten parte sustancial de su ecosistema técnico y operativo.

Relación entre Firebase Project y Google Cloud Project¶

La relación entre ambos no es opcional ni secundaria. La documentación oficial establece que cuando se crea un proyecto Firebase, en realidad se crea un proyecto de Google Cloud por detrás; incluso es posible crear primero el proyecto de Google Cloud y después añadir Firebase.[cite:2] El soporte oficial de Firebase resume esta idea de forma directa: los proyectos Firebase son proyectos de Google Cloud Platform que utilizan servicios de Firebase.[cite:3]

Esto significa que permisos, facturación, identificadores y jerarquía de recursos se comparten entre Firebase y Google Cloud.[cite:2][cite:3] También significa que un mismo proyecto puede administrarse desde Firebase Console, Google Cloud Console, Firebase CLI, gcloud y APIs compatibles con el ecosistema cloud de Google.[cite:2]

Desde una perspectiva profesional, esta relación obliga a pensar más allá de la consola de Firebase. Crear un proyecto no es abrir una carpeta aislada dentro de una herramienta amigable; es dar de alta una unidad cloud real sobre la cual vivirán recursos, permisos, cuotas y costos.

Cómo crear un nuevo proyecto¶

La creación de un proyecto puede realizarse desde Firebase Console y comienza con una decisión básica: nombre del proyecto, vinculación con Google Analytics y configuración inicial del entorno.[cite:2] Aunque la interfaz lo presenta como un asistente sencillo, cada paso tiene implicaciones concretas para administración futura, reportes, integraciones y crecimiento.

A nivel práctico, el proceso general es el siguiente:

Acceder a Firebase Console y seleccionar Create a project.[cite:2]
Definir el nombre visible del proyecto, que es interno y sirve para diferenciarlo en consola y herramientas administrativas.[cite:2]
Confirmar o ajustar el project ID, que debe ser único globalmente y que puede aparecer en URLs o nombres de recursos visibles, como subdominios de Hosting o buckets por defecto.[cite:2]
Elegir si se habilitará Google Analytics para el proyecto durante la creación.[cite:2]
Finalizar el aprovisionamiento y revisar la configuración general antes de registrar aplicaciones.

La lección importante aquí es que no conviene crear proyectos improvisados con nombres ambiguos ni con la expectativa de “arreglarlo después”. Algunos elementos pueden modificarse, pero otros impactan recursos públicos o hábitos operativos a largo plazo.[cite:2]

Configuración inicial¶

Tras crear el proyecto, la primera revisión profesional debe hacerse en la configuración general. Ahí se observan identificadores como project name, project ID y project number, todos compartidos con Google Cloud.[cite:2] La documentación explica que el project name es interno y editable, mientras que el project number es un identificador global asignado por Google y no puede modificarse.[cite:2]

El project ID merece especial atención. Firebase indica que este identificador puede aparecer en recursos visibles públicamente, como el subdominio por defecto de Hosting o el nombre del bucket por defecto de Cloud Storage.[cite:2] Por eso debe elegirse con criterio: claro, estable, profesional y sin información innecesaria que pueda volverse incómoda en el futuro.

Una buena práctica inicial consiste en revisar de inmediato:

Nombre visible del proyecto.
Project ID.
Vinculación con Analytics.
Miembros y permisos iniciales.
Plan de precios activo.
Estrategia de ambientes antes de registrar apps.

Selección de región¶

Aunque la creación del proyecto no siempre obliga a decidir todas las regiones desde el primer clic, la organización profesional sí exige definir una estrategia regional temprana. La razón es simple: varios servicios de Firebase y Google Cloud toman decisiones regionales que afectan latencia, cumplimiento, costos y cercanía a los usuarios una vez que se aprovisionan recursos.

La mejor práctica en esta etapa consiste en decidir la región pensando en tres factores: ubicación principal de usuarios, requisitos regulatorios y posible crecimiento del sistema. No se trata solo de “elegir lo más cercano”, sino de elegir lo que mejor equilibra experiencia de usuario, operación y gobernanza. Esa disciplina temprana evita uno de los problemas más comunes en equipos nuevos: activar recursos sin criterio territorial y descubrir después que moverlos no es trivial.

En el proyecto transversal del libro, se asumirá una estrategia orientada a un despliegue profesional para un producto hispanohablante con posibilidad de crecimiento regional. Esa decisión deberá mantenerse coherente en los capítulos posteriores cuando se activen los servicios concretos.

Configuración de Analytics¶

La documentación oficial indica que las apps registradas dentro del mismo proyecto se asocian a una misma propiedad de Google Analytics, donde cada app representa un flujo de datos independiente.[cite:2] Esto convierte a Analytics en una decisión de plataforma, no solo de medición aislada.

Activar Analytics durante la creación del proyecto suele ser recomendable cuando el producto tendrá recorrido real y se desea medir comportamiento desde etapas tempranas. Sin embargo, esta decisión debe tomarse entendiendo su propósito: no es “activar una casilla por costumbre”, sino preparar la capacidad de observación del producto desde el inicio.

Para el proyecto del libro, habilitar Analytics tiene sentido porque el manual construirá una aplicación que debe observarse, evolucionar y optimizarse. Si el lector estuviera creando un entorno de laboratorio efímero, la decisión podría ser distinta. Lo importante es que cada configuración tenga una justificación explícita.

Organización profesional de proyectos¶

La documentación oficial recomienda para aplicaciones de producción establecer un flujo de desarrollo claro, lo que normalmente implica múltiples entornos.[cite:2] Esta recomendación es crítica porque un solo proyecto para todo puede parecer cómodo al principio, pero termina mezclando pruebas, datos, configuraciones y despliegues que deberían estar separados.

Una organización profesional parte de una pregunta simple: ¿qué necesita aislarse para reducir riesgo? En casi todos los casos, la respuesta incluye al menos entornos, miembros con distintos permisos y convenciones claras para nombres y despliegues. Esa separación permite experimentar sin comprometer producción, validar cambios sin contaminar datos reales y gobernar el acceso del equipo con más precisión.

Convenciones para nombrar proyectos¶

El nombre visible del proyecto es interno y editable, pero aun así conviene manejarlo con un criterio uniforme.[cite:2] La mejor práctica consiste en usar un patrón que permita reconocer rápidamente producto, entorno y, si aplica, región o unidad de negocio.

Una convención profesional sencilla puede ser:

firebase-profesional-dev
firebase-profesional-test
firebase-profesional-prod

Esta convención funciona porque evita ambigüedades, facilita lectura en consola y hace evidente el propósito de cada proyecto. En equipos grandes, puede ampliarse con prefijos de organización o código del sistema, pero sin sacrificar claridad.

Convenciones para nombrar aplicaciones¶

Dentro de un mismo proyecto se pueden registrar varias aplicaciones: web, Android, Apple y otras variantes soportadas.[cite:2] Todas compartirán los recursos del proyecto, por lo que sus nombres también deben reflejar plataforma y rol de forma consistente.

Una convención útil para el proyecto del libro sería:

firebase-profesional-web
firebase-profesional-android
firebase-profesional-ios
firebase-profesional-admin-web

Esto ayuda a distinguir con rapidez qué aplicación se está registrando, qué flujo de datos tendrá en Analytics y qué configuración local corresponde a cada una.[cite:2] Un mal nombre de app no rompe la plataforma, pero sí introduce confusión operativa constante.

Ambientes de desarrollo¶

La documentación oficial recomienda revisar buenas prácticas de flujo de desarrollo para apps de producción, lo que normalmente implica múltiples ambientes.[cite:2] En términos prácticos, esto significa evitar que el desarrollo cotidiano, las pruebas de validación y la operación real compartan exactamente el mismo proyecto.

Separar ambientes no es un lujo corporativo. Es un mecanismo de reducción de riesgo. Permite probar integraciones, despliegues, reglas y configuraciones sin poner en peligro datos reales, recursos de producción o estabilidad del sistema.

Desarrollo (Development)¶

El ambiente de desarrollo es el espacio donde el equipo implementa, prueba ideas rápidamente y comete errores de forma segura. Debe priorizar velocidad de iteración, facilidad para reiniciar datos de prueba y flexibilidad para experimentar sin impacto real.

En este ambiente es razonable que los permisos del equipo sean más amplios, siempre con control. También es el lugar natural para trabajar junto con herramientas locales como Emulator Suite y para validar cambios antes de promoverlos a pruebas más formales.

Pruebas (Testing)¶

El ambiente de testing sirve para validar que lo construido funciona como se espera en condiciones cercanas a una entrega controlada. No debe ser una copia caótica del entorno de desarrollo ni una producción en miniatura mal mantenida; debe actuar como un filtro de calidad entre experimentación y operación real.

Aquí conviene validar configuraciones, despliegues, flujos de acceso y comportamiento de la aplicación con datos de prueba representativos. En equipos formales, también es el entorno adecuado para QA, demos internas o validaciones previas a liberaciones.

Producción (Production)¶

Producción es el entorno donde viven usuarios reales, datos reales y consecuencias reales. Por eso debe tener la mayor disciplina operativa: permisos más restringidos, cambios controlados, observabilidad activa y gobernanza clara.

Una de las peores decisiones que puede tomar un equipo novato es tratar producción como una extensión del ambiente de desarrollo. Cuando eso ocurre, los errores no se convierten en aprendizajes internos, sino en incidentes visibles, pérdida de confianza y potenciales costos económicos.

Cuándo utilizar múltiples proyectos¶

La respuesta corta es: casi siempre que exista más de un ambiente serio de trabajo. La documentación oficial recomienda una estrategia clara de desarrollo para apps de producción, y esa recomendación se traduce de manera natural en el uso de múltiples entornos o proyectos según el caso.[cite:2]

Usar múltiples proyectos conviene cuando se necesita separar:

Desarrollo, pruebas y producción.
Distintas unidades de negocio.
Aplicaciones con diferentes necesidades de seguridad o facturación.
Equipos con permisos claramente distintos.
Experimentos o laboratorios que no deben compartir recursos con el sistema principal.

No siempre se requiere una explosión de proyectos, pero tampoco es profesional operar todo dentro de uno solo por comodidad. La decisión correcta depende del nivel de aislamiento que la organización necesite.

Organización de equipos¶

Como los permisos se comparten entre Firebase y Google Cloud, la organización del equipo debe tratarse como una cuestión de gobernanza real y no como una simple lista de colaboradores.[cite:2] Cada miembro añadido al proyecto hereda implicaciones sobre recursos y administración en ambos entornos.

Una organización madura suele separar al menos tres perfiles: administradores de plataforma, desarrolladores que despliegan y colaboradores con acceso de observación o análisis. Este reparto no debe complicarse artificialmente, pero sí reflejar responsabilidades reales. El objetivo es minimizar privilegios sin bloquear el trabajo.

Gestión de miembros¶

La documentación oficial indica que los permisos y roles de IAM son compartidos entre Firebase y Google Cloud.[cite:2] Por ello, agregar un miembro al proyecto implica tomar una decisión de acceso a nivel plataforma, no solo a nivel de una pantalla concreta de la consola.

En la práctica, conviene adoptar tres reglas desde el día uno:

Agregar solo a quienes realmente necesiten acceso.
Revisar periódicamente miembros activos.
Evitar cuentas compartidas o accesos genéricos.

Estas reglas parecen obvias, pero su ausencia es una causa frecuente de desorden y riesgo innecesario en proyectos pequeños que crecen rápido.

Roles y permisos¶

Los roles deben asignarse con criterio de mínimo privilegio. La razón es doble: seguridad y orden operativo. Si demasiadas personas pueden cambiar configuraciones críticas, borrar recursos o alterar facturación, el proyecto se vuelve frágil aunque técnicamente funcione.

Como los permisos se comparten entre Firebase y Google Cloud, un error de asignación no afecta solo una consola, sino el proyecto completo.[cite:2] Por ello, una práctica profesional consiste en distinguir claramente quién administra la plataforma, quién desarrolla y despliega, y quién solo necesita observar métricas o revisar resultados.

Configuración del plan Spark¶

Firebase ofrece dos planes: Spark, sin costo inicial, y Blaze, bajo pago por uso.[cite:1] La documentación oficial explica que Spark permite usar plenamente los productos sin costo y acceder a cuotas gratuitas para ciertos productos de pago, sin necesidad de proporcionar información de pago para comenzar.[cite:1]

Esto lo convierte en un excelente punto de partida para aprendizaje, prototipos, laboratorios y primeras iteraciones. Sin embargo, la misma documentación advierte que si se supera la cuota gratuita de un producto en Spark, el uso de ese producto se detiene durante el resto del período correspondiente, en lugar de continuar con cobro incremental.[cite:1]

Desde una perspectiva profesional, Spark sirve para empezar rápido, pero no debe interpretarse como sinónimo de escalabilidad automática sin límites. Su función principal es facilitar el arranque controlado.

Cuándo migrar al plan Blaze¶

La documentación oficial señala que Blaze es el plan de pago por uso, habilitado cuando se vincula una cuenta de facturación de Google Cloud al proyecto.[cite:1] Este plan permite seguir usando cuotas gratuitas donde existan, pero cobra el consumo adicional y habilita acceso a servicios y características que no están disponibles en Spark, como Cloud Functions y productos de Google Cloud de pago.[cite:1]

Conviene migrar a Blaze cuando ocurre al menos una de estas situaciones:

El proyecto necesita Cloud Functions.[cite:1]
Se requiere usar servicios de Google Cloud como Cloud Run, Pub/Sub o capacidades de facturación e integración más amplias.[cite:1]
Las cuotas del plan Spark dejan de ser suficientes para pruebas serias o para producción.[cite:1]
Se desea evitar que un servicio se detenga al superar el límite del nivel gratuito.[cite:1]

La migración no debe verse como un fracaso del plan gratuito, sino como una transición natural hacia una operación más realista y controlada.

Diferencias entre Spark y Blaze¶

Aspecto	Spark	Blaze
Modelo económico	Sin costo inicial para empezar.[cite:1]	Pago por uso con cuenta de facturación vinculada.[cite:1]
Información de pago	No se requiere para comenzar.[cite:1]	Requiere vincular una cuenta de Cloud Billing.[cite:1]
Productos sin costo	Acceso completo a productos sin costo de Firebase.[cite:1]	También incluye acceso completo a productos sin costo.[cite:1]
Productos con cuota gratuita	Incluye cuotas gratuitas para ciertos productos de pago.[cite:1]	Incluye cuotas gratuitas y cobra el excedente por uso.[cite:1]
Cloud Functions	No disponible para nuevos despliegues de funciones de pago generalizado.[cite:1]	Disponible con cuota gratuita y luego pago por uso.[cite:1]
Servicios Google Cloud de pago	No disponibles.[cite:1]	Disponibles en el proyecto.[cite:1]
Comportamiento al exceder cuota	El producto afectado puede detenerse el resto del ciclo correspondiente.[cite:1]	El servicio continúa y se factura el uso adicional.[cite:1]

La diferencia central es operativa. Spark prioriza simplicidad de inicio; Blaze prioriza continuidad y expansión. Elegir bien depende del momento del proyecto y de la criticidad del sistema.

Organización recomendada para proyectos grandes¶

En equipos o empresas, la organización recomendada suele incluir múltiples proyectos según entorno, permisos más finos y una convención de nombres homogénea. La base documental lo respalda indirectamente al recordar que un proyecto Firebase comparte permisos, facturación, jerarquía organizativa y recursos con Google Cloud.[cite:2]

Una estructura razonable para una organización en crecimiento podría ser:

Un proyecto para desarrollo.
Un proyecto para testing o staging.
Un proyecto para producción.
Proyectos adicionales solo cuando existan productos claramente distintos, equipos separados o exigencias regulatorias específicas.

La clave no es multiplicar proyectos por moda, sino separar donde exista riesgo compartido indeseable. Un exceso de fragmentación complica la operación; una falta de separación compromete seguridad y gobernanza.

Configuración inicial recomendada antes de escribir una sola línea de código¶

Antes de programar, el proyecto debería quedar organizado al menos en estos frentes:

Nombre profesional del proyecto y estrategia de naming consistente.
Definición de ambientes.
Revisión de project ID y su impacto en recursos visibles.[cite:2]
Decisión sobre Analytics.[cite:2]
Revisión del plan Spark o Blaze según necesidades.[cite:1]
Alta inicial de miembros con permisos mínimos necesarios.[cite:2]
Definición de quién administra plataforma, quién desarrolla y quién observa.
Criterio regional documentado para servicios futuros.
Preparación del proyecto transversal que crecerá durante el libro.

Este checklist es importante porque evita un error muy común: empezar a escribir código y después intentar poner orden sobre un entorno ya contaminado por decisiones apresuradas.

Proyecto transversal del libro¶

El proyecto oficial del manual se organizará con una convención clara y pensada para crecer. Se propone el nombre visible Firebase Profesional, y como identificadores de entorno:

firebase-profesional-dev
firebase-profesional-test
firebase-profesional-prod

Se elige este nombre por tres razones. Primero, es descriptivo y fácil de reconocer dentro de consola y CLI. Segundo, mantiene una continuidad natural con el libro y con la aplicación profesional que se construirá progresivamente. Tercero, separa desde el inicio el concepto editorial del proyecto visible públicamente a través de IDs concretos y ambientes independientes.[cite:2]

Durante el resto del manual, todo lo que se construya se apoyará en esta base. Eso permitirá mostrar una evolución profesional real: no un conjunto de ejemplos aislados, sino un sistema que madura con estructura, control y trazabilidad.

Ejemplo práctico paso a paso¶

Escenario¶

Se creará el proyecto base que acompañará el libro y se dejará preparado para crecimiento profesional. El objetivo no es activar todavía todos los servicios, sino establecer una estructura sana desde el principio.

Paso 1: crear el proyecto base¶

Ingresar a Firebase Console y seleccionar la creación de un nuevo proyecto.[cite:2] Asignar como nombre visible Firebase Profesional Dev y revisar con cuidado el project ID sugerido, ajustándolo a firebase-profesional-dev si está disponible.[cite:2]

¿Por qué así? Porque el nombre visible ayuda a identificar el entorno en consola, y el project ID debe ser estable, legible y profesional, ya que puede aparecer en recursos visibles públicamente.[cite:2]

Paso 2: decidir Google Analytics¶

Durante el asistente, habilitar Google Analytics para el proyecto base del libro.[cite:2] Esta decisión se justifica porque el sistema crecerá como producto completo y será útil medir comportamiento, flujos y evolución desde etapas tempranas.

Paso 3: revisar configuración general¶

Una vez creado el proyecto, abrir Settings > General y revisar project name, project ID y project number.[cite:2] Confirmar que el entorno creado corresponde al de desarrollo y documentar estos datos en la guía del proyecto o en la documentación interna del equipo.

Paso 4: decidir el plan inicial¶

Mantener inicialmente el proyecto en Spark si el objetivo es aprendizaje controlado y primeras iteraciones.[cite:1] Documentar desde el día uno que el paso a Blaze será necesario cuando el libro avance a escenarios que requieran Cloud Functions o continuidad operativa más allá de las cuotas gratuitas.[cite:1]

Paso 5: preparar la estrategia multiambiente¶

Antes de registrar aplicaciones, definir que existirán tres proyectos independientes: dev, test y prod. Aunque al inicio se cree solo development, la convención completa debe quedar documentada desde el capítulo 3 para evitar improvisación posterior.

Paso 6: organizar miembros¶

Agregar únicamente a las personas que realmente participarán en esta etapa y asignar permisos mínimos. El responsable principal del libro o del equipo puede actuar como administrador de plataforma; otros perfiles deben entrar con privilegios más acotados según necesidad.

Paso 7: registrar la convención de aplicaciones futuras¶

Dejar definida la nomenclatura de las apps que se registrarán más adelante:

firebase-profesional-web
firebase-profesional-android
firebase-profesional-ios
firebase-profesional-admin-web

Esto prepara el crecimiento del sistema y evita nombres arbitrarios cuando el proyecto empiece a llenarse de recursos y variantes.

Buenas prácticas¶

Crear proyectos con intención arquitectónica, no como pruebas improvisadas.
Usar una convención de nombres clara para proyecto, entorno y aplicaciones.[cite:2]
Separar desarrollo, pruebas y producción cuando el proyecto tenga recorrido real.[cite:2]
Revisar el impacto del project ID antes de confirmarlo, porque puede aparecer en recursos públicos.[cite:2]
Activar Analytics cuando exista una justificación clara de producto y medición.[cite:2]
Tratar membresías y permisos como parte de la gobernanza del sistema, no como un trámite secundario.[cite:2]
Empezar en Spark cuando sea suficiente, pero documentar desde temprano los criterios de migración a Blaze.[cite:1]
Preparar la estructura antes de escribir código, no después.

Errores comunes¶

Crear un solo proyecto para todo y usarlo simultáneamente para desarrollo, pruebas y producción.
Elegir nombres ambiguos o poco profesionales para proyectos y aplicaciones.
No revisar el project ID y descubrir tarde que aparece en subdominios o recursos visibles.[cite:2]
Agregar miembros con permisos excesivos por comodidad.
Empezar a desarrollar sin definir ambientes ni plan operativo.
Pensar que Spark equivale a producción sin riesgos de interrupción, cuando la documentación indica que ciertos productos se detienen al superar cuotas en ese plan.[cite:1]
Migrar a Blaze sin gobernanza de consumo o, en el extremo opuesto, retrasar demasiado la migración cuando el proyecto ya necesita continuidad real.[cite:1]

Resumen¶

Un proyecto de Firebase es la unidad superior de organización de la plataforma y, al mismo tiempo, un proyecto de Google Cloud que comparte recursos, identificadores, permisos y facturación.[cite:2][cite:3] Por eso, crear un proyecto correctamente no es un detalle administrativo, sino una decisión arquitectónica que impacta seguridad, mantenimiento, escalabilidad y costos desde el primer día.

La forma profesional de empezar consiste en definir nombres claros, separar ambientes, asignar permisos mínimos, decidir conscientemente entre Spark y Blaze, y dejar documentada la estructura del sistema antes de programar. Esa disciplina inicial permitirá que el proyecto transversal del libro crezca con orden durante todos los capítulos posteriores.

Conceptos clave¶

Proyecto Firebase.[cite:2][cite:3]
Proyecto Google Cloud asociado.[cite:2][cite:3]
Project name.[cite:2]
Project ID.[cite:2]
Project number.[cite:2]
Google Analytics.[cite:2]
Ambientes development, testing y production.[cite:2]
Naming conventions.
Roles y permisos compartidos con IAM.[cite:2]
Plan Spark.[cite:1]
Plan Blaze.[cite:1]
Cloud Billing.[cite:1][cite:2]
Organización profesional de entornos.

Preguntas de repaso¶

¿Qué es un proyecto de Firebase y por qué se considera la entidad superior de la plataforma?[cite:2]
¿Qué relación existe entre un Firebase Project y un Google Cloud Project?[cite:2][cite:3]
¿Por qué el project ID debe elegirse con cuidado desde el inicio?[cite:2]
¿Qué diferencias operativas existen entre Spark y Blaze?[cite:1]
¿Cuándo conviene usar múltiples proyectos en lugar de uno solo?[cite:2]
¿Por qué la gestión de miembros y permisos debe tratarse como parte de la arquitectura?
¿Qué ventajas aporta separar development, testing y production?
¿Qué debería quedar configurado antes de escribir la primera línea de código?
¿Por qué el proyecto del libro se organiza desde este capítulo con una convención formal?
¿Qué riesgos aparecen cuando un equipo empieza a trabajar sin estrategia de entornos?

Ejercicios prácticos¶

Crea un borrador de estrategia de nombres para tres proyectos: development, testing y production.
Define un project ID profesional para una aplicación propia y justifica por qué sería adecuado en recursos visibles públicamente.[cite:2]
Diseña una propuesta de roles para un equipo pequeño de tres personas y otra para un equipo de diez personas.
Elabora una tabla donde señales cuándo permanecerías en Spark y cuándo pasarías a Blaze.[cite:1]
Dibuja la relación entre Firebase Console, Google Cloud Console, permisos IAM y facturación compartida.[cite:2]
Planifica la estructura inicial del proyecto transversal del libro con sus tres ambientes y sus futuras aplicaciones registradas.

Bibliografía y referencias oficiales¶

Documentación de planes de precios de Firebase: https://firebase.google.com/docs/projects/billing/firebase-pricing-plans [cite:1]
Documentación oficial para comprender proyectos Firebase: https://firebase.google.com/docs/projects/learn-more [cite:2]
Soporte oficial: ¿Qué es un proyecto de Firebase?: https://support.google.com/firebase/answer/6399760 [cite:3]