Firebase-tools: Implementación de funciones extremadamente lenta

¡Gracias por archivar! Sabemos que la implementación lenta es un problema importante para la experiencia de funciones, y es algo que estamos trabajando para resolver a través de varias estrategias.

@laurenzlong
Como novato en Firebase, a primera vista pensé que estaba estropeando algo, porque la implementación siempre se detenía en la parte _functions: preparando el directorio de funciones para cargar..._.
Sería muy bueno dar información adicional (como: se tarda de 3 a 5 minutos en completarse), hasta que se resuelva el problema.

Como novato, pasé muchas veces cancelando esto pensando que estaba haciendo algo mal.

El problema es algo obvio. El comando init creó una carpeta de 'módulos de nodo' que es enorme. En mi máquina es: 22,903 Archivos, 2,782 Carpetas. El código copia todo eso en una carpeta temporal.

Aquí esta lo que hice:

1. Usando declaraciones de impresión de registro, identifiqué la línea lenta de código. Es aquí:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

Línea 26 en prepareFunctionsUpload.js:
fs.copySync(options.config.path(options.config.get('functions.source')), tmpdir.name);

1. Imprimí los parámetros para esa llamada de copia de archivo. En mi maquina es:
   C:\Usuarios\thoma\StudioProjects\LSystemAndroid\firestorefunctions
   -> C:\Usuarios\thoma\AppData\Local\Temp\fbfn_752624vejX0cv3GEJI

La carpeta de funciones fue creada por el comando CLI init. Se parece a esto:

• node_modules (tamaño enorme)
• .gitignore
• índice.js
• paquete.json
• paquete-bloqueo.json

Me parece que el comando CLI init NO debería haber creado esa carpeta node_modules. Tiene 165 MB de tamaño. Eso parece irrazonable para agregar a cada proyecto.

@thomasfischersm

Ese no es el problema. Node_modules no se copia en la carpeta temporal, como puede ver en esta línea aquí: https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

Es necesario que firebase init instale todos los módulos de nodo localmente dentro de la carpeta de origen de las funciones; de lo contrario, el servicio local de las funciones no funcionará y la extracción de desencadenadores no funcionará (así es como la CLI entiende qué eventos desencadenan cada uno). para que pueda implementarlos correctamente).

Puse una línea de impresión de depuración antes de la línea 26 y después. Esa línea tomó minutos.

Luego, agregué un filtro para imprimir qué archivos se estaban copiando. Incluía todos los archivos node_modules.

Luego, cambié el filtro para excluir los archivos node_module. El despliegue progresó rápido ahora. Sin embargo, un poco más tarde, parecía que el script estaba tratando de evaluar la corrección de las funciones de la nube. Ese código falló porque le faltaban las dependencias de la biblioteca.

La línea de código fuente a la que apunta parece ser un paso posterior. Parece que los archivos (menos los node_modules) se archivan en un archivo zip antes de cargarlos en la nube. Esa línea no parece funcionar lentamente en mi máquina.

Sí, tienes razón, me equivoqué, node_modules se copia. Creo que es una idea válida no copiar node_modules en el directorio temporal. Lo que complica esto un poco es el hecho de que la CLI escribe un ".runtimeconfig.json" en la carpeta temporal antes de desencadenar el análisis, y este archivo se carga con el resto del código fuente de las funciones, y no queríamos escribir este archivo en el directorio del código fuente real. Entonces, probablemente haya una buena solución que mejore la velocidad de implementación y garantice que no haya efectos secundarios no deseados, pero tendría que jugar un poco. También puede sentirse libre de hacer una solicitud de extracción.

Estoy teniendo el mismo problema. Puede ser una buena idea imprimir más mensajes durante los pasos de "preparación del directorio..." para que el usuario no crea que firebase-tools se está bloqueando.

Editar: Esto fue en Ubuntu WSL. En Linux, la fase de "preparación" no se bloquea. El paso de "crear función" puede ser lento, pero no tanto como experimenté anteriormente.

Este problema es un verdadero dolor de cabeza. Creo que se le debe dar alta prioridad :/

Estoy tratando de implementar funciones de base de fuego en mi proyecto y debido a este error tuve que posponerlo.
Este error me hizo perder mucho tiempo.
espero que se solucione pronto!

Este problema es un gran obstáculo. Principalmente porque uso firestore y cosas como agregados, contadores y presencia solo pueden manejarse decentemente mediante funciones en la nube y solo se bloquea durante 5 minutos cada vez.

@PulpoEnPatineta Esto no es un error. Esto es simplemente un problema con el tiempo de implementación.

@McStuffins Si su automóvil tarda cinco minutos en encenderse, ¿es un error o simplemente un problema con la hora de inicio?

¿Hay una solución para esto? Es realmente extremadamente lento.

Mantuve un registro de este problema desde el principio, pero nunca ha sido un problema para mí ya que tengo un CD configurado y hace todo el trabajo por mí. Tampoco implemento funciones solo para probar si funcionan. Así que básicamente no me importaba.

Hasta hoy, cuando me encontré con una limitación inesperada: ya no puedo implementar mis funciones, porque la implementación en producción supera la cuota diaria (12,000 segundos). Tengo ~55 funciones con varios disparadores (pubsub, firestore, https). ¿Es demasiado para manejar?

Ahora tengo que implementar mi aplicación durante dos días :rofl: :lollipop: :+1: :1st_place_medal: :coffin: :tada: :taco: :cactus: :dancer: :smiling_imp:

A veces, cuando estoy implementando, es extremadamente lento y luego hay una advertencia en la terminal que dice "Error en el entorno de compilación"

@srinurp Consulte la solicitud de extracción a la que me vinculé anteriormente, solucionará una parte del problema. Y el equipo de back-end está trabajando para abordar otras partes del problema (pero es una tarea muy complicada, por lo que agradecemos su paciencia).

@merlinnot A menos que esté actualizando el código para todas sus funciones con cada implementación, recomendaría usar el comando --only para implementar funciones individuales o grupos de funciones. Consulte https://firebase.google.com/docs/cli/#partial_deploys.

@McStuffins "Error en el entorno de compilación" generalmente indica un problema de producción, en ese caso, presente un ticket de soporte en https://firebase.google.com/support/ , puede ver si hay algún problema de producción en curso visitando el Panel de estado de Firebase

@laurenzlong Tendría que configurar mi CI para detectar automáticamente cambios en cada función entre implementaciones (incluida la resolución de dependencias). ¿Y si actualizo paquetes como firebase-functions , firebase-admin , lodash , etc., que uso en cada función?

@merlinnot Ese es un caso de uso muy legítimo. Las cuotas de implementación están controladas por Google Cloud Functions, recomendaría presentar una solicitud en su rastreador de problemas públicos: https://cloud.google.com/functions/docs/support

Para todos los interesados: https://issuetracker.google.com/issues/71385193

@laurenzlong ¿Se podría ignorar la carpeta node_modules al copiar la fuente y luego hacer npm install --production o yarn install --production ? Como estas herramientas pueden ser más rápidas que simplemente copiar y pegar.

@horacehylee
Esto podría ser un cambio radical. Algunas personas pueden (incluido yo mismo) seguir haciendo referencia a los paquetes por una ruta relativa (como "nombre del paquete": "./externs/package.tgz"), principalmente debido al problema ( ahora solucionado ) con los repositorios privados. La herramienta tendría que tener en cuenta todos estos casos de esquina.

La otra cosa es el almacenamiento en caché: si Google descargara paquetes en su nombre, tendría que implementar algún mecanismo de almacenamiento en caché interno. Todos tenemos cachés locales en nuestras computadoras (tanto npm como yarn tienen mecanismos de almacenamiento en caché), por lo tanto, no eliminamos los servidores de npm;)

Algunas personas también pueden querer simplemente probar algunos cambios en bibliotecas externas. Es mucho más fácil simplemente cambiar un archivo e implementar la función que crear una bifurcación, hacer cambios, cambiar temporalmente una referencia al paquete, ...

En pocas palabras: funciona bien, déjalo como está ahora :+1:

@horacehylee @merlinnot Gracias por los 2 centavos. Consulte https://github.com/firebase/firebase-tools/pull/578 , la próxima versión de CLI ya no copiará el período de la carpeta de origen de funciones.

Realmente no estoy seguro de qué podría estar haciendo firebase que tarda MINUTOS en implementar una función de 5 líneas y 1 kb en una máquina de seis núcleos de 4 GHz, sentada en una conexión de fibra de 1 Gbps.

Sé que suena como si me estuviera tomando el pelo, pero tengo mucha curiosidad por saber qué está pasando durante la "preparación del directorio para cargar". ¿Alguien realmente sabe?

Copiando su directorio de funciones, incluidos los módulos de nodo, a un directorio tmp.

Nuestro próximo lanzamiento abordará esto y ya no es necesario copiar antes
desplegando

El domingo, 7 de enero de 2018, 5:05 p. m., hmexx [email protected] escribió:

Realmente no estoy seguro de qué podría estar haciendo firebase que lleva MINUTOS para
implementar una función de 5 líneas, 1 kb, en una máquina de seis núcleos de 4 GHz, sentado en un
Conexión de fibra de 1Gbps.

Sé que suena como si me estuviera tomando el pelo, pero tengo mucha curiosidad por saber qué
está ocurriendo durante la "preparación del directorio para la carga". ¿Alguien realmente sabe?

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

@mbleigh

Ah bien. Eso lo explica. Es un poco cómico ver una estación de trabajo volverse loca por un minuto o dos, solo para que la siguiente línea imprima "funciones empaquetadas ( 37.55kb !!!) exitosamente para cargar" lol

Esperamos el próximo lanzamiento. Gracias por responder.

h

Día 19. Firebase sigue desplegándose. *agarra palomitas de maiz*

Si.

¿Cuándo está programada la próxima versión y qué porcentaje de mejora en los tiempos de implementación deberíamos esperar?

Solo para saber si seguir por este camino.

El lanzamiento debería ocurrir esta semana, y puede esperar que el "Preparando
directorio de funciones para implementar" para ir sustancialmente más rápido (no
tienen números exactos). Otras partes del despliegue permanecerán sin cambios.

El lunes, 15 de enero de 2018 a las 12:42 p. m. hmexx [email protected] escribió:

Si.

¿Cuándo está prevista la próxima versión y qué porcentaje de mejora en la implementación?
tiempos debemos esperar?

Solo para saber si seguir por este camino.

—
Estás recibiendo esto porque te mencionaron.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-357784792 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAD_vaj-WngS9dMj7j5Q2AesM0tNMvVks5tK7hBgaJpZM4QdF3g
.

¡Esto fue lanzado!

@mbleigh ¿Está esto en la versión 3.17.4?

@jkossis v3.17.0

De las notas de la versión:

Si está implementando funciones, debe actualizar el SDK de funciones de firebase a la versión más reciente ejecutando "npm i --save firebase-functions@latest " dentro de su directorio de funciones. Esto permite un despliegue de funciones más rápido.

de minutos a segundos: ¡buen trabajo!

Para mí esto todavía toma minutos.

Tengo [email protected] y [email protected] . ¿Qué puedo hacer para ayudar a depurar aún más este problema?

Aquí está la salida cronometrada de implementar solo funciones. Cambié los nombres, pero son una combinación de puntos finales REST, bases de datos y activadores de autenticación.

➜  functions git:(master) ✗ firebase --version
3.17.4
➜  functions git:(master) ✗ time firebase deploy --only functions

=== Deploying to 'XXX'...

i  deploying functions
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (123.07 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: updating function 1...
i  functions: updating function 2...
i  functions: updating function 3...
i  functions: updating function 4...
i  functions: updating function 5...
i  functions: updating function 6...
✔  functions[1]: Successful update operation.
Function URL (1): https://us-central1-XXX.cloudfunctions.net/1
✔  functions[3]: Successful update operation.
✔  functions[4]: Successful update operation.
✔  functions[5]: Successful update operation.
✔  functions[6]: Successful update operation.
✔  functions[2]: Successful update operation.
Function URL (2): https://us-central1-XXX.cloudfunctions.net/2

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/XXX/overview
firebase deploy --only functions  4.59s user 1.07s system 1% cpu 6:09.26 total

@adamduren la solución fue por un tiempo excesivo gastado en preparing functions directory for uploading...

Los despliegues en sí mismos aún pueden llevar bastante tiempo.

pila en la misma situación:

"firebase-admin": "^5.8.2",
"firebase-functions": "^0.8.1",

npm install -g npm@latest me dio una entrada ligeramente diferente, y la eliminación firebase-cli también pareció cambiar algo.

actualizar:

bien, después de ejecutar npm install -g firebase-tools finalmente funcionó. Felicitaciones a https://stackoverflow.com/questions/48531993/firebase-config-variables-are-not-disponible-error-with-deploying-functions#comment84098334_48531993

Hola, tengo un problema en el mismo punto ("preparando el directorio de funciones...")
pero en mi caso tardó más de 25/30 minutos en completarse
tengo 4 dependencias privadas que pesan comprimidas alrededor de 2.20 mb
Descubrí que esa era la única forma de incluir dependencias privadas, como archivos comprimidos.
¿Estoy haciendo algo mal? ¿O es así como se supone que funciona?

2018-5-9
firebase deploy todavía lento, no estoy seguro de por qué

¿Has actualizado a la última versión? Actualicé la semana pasada y ahora mi implementación demora de 1 a 3 minutos (desde el 25/30)

Veo tiempos de implementación de más de 4 minutos para algo tan simple como:

const functions = require('firebase-functions')

exports.test = functions.https.onRequest((req, res) => {
  res.send('Hello World')
})

i functions: updating function test... es la línea que cuelga.
¡Nunca antes había sido tan lento!

@Robula ¿Has actualizado a la última versión de firebase-tools?

Sí, así lo creo. firebase —version informes 3.18.6.

usted está en una versión posterior a la mía. No estoy seguro si tal vez continuaron transfiriendo la carpeta node_modules nuevamente en 3.18.6, pero en este momento con 3.18.4, todo parece estar funcionando bien...

No ha habido una regresión en la estrategia de implementación en las versiones recientes de firebase-tools (la carpeta node_modules no se copia), sin embargo, el tiempo de implementación también varía de una máquina a otra y de vez en cuando. La implementación inicial de una función también es más lenta que las actualizaciones posteriores.

Veo que los tiempos de implementación durante el paso preparing functions directory for uploading... tardan casi 7 minutos solo en este paso cuando se ejecuta localmente. El paso previo a la implementación para la compilación demora alrededor de 5 segundos localmente. Todos los demás pasos en el proceso de implementación se ejecutan desde la depuración como muy rápidos. Entiendo que la implementación puede ser algo lenta, pero también uso AWS lambda para el trabajo y las implementaciones de lambda muy grandes son mucho más rápidas que esto, del orden de 2 dos 3 minutos, incluidas las instalaciones y compilaciones de paquetes de python.

Incluso la implementación desde la compilación en la nube de Google lleva de 2 a 3 minutos, en comparación con los 10 a 20 segundos en aws lambda. Solo quiero preguntar si el cli comprime toda la carpeta de funciones antes de cargarla.

@laurenzlong , ¿podría explicar si las funciones ya están implementadas en paralelo o si esta optimización está en proceso?

Las funciones siempre se han desplegado en paralelo. Sin embargo, tenga en cuenta que implementar 10 funciones en paralelo sigue siendo más lento que implementar una sola función.

+1 Que implementar una función es extremadamente lento. Seguí el tutorial del trabajo cron para crear la función de marca por hora, mi primer tono, y se tarda como un minuto en implementarlo cada vez.

@laurenzlong ¡ muchas gracias por responder y gracias por su arduo trabajo en Firebase!

¿Existen planes activos para mejorar el tiempo de implementación? Pregunto porque aunque nos gusta Firebase, en realidad estamos pensando en dejarlo debido a los lentos tiempos de implementación. Tenemos alrededor de 47 funciones en la nube y nuestras implementaciones generalmente demoran de 3 a 6 minutos. Compare eso con git push heroku master , que tardaría entre 20 y 30 segundos en implementar el mismo volumen de código en Heroku. Y ese código se ejecutaría instantáneamente en Heroku. Con Firebase, tenemos que esperar otros 20-30 segundos (aleatorios) después de la implementación antes de que las funciones implementadas se ejecuten realmente (durante este tiempo, se ejecuta una combinación de funciones nuevas y antiguas).

Así que compare la experiencia de implementación:

*** Heroku:

git push heroku master

20-30s later ...

All newly-deployed functions are now running in a consistent/atomic way

*** Firebase:

firebase deploy --only functions

180-360s later ...

Functions are deployed but only some of the new ones are running, some old ones are still running

20-30s later ... 

All new functions running

También es difícil hacer implementaciones atómicas con Firebase porque después de la implementación, hay un período de tiempo durante el cual algunas de las funciones nuevas, llámelas v_n+1 se ejecutan junto con algunas de las funciones antiguas v_n . Entonces, si realiza una actualización importante, tiene una combinación de funciones nuevas y antiguas que se ejecutan posiblemente utilizando diferentes formatos de datos o algoritmos. Esto es mucho menos seguro que una implementación de Heroku donde se implementan todas las funciones nuevas y solo se ejecutan funciones nuevas o no se implementa ninguna.

Además, a veces algunas de nuestras 47 funciones no se implementarán con errores como

⚠  functions[retrieveFavorites(us-central1)]: Deployment error.
Server Error. getaddrinfo ENOTFOUND cloudfunctions.googleapis.com cloudfunctions.googleapis.com:443

Estamos implementando en Internet Gigabit simétrico altamente confiable, por lo que el problema no es nuestra red.

Así que piense en las implementaciones de Heroku como una transacción de base de datos atómica (todo o nada), mientras que las implementaciones de Firebase son más bien consistentes con fallas parciales... Esto hace que las operaciones de desarrollo sean mucho más difíciles, especialmente si está impulsando una corrección de errores. la mitad de la noche en respuesta a una página.

Sea franco, la experiencia de implementación en Firebase es objetivamente más lenta y menos confiable que en Heroku o AWS... No me malinterpreten, nos gusta Firebase y realmente apreciamos todo su arduo trabajo. No quiero que esto suene como un ataque, no es nada personal, pero necesitamos que Firebase funcione mejor aquí o estamos pensando en ir a otro lado porque las implementaciones son demasiado dolorosas.

Gracias nuevamente por su arduo trabajo en Firebase. Apreciamos su ayuda :-).

¡Gracias por compartir tu punto de datos! Tenemos algunos planes para mejorar esto, especialmente para implementar muchas funciones al mismo tiempo (principalmente mejorar el paso de compilación del lado del servidor después de que se realiza la llamada a la API para crear/actualizar la función). Sin embargo, estos son cambios de infraestructura que tomarán trimestres, por lo que realmente apreciamos su paciencia mientras tanto.

Es posible que ya haya considerado esto, pero puede crear una secuencia de comandos en su canalización de CI/CD que detecte qué funciones se han editado y solo implemente aquellas con el indicador --only . Eso mejorará drásticamente su velocidad de implementación. Vea este video para ver un ejemplo: https://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong Gracias por la información, Lauren. Sin embargo, solo tengo una pequeña función en la nube y la implementación aún demora alrededor de 1 minuto, incluso después de realizar el cambio más pequeño. También uso esa bandera aunque solo tengo una función de nube. Parece que algo anda mal aquí.

Todavía tomo literalmente minutos a partir de abril de 2019 - Firebase versión 6.6.0 - todo lo que hago es seguir el tutorial aquí: https://firebase.google.com/docs/functions/get-started

Acabo de descargar y me toma unos minutos cada vez que "implemento Firebase"

Los últimos dos días, la implementación incluso del alojamiento lleva varios minutos, cuando hace un par de semanas tomó entre 10 y 15 segundos. La implementación de funciones también se agota.

Y la página de estado de Firebase es verde https://status.firebase.google.com/ .

¿Alguien sabe por qué pasa esto?

Usando firebase-tools 7.0.0

$ firebase deploy --only=hosting --token xxx

=== Deploying to 'xxx'...

i  deploying hosting
i  hosting[xxx]: beginning deploy...
i  hosting[xxx]: found 1959 files in public
✔  hosting[xxx]: file upload complete
i  hosting[xxx]: finalizing version...
✔  hosting[xxx]: version finalized
i  hosting[xxx]: releasing new version...
✔  hosting[xxx]: release complete
✔  hosting: Finished running postdeploy script.

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/xxx/overview
Hosting URL: https://xxx.firebaseapp.com
✨  Done in 181.75s

@laurenzlong-

Sin embargo, estos son cambios de infraestructura que tomarán trimestres, por lo que realmente apreciamos su paciencia mientras tanto.

¿Alguna actualización del lado de la infraestructura desde su última nota hace unos trimestres? Hasta que se hayan realizado estos cambios, ¿es posible volver a abrir este problema? Cerrado no parece ser el estado apropiado a menos que el seguimiento se haya movido a un problema diferente o relacionado.

Firebase functions sigue siendo muy lento después de que todo se ha creado/cargado y las funciones se están creando/actualizando en el lado del servidor. Como han dicho otros, este es un importante amortiguador de velocidad de desarrollo.

firebase --version
7.1.0

¡Muchas gracias por considerarlo!

@repentsinner, el proyecto de back-end para mejorar los tiempos de compilación/implementación aún está en curso (¡y va bien!) pero aún no se ha lanzado.

¿Ha intentado usar el emulador (a través firebase emulators:start ) para acelerar su proceso de desarrollo? Si es así, ¡nos encantaría recibir sus comentarios!

Gracias por la actualización @samtstern.

Todavía no probé el emulador: estoy usando functions.https.onCall de una aplicación flutter, así como datos en un almacén de incendios, y parece que (al menos en este momento) estoy redirigiendo todo en las compilaciones de prueba de la aplicación. a mi estación de trabajo de desarrollo es más esfuerzo que esperar implementaciones.

Supongo que puedo usar el tiempo que estoy esperando para investigar esto 🤨.

¡Feliz año nuevo a este problema que aún está cerrado y aún no se ha solucionado! 🎉

Tal vez un administrador u OP pueda cambiar el nombre de este problema a "Preparando el directorio de funciones para una implementación extremadamente lenta", ya que parece haberse cerrado basándose únicamente en una solución a esa etapa del proceso de implementación general.

Entonces podemos abrir un nuevo problema de "Implementación de funciones extremadamente lenta" ya que... la implementación de funciones sigue siendo extremadamente lenta 😄

Este problema se cerró porque no hay nada más que podamos hacer en el lado de la CLI para mejorar los tiempos de implementación. Para el desarrollo local, continuamos invirtiendo en el emulador, esperamos que las personas tengan que ejecutar firebase deploy solo cuando se implementen para producir y no como parte de su ciclo de vida de desarrollo.

Los cambios de backend todavía están en progreso. Como puede ver, ha habido retrasos inesperados.

Gracias por la aclaración @samtstern , así que supongo que los problemas/solicitudes contra firebase/firebase-tools solo se aplican a la CLI. Buscará un repositorio/proyecto que cubra el backend.

Con respecto al desarrollo local, desde el lado público de las cosas, parece que Google realmente está alentando la integración de Firebase y Flutter, que en la lata parece funcionar muy bien juntos, pero en la práctica nos encontramos con inconsistencias en el tiempo de desarrollo como esta. Eché un vistazo rápido al emulador como se sugirió cuando descubrí este problema, pero realmente no parecía admitir un flujo de trabajo de desarrollo integrado de Firebase más Flutter en absoluto, ciertamente no tan fluido como lo hace a través del backend en la nube. No he dado la vuelta para ver si esto ha mejorado últimamente, pero parece poco probable.

@repentsinner, sí, este repositorio solo rastrea el trabajo de CLI. Por supuesto, tratamos de responder a todo lo que surge, pero a menudo tenemos que cerrar problemas cuando no hay nada productivo que podamos hacer aquí. Nuestros backends no son de código abierto, por lo que generalmente dirigimos a las personas al soporte de Firebase para presentar informes de errores o solicitudes de características sobre cosas generales de Firebase.

En cuanto a Flutter, nos encanta (consulte: https://github.com/FirebaseExtended/flutterfire), pero es importante tener en cuenta que no es una plataforma oficial de Firebase, lo que significa que no podemos ofrecer nuestro soporte completo para problemas como lo hacemos en Android/iOS/Web nativo. Tal vez eso cambie algún día, pero por ahora esa es la situación.

Si tiene preguntas sobre cómo conectar su aplicación Flutter a los emuladores de Firebase, abra un problema en el repositorio de FlutterFire y envíeme un mensaje de correo electrónico, entonces también puedo involucrar a las personas adecuadas de Flutter.

Lo tengo, ¡gracias por la aclaración @samtstern! He pasado a otros proyectos por el momento, pero buscaré en el repositorio de FlutterFire cuando vuelva a este tema.

El emulador no es compatible con el contexto de autenticación, por lo que es 100% completamente inútil en mi opinión.

Terminé descubriendo que mis implementaciones se congelaron porque estaba tratando de usar dotenv

Solo asomo mi cabeza para recordarle a la gente que esto sigue siendo un punto doloroso ✌️

Para las personas que aún se encuentran con esto, una cosa que encontré útil fue utilizar functions.ignore para evitar cargar contenido innecesario. Creo que uno especialmente bueno para incluir es .git :
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

Dejé las funciones por completo ya que el flujo de trabajo del desarrollador es más que doloroso.

Para las personas que aún se encuentran con esto, una cosa que encontré útil fue utilizar functions.ignore para evitar cargar contenido innecesario. Creo que uno especialmente bueno para incluir es .git :

"functions": {
    "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"]
  }

Esto realmente arrojó algunos resultados. Corriendo en alrededor del 65-70% del tiempo ahora. ¡Gracias!

Interesante: de forma predeterminada, el subdirectorio functions está debajo de la raíz del proyecto, por lo que no tendrá una carpeta .git . Gente a la que esto ayudó: ¿cómo es la estructura de su directorio?

@mbleigh Cierto. Mi mejor suposición es que es inteligente al respecto y las aplica al directorio de funciones.

@mbleigh Tengo un repositorio solo de funciones, por lo que parecía un poco tonto tener un directorio de funciones. Todo se desplazó hasta la raíz.

Eso es un extracto de mi firebase.json :

  "functions": {
    "ignore": [
      "__mocks__",
      ".cache",
      ".commitlintrc.yaml",
      ".dependabot",
      ".editorconfig",
      ".eslintrc.yaml",
      ".firebase",
      ".firebaserc",
      ".git",
      ".gitattributes",
      ".github",
      ".gitignore",
      ".lintstagedrc.js",
      ".nvmrc",
      ".prettierignore",
      ".prettierrc.yaml",
      ".vscode",
      "CHANGELOG.md",
      "cloudbuild.yaml",
      "codecov.yml",
      "CONTRIBUTING.md",
      "coverage",
      "cSpell.json",
      "decisions",
      "firebase.json",
      "firestore.indexes.json",
      "jest.config.js",
      "node_modules",
      "README.md",
      "rfcs",
      "scripts",
      "src",
      "test",
      "tsconfig.json",
      "tsconfig.production.json"
    ],
    "source": "."
  },

Con mucho gusto lo reemplazaría con:
```
{
"incluir": ["lib", "paquete.json", "bloqueo-paquete.json"]
}

FWIW Creo que estos aceptan globos, por lo que es posible que puedas hacer:

{
  "exclude": ["!{lib,package.json,package-lock.json}"]
}

Recién comencé las funciones en la nube y el tiempo de implementación es doloroso.

tiempo de despliegue doloroso :(

Nuestra aplicación firebase tiene 60 funciones en la nube ejecutándose ahora. Al principio, comenzamos a tener muchos errores de implementación debido a las cuotas, por lo que luego lo dividimos en lotes, como sugieren los documentos. Ahora se implementa de manera constante, pero cada lote tarda aproximadamente 3 minutos en implementarse como parte del CI de acciones de GitHub en los ejecutores predeterminados. Los lotes son aproximadamente 6 cada uno, por lo que 10 lotes en total hacen que el tiempo de implementación de nuestra función sea de alrededor de 30 minutos.

Las funciones en sí mismas son fragmentos de código muy pequeños con dependencias mínimas. No estoy seguro de qué más podemos hacer para acelerar la canalización.

Eso es muy triste de escuchar. Otro enfoque es agrupar múltiples puntos de entrada/rutas en una sola función. Obviamente, esto no es lo mejor de la separación de preocupaciones/tamaño/seguridad, pero esto es lo que hicimos con todos nuestros puntos finales de API (punto de entrada único que luego usa un enrutador interno), y no hemos experimentado muchos límites de cuota desde entonces (pero suceden ocasionalmente).

Aún así, este límite de cuota parece muy bajo, ya que el documento oficial enumera "80 por 100 segundos" para "Llamadas para implementar o eliminar funciones a través de la API de Cloud Functions". Supongo que el soporte de Google no podría aumentar este límite aún más.

Aún así, este límite de cuota parece muy bajo, ya que el documento oficial enumera "80 por 100 segundos" para "Llamadas para implementar o eliminar funciones a través de la API de Cloud Functions". Supongo que el soporte de Google no podría aumentar este límite aún más.

@dinvlad Estaba preguntando tanto a ventas como a soporte sobre cómo aumentar ese límite de API, está explícitamente deshabilitado / atenuado en la sección de cuotas de la consola GCP. Eventualmente pude conseguir un ingeniero de Google en Hangouts que me informó "Esa cuota no cambia"... así que supongo que no.

Hemos agregado .git a la lista de ignorados estándar en la próxima versión:
https://github.com/firebase/firebase-tools/pull/2395

Eso debería acelerar los lanzamientos para algunos. Por supuesto, no hay mucho que nosotros (el equipo de CLI de Firebase) podamos hacer con respecto a la latencia en el backend de Cloud Functions.

asegúrese de hacer firebase deploy --only hosting cuando no esté actualizando funciones

Aquí también hemos estado agrupando la funcionalidad relacionada en una función, por lo que termina pareciendo "una función por área de características" en lugar de "una función por gránulo individual de funcionalidad".

¡Las características de rendimiento de la implementación están impulsando fuertemente la arquitectura de lo que se incluye en una función!

Cuándo y por qué se cerró este problema. Se inauguró en noviembre de 2017 y parece que sigue siendo un problema tan grande como lo era entonces. No puedo ver una referencia a 'Cerrado' aquí y me interesaría saber por qué se cerró.

No me quejo, solo me pregunto. Estoy seguro de que se está trabajando en ello, pero sería bueno saber sobre cualquier progreso.

@chriscurnow se cerró porque la causa real aparentemente se debe al lado del servidor (de código cerrado), no a las herramientas de CLI, aunque se manifiesta a los usuarios finales como un problema de CLI (según @samtstern en https://github.com /firebase/firebase-tools/issues/536#issuecomment-572830647).

Desafortunadamente, no hay un buen rastreador público para el back-end, así que recibimos actualizaciones aquí :(

¿Cómo podemos abrir este error para que Google lo arregle en su backend?
es ridículamente lento

Como, ¿cuál es el punto de usar las funciones de Firebase si va a llevar tanto tiempo?

Hola chicos, tal vez todos podamos informar este problema a Google y tal vez escuchen.
https://firebase.google.com/support/troubleshooter/contact

Cada vez que trato de usar algo de Google para algo importante, recuerdo que es una de las empresas menos amigables con el consumidor que existen, pero bueno, podríamos intentarlo.

@RenFontes Acabo de presentar el Caso 00075974: La implementación de las funciones de Firebase es tan lenta que no se puede utilizar con el soporte de Firebase. Actualizaré este mensaje con lo que sea que regresen.

Es posible implementar funciones específicas. ¿No podría la CLI tener un "rastreador de suma de verificación" para cada función y solo implementar las modificadas (y también rastrear todo lo que usa: vars, paquetes, ...)?

@SrBrahma seguro, pero el problema sigue presente incluso si solo implementa una sola función (por ejemplo, la implementación de una sola función aún puede fallar debido al tiempo de espera).

No debería ser responsabilidad del usuario administrar la implementación de la función de procesamiento por lotes y, en muchos casos, las actualizaciones de funciones se necesitan de manera atómica, por lo tanto, no se pueden dividir o procesar por lotes.

Agradezco las sugerencias para una solución alternativa, pero realmente lo que necesitamos aquí es un SLA de Google y su cumplimiento.

¿Es cierto que Firebase funciona a veces? (Quizás a menudo) apesta en el rendimiento... Es realmente lento... Debería admitir Rust en lugar... ¿Go? ¿Es mucho más rápido que Node?

¿Sigues esperando que Google mejore el tiempo de implementación de Google Functions, verdad?
Pasar de PWA a SSR me obligó a esperar 7 minutos más por cada implementación 😞