Firebase-tools: Implantação de funções extremamente lenta

Obrigado por arquivar! Sabemos que a implantação lenta é um grande problema para a experiência das funções e é algo que estamos trabalhando para resolver por meio de várias estratégias.

@laurenzlong
Como um novato no Firebase, à primeira vista, pensei que estava atrapalhando alguma coisa, porque o deploy sempre parava no diretório _functions: preparando funções para upload..._ part.
Dar algumas informações extras (como: leva de 3 a 5 minutos para ser concluído) seria muito bom, até que o problema seja resolvido.

Como novato, passei muitas vezes cancelando pensando que estava fazendo algo errado.

O problema é meio óbvio. O comando init criou uma pasta de 'módulos de nó' que é enorme. Na minha máquina são: 22.903 Arquivos, 2.782 Pastas. O código copia tudo isso para uma pasta temporária.

Aqui está o que eu fiz:

1. Usando instruções de impressão de log, identifiquei a linha de código lenta. Está aqui:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

Linha 26 em prepareFunctionsUpload.js:
fs.copySync(options.config.path(options.config.get('functions.source')), tmpdir.name);

1. Imprimi os parâmetros para essa chamada de cópia de arquivo. Na minha máquina é:
   C:\Users\thoma\StudioProjects\LSystemAndroid\firestorefunctions
   -> C:\Users\thoma\AppData\Local\Temp\fbfn_752624vejX0cv3GEJI

A pasta de funções foi criada pelo comando CLI init. Se parece com isso:

• node_modules (tamanho enorme)
• .gitignore
• index.js
• pacote.json
• pacakge-lock.json

Parece-me que o comando CLI init NÃO deveria ter criado essa pasta node_modules. É 165 MB grande. Isso parece irracional para adicionar a cada projeto.

@thomasfischersm

Isso não é realmente o problema. O node_modules não é copiado para a pasta temporária, como você pode ver nesta linha aqui: https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

É necessário que firebase init instale todos os módulos do nó localmente dentro da pasta de origem das funções, caso contrário, servir localmente as funções não funcionará e a extração de trigger não funcionará (é assim que a CLI entende quais eventos acionam cada função para que possa implantá-los corretamente).

Eu coloquei uma linha de impressão de depuração antes da linha 26 e depois. Essa linha levou minutos.

Em seguida, adicionei um filtro para imprimir quais arquivos estavam sendo copiados. Ele incluiu todos os arquivos node_modules.

Em seguida, alterei o filtro para excluir os arquivos node_module. A implantação progrediu rapidamente agora. No entanto, um pouco mais tarde, parecia que o script estava tentando avaliar a exatidão das funções da nuvem. Esse código falhou porque estava faltando as dependências da biblioteca.

A linha de código-fonte para a qual você aponta parece ser uma etapa posterior. Parece que os arquivos (menos os node_modules) são arquivados em um arquivo zip antes de serem carregados na nuvem. Essa linha não parece ficar lenta na minha máquina.

Sim, você está certo, eu estava enganado, node_modules é copiado. Eu acho que é uma ideia válida não copiar node_modules para o diretório temporário. O que complica um pouco isso é o fato de que a CLI grava um ".runtimeconfig.json" na pasta temp antes de acionar a análise, e esse arquivo é carregado com o restante do código-fonte das funções, e não queríamos escrever este arquivo no diretório de código-fonte real. Portanto, provavelmente há uma boa solução que melhora a velocidade de implantação e garante que não haja efeitos colaterais indesejados, mas eu teria que brincar um pouco. Você também pode se sentir à vontade para fazer um pull request.

Estou tendo o mesmo problema. Pode ser uma boa ideia imprimir mais mensagens durante as etapas de "preparando o diretório..." para que o usuário não pense que o firebase-tools está travando.

Edit: Isso foi no Ubuntu WSL. No Linux, a fase de "preparação" não trava. A etapa da "função de criação" pode ser lenta, mas não tanto quanto experimentei anteriormente.

Esta questão é uma verdadeira dor no bumbum. Acho que deveria ter prioridade :/

Estou tentando implementar funções do Firebase no meu projeto e por causa desse erro tive que adiar.
Esse erro me fez perder muito tempo.
espero que seja corrigido logo!

Essa questão é um grande obstáculo. Principalmente porque eu uso firestore e coisas como agregados, contadores e presença só podem ser tratadas decentemente por funções de nuvem e ele trava por 5 minutos todas as vezes.

@PulpoEnPatineta Isso não é um erro. Isso é simplesmente um problema com o tempo de implantação.

@McStuffins Se o seu carro demorar cinco minutos para ligar, é um erro ou simplesmente um problema com a hora de partida?

Existe uma correção para isso? É realmente extremamente lento.

Acompanhei esse problema desde o início, mas nunca foi um problema para mim, pois tenho um CD configurado e ele faz todo o trabalho para mim. Eu também nunca implemento funções apenas para testar se elas funcionam. Então, basicamente, não importava para mim.

Até hoje, quando me deparei com uma limitação inesperada: não consigo mais implantar minhas funções, pois a implantação para produção ultrapassa a cota diária (12.000 segundos). Eu tenho ~ 55 funções com vários gatilhos (pubsub, firestore, https). É demais para lidar?

Agora eu tenho que implantar meu aplicativo por dois dias :rofl: :lollipop: :+1: :1st_place_medal: :coffin: :tada: :taco: :cactus: :dancer: :smiling_imp:

Às vezes, quando estou implantando, é extremamente lento e, em seguida, há um aviso no terminal que diz "Erro no ambiente de compilação"

@srinurp Por favor, veja o pull request que eu vinculei acima, ele resolverá uma parte do problema. E a equipe de back-end está trabalhando para resolver outras partes do problema (mas é uma tarefa muito complicada, por isso agradecemos sua paciência).

@merlinnot A menos que você esteja atualizando o código para todas as suas funções com cada implantação, eu recomendaria usar o comando --only para implantar funções individuais ou grupos de funções. Consulte https://firebase.google.com/docs/cli/#partial_deploys.

@McStuffins "Erro no ambiente de compilação" geralmente indica um problema de produção; nesse caso, envie um tíquete de suporte em https://firebase.google.com/support/ , você pode ver se há algum problema de produção em andamento visitando o Painel de status do Firebase

@laurenzlong Eu teria que configurar meu CI para detectar automaticamente as alterações em cada função entre as implantações (incluindo a resolução de dependências). E se eu atualizar pacotes como firebase-functions , firebase-admin , lodash etc., que eu uso em todas as funções?

@merlinnot Esse é um caso de uso muito legítimo. As cotas de implantação são controladas pelo Google Cloud Functions. Recomendo enviar uma solicitação no rastreador de problemas públicos: https://cloud.google.com/functions/docs/support

Para todos os interessados: https://issuetracker.google.com/issues/71385193

@laurenzlong A pasta node_modules pode ser ignorada ao copiar a fonte e, em seguida, fazer um npm install --production ou yarn install --production ? Como essas ferramentas podem ser mais rápidas do que simplesmente copiar e colar.

@horacehylee
Esta pode ser uma mudança de ruptura. Algumas pessoas podem (inclusive eu) ainda referenciar pacotes por um caminho relativo (como "package-name": "./externs/package.tgz"), principalmente por causa do problema ( agora corrigido ) com repositórios privados. A ferramenta teria que levar em conta todos esses casos de canto.

A outra coisa é o cache: se o Google fosse baixar pacotes em seu nome, eles teriam que implementar algum mecanismo interno de cache. Todos nós temos caches locais em nossos computadores (tanto o npm quanto o yarn possuem mecanismos de cache), portanto não matamos os servidores do npm ;)

Algumas pessoas também podem querer simplesmente testar algumas mudanças em bibliotecas externas. É muito mais fácil apenas alterar um arquivo e implantar a função do que criar um fork, fazer alterações, alterar temporariamente uma referência ao pacote, ...

Resumindo: funciona bem, deixe como está agora :+1:

@horacehylee @merlinnot Obrigado pelos 2 centavos. Consulte https://github.com/firebase/firebase-tools/pull/578 , a próxima versão da CLI não copiará mais o período da pasta de origem das funções.

Eu realmente não tenho certeza do que o Firebase poderia estar fazendo que leva MINUTOS para implantar uma função de 5 linhas e 1 kb em uma máquina de seis núcleos de 4 GHz, em uma conexão de fibra de 1 Gbps.

Eu sei que parece que estou me irritando, mas estou genuinamente curioso sobre o que está acontecendo durante a "preparação do diretório para upload". Alguém realmente sabe?

Copiando seu diretório de funções, incluindo módulos de nó, para um diretório tmp.

Nossa próxima versão abordará isso e não será mais necessário copiar antes
implantando.

Em domingo, 7 de janeiro de 2018, 17h05, hmexx [email protected] escreveu:

Eu realmente não tenho certeza do que o Firebase poderia estar fazendo que leva MINUTOS para
implantar uma função de 5 linhas e 1kb em uma máquina de seis núcleos de 4 GHz,
Conexão de fibra de 1 Gbps.

Eu sei que parece que estou me irritando, mas estou genuinamente curioso para saber o que
está acontecendo durante a "preparação do diretório para upload". Alguém realmente sabe?

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

@mbleigh

Ah, certo. isso explica. É meio cômico ver uma estação de trabalho enlouquecer por um minuto ou dois, apenas para que a próxima linha imprima "funções empacotadas ( 37,55kb !!!) com sucesso para upload" lol

Aguarde o próximo lançamento. Thx por responder.

H.

Dia 19. Firebase ainda em implantação. *pega pipoca*

Sim.

Quando está previsto o próximo lançamento e qual % de melhoria nos tempos de implantação devemos esperar?

Só para saber se continuar indo por esse caminho.

O lançamento deve acontecer esta semana, e você pode esperar o "Preparando
diretório de funções para implantação" para ir substancialmente mais rápido (eu não
tem números exatos). Outras partes da implantação permanecerão inalteradas.

Em segunda-feira, 15 de janeiro de 2018 às 12h42 hmexx [email protected] escreveu:

Sim.

Quando está previsto o próximo lançamento e qual % de melhoria na implantação
vezes devemos esperar?

Só para saber se continuar indo por esse caminho.

—
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-357784792 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAAD_vaj-WngS9dMj7j5Q2AesM0tNMvVks5tK7hBgaJpZM4QdF3g
.

Este foi lançado!

@mbleigh Isso está na versão 3.17.4?

@jkossis v3.17.0

Das notas de lançamento:

Se você estiver implantando funções, deverá atualizar o SDK firebase-functions para o mais recente executando "npm i --save firebase -functions@latest " dentro do diretório de funções. Isso permite uma implantação de funções mais rápida.

de minutos para segundos: bom trabalho!

Para mim, isso ainda leva minutos.

Eu tenho [email protected] e [email protected] . O que posso fazer para ajudar a depurar ainda mais esse problema?

Aqui está a saída cronometrada da implantação apenas de funções. Eu mudei os nomes, mas eles são uma combinação de endpoints REST, banco de dados e gatilhos de autenticação.

➜  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 a correção foi por um tempo excessivo gasto em preparing functions directory for uploading...

As próprias implantações ainda podem demorar bastante.

pilha na mesma situação:

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

npm install -g npm@latest me deu uma entrada um pouco diferente, e remover firebase-cli pareceu mudar algo também.

atualizar:

ok, depois de executar npm install -g firebase-tools finalmente funcionou. Parabéns a https://stackoverflow.com/questions/48531993/firebase-config-variables-are-not-available-error-with-deploying-functions#comment84098334_48531993

Oi, estou tendo um problema no mesmo ponto ("preparando o diretório de funções..")
mas no meu caso levou mais de 25/30 minutos para completar
Tenho 4 dependências privadas que pesam compactadas em torno de 2,20 mb
Descobri que essa era a única maneira de incluir dependências privadas, como arquivos compactados.
Estou fazendo algo errado? ou é assim que deve funcionar?

09/05/2018
firebase deploy ainda lento, não sei por que

Você atualizou para a última versão? Atualizei na semana passada e agora minha implantação leva de 1 a 3 minutos (de 25/30)

Estou vendo tempos de implantação de mais de 4 minutos para algo tão simples quanto:

const functions = require('firebase-functions')

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

i functions: updating function test... é a linha que trava.
Nunca foi tão lento!

@Robula Você atualizou para a versão mais recente do firebase-tools?

Sim eu acredito que sim. firebase —version relatórios 3.18.6.

você está em uma versão mais recente do que eu. Não tenho certeza se eles continuaram transferindo a pasta node_modules novamente em 3.18.6, mas no momento com 3.18.4, tudo parece estar funcionando bem ...

Não houve uma regressão na estratégia de implantação nas versões recentes do firebase-tools (a pasta node_modules não é copiada), no entanto, o tempo de implantação também varia de máquina para máquina e de tempos em tempos. A implantação inicial de uma função também é mais lenta do que as atualizações subsequentes.

Estou vendo que os tempos de implantação durante a etapa preparing functions directory for uploading... levam quase 7 minutos apenas nesta etapa ao executar localmente. A etapa de pré-implantação para compilação leva cerca de 5 segundos localmente. Todas as outras etapas no processo de implantação são executadas a partir da depuração muito rapidamente. Entendo que a implantação pode ser um pouco lenta, mas também uso o AWS lambda para trabalho e implantações lambda muito grandes são muito mais rápidas do que isso, na ordem de 2 a 3 minutos, incluindo instalações e compilações de pacotes python.

Mesmo a implantação do google cloud build leva de 2 a 3 minutos, contra 10 a 20 segundos no aws lambda. Eu só quero perguntar se o cli compacta toda a pasta de funções antes de fazer o upload?

@laurenzlong , você poderia detalhar se as funções já estão implantadas em paralelo ou se essa otimização está em andamento?

As funções sempre foram implantadas em paralelo. No entanto, observe que implantar 10 funções em paralelo ainda é mais lento do que implantar uma única função.

+1 Que implantar uma função é extremamente lento. Eu segui o tutorial do cron job para criar a função de marcação horária, meu primeiro tom, e leva um minuto para implantar todas as vezes.

@laurenzlong muito obrigado por responder e obrigado por seu trabalho duro no Firebase!

Existem planos ativos para melhorar o tempo de implantação? Pergunto porque, embora gostemos do Firebase, na verdade estamos pensando em nos afastar dele devido aos tempos de implantação lentos. Temos cerca de 47 funções de nuvem e leva regularmente de 3 a 6 minutos para nossas implantações. Compare isso com git push heroku master , que levaria cerca de 20 a 30 segundos para implantar o mesmo volume de código no Heroku. E esse código seria executado instantaneamente no Heroku. Com o Firebase, temos que esperar mais 20 a 30 segundos (aleatórios) após a implantação antes que as funções implantadas estejam realmente em execução (durante esse tempo, uma combinação de funções novas e antigas é executada).

Então compare a experiência de implantação:

*** 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

Também é difícil fazer implantações atômicas com o Firebase porque, após a implantação, há um período de tempo durante o qual algumas das novas funções, chamadas de v_n+1 estão sendo executadas junto com algumas das funções antigas v_n . Portanto, se você fizer uma atualização importante, terá uma mistura de funções novas e antigas em execução, possivelmente usando diferentes formatos de dados ou algoritmos. Isso é muito menos seguro do que uma implantação do Heroku, onde todas as novas funções são implantadas e apenas as novas funções estão em execução ou nenhuma implantação.

Além disso, às vezes algumas de nossas 47 funções falham ao serem implantadas com erros como

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

Estamos implantando em uma internet Gigabit simétrica altamente confiável, então o problema não é nossa rede.

Portanto, pense em implantações do Heroku como uma transação de banco de dados atômica (tudo ou nada), enquanto as implantações do Firebase são mais consistentes com falhas parciais ... no meio da noite em resposta a uma página.

Para ser franco, a experiência de implantação no Firebase é objetivamente mais lenta e menos confiável do que no Heroku ou AWS ... Não me entenda mal, gostamos do Firebase e realmente apreciamos todo o seu trabalho duro. Não quero que isso soe como um ataque, não é nada pessoal, mas precisamos que o Firebase faça melhor aqui ou estamos pensando em ir para outro lugar porque as implantações são muito dolorosas.

Obrigado novamente por seu trabalho árduo no Firebase. Agradecemos sua ajuda :-).

Obrigado por compartilhar seu ponto de dados! Temos alguns planos para melhorar isso especialmente para implantar muitas funções ao mesmo tempo (principalmente melhorando a etapa de compilação do lado do servidor após a chamada da API ser feita para criar/atualizar a função). No entanto, essas são mudanças de infraestrutura que levarão trimestres, por isso agradecemos sua paciência enquanto isso.

Você já deve ter considerado isso, mas pode criar um script em seu pipeline de CI/CD que detecte quais funções foram editadas e implemente apenas aquelas com o sinalizador --only . Isso melhorará drasticamente sua velocidade de implantação. Veja este vídeo para um exemplo: https://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong Obrigado pela informação, Lauren. No entanto, tenho apenas uma pequena função de nuvem e ainda leva cerca de 1 minuto para implantar, mesmo depois de fazer a menor alteração. Eu também uso esse sinalizador mesmo tendo apenas uma função de nuvem. Parece que tem algo errado acontecendo aqui.

Ainda levando literalmente alguns minutos em abril de 2019 - Firebase versão 6.6.0 - tudo o que estou fazendo é seguir o tutorial aqui: https://firebase.google.com/docs/functions/get-started

Acabei de fazer o download e demorando alguns minutos cada vez que "firebase deploy"

Nos últimos dias, a implantação de até mesmo a hospedagem leva vários minutos, quando levou de 10 a 15 segundos algumas semanas atrás. A implantação de funções também expira.

E a página de status do Firebase fica verde https://status.firebase.google.com/ .

Alguém sabe porque isso acontece?

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-

No entanto, essas são mudanças de infraestrutura que levarão trimestres, por isso agradecemos sua paciência enquanto isso.

Alguma atualização do lado da infraestrutura desde sua última nota há alguns trimestres? Até que essas alterações sejam feitas, é possível reabrir esse problema? Fechado não parece ser o estado apropriado, a menos que o rastreamento tenha sido movido para um problema diferente/relacionado.

O Firebase functions ainda está super lento depois que tudo foi compilado/carregado e as funções estão sendo criadas/atualizadas no lado do servidor. Como outros já disseram, este é um grande amortecedor de velocidade de desenvolvimento.

firebase --version
7.1.0

Muito obrigado por considerar!

@repentsinner o projeto de back-end para melhorar os tempos de compilação/implantação ainda está em andamento (e indo bem!), mas ainda não foi lançado.

Você já tentou usar o emulador (através de firebase emulators:start ) para acelerar seu processo de desenvolvimento? Se sim, adoraríamos receber seu feedback!

Obrigado pela atualização @samtstern.

Ainda não testei o emulador - estou usando functions.https.onCall de um aplicativo flutter, bem como dados em um firestore, e parece (no momento de qualquer maneira) redirecionando tudo nas compilações de teste do aplicativo para minha estação de trabalho de desenvolvimento é mais trabalhoso do que esperar por deploys.

Acho que posso usar o tempo que estou esperando para investigar isso 🤨.

Feliz Ano Novo para este problema que ainda está Fechado e ainda não corrigido! 🎉

Talvez um administrador ou OP possa renomear esse problema para "Preparando o diretório de funções para implantação extremamente lenta", pois parece ter sido fechado com base apenas em uma correção para esse estágio do processo geral de implantação.

Podemos, então, abrir um novo problema "Implantando funções extremamente lentas", pois ... a implantação de funções ainda é extremamente lenta 😄

Esse problema foi encerrado porque não há mais nada que possamos fazer no lado da CLI para melhorar os tempos de implantação. Para o desenvolvimento local, continuamos a investir no emulador, esperamos que as pessoas tenham que executar firebase deploy apenas quando estiverem implantando para produção e não como parte de seu ciclo de vida de desenvolvimento.

As alterações de back-end ainda estão em andamento. Como você pode ver, houve atrasos inesperados.

Obrigado pelo esclarecimento @samtstern , então acho que problemas/solicitações contra firebase/firebase-tools são aplicáveis ​​apenas à CLI? Procurará um repositório/projeto que cubra o back-end.

Em relação ao desenvolvimento local - do lado público das coisas, parece que o Google está realmente incentivando a integração do Firebase e do Flutter, que na lata parece funcionar muito bem juntos, mas na prática nos deparamos com inconsistências de tempo de desenvolvimento como essa. Dei uma olhada rápida no emulador, conforme sugerido ao descobrir esse problema, mas ele realmente não parecia oferecer suporte a um fluxo de trabalho de desenvolvimento integrado do Firebase e do Flutter, certamente não tão suavemente quanto no back-end da nuvem. Eu não circulei de volta para ver se isso melhorou ultimamente, mas parece improvável.

@repentsinner sim, este repositório rastreia apenas o trabalho da CLI. É claro que tentamos responder a qualquer coisa que surja, mas muitas vezes temos que encerrar as questões quando não há nada produtivo que possamos fazer aqui. Nossos back-ends não são de código aberto, e é por isso que geralmente direcionamos as pessoas para o suporte do Firebase para enviar relatórios de bugs ou solicitações de recursos sobre coisas gerais do Firebase.

Quanto ao Flutter, adoramos (veja: https://github.com/FirebaseExtended/flutterfire), mas é importante observar que não é uma plataforma oficial do Firebase, o que significa que não podemos oferecer suporte completo para problemas como fazemos no Android/iOS/Web nativo. Talvez isso mude um dia, mas por enquanto essa é a situação.

Se você tiver dúvidas sobre como conectar seu aplicativo Flutter aos emuladores do Firebase, abra um problema no repositório FlutterFire e me envie uma cópia, para que eu possa envolver as pessoas certas do Flutter também.

Entendi, obrigado pelo esclarecimento @samtstern! Eu mudei para outros projetos no momento, mas vou olhar no repositório do FlutterFire quando eu voltar para essas coisas.

O emulador não suporta contexto de autenticação, portanto, é 100% IMO completamente inútil.

Acabei descobrindo que minhas implantações congelaram porque eu estava tentando usar dotenv

Apenas colocando minha cabeça para lembrar as pessoas que isso ainda é um ponto de dor ✌️

Para as pessoas que ainda se deparam com isso - uma coisa que achei útil foi utilizar functions.ignore para evitar o upload de inchaço desnecessário. Eu acho que um especialmente bom para incluir é .git :
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

Eu larguei as funções completamente, pois o fluxo de trabalho do desenvolvedor é muito doloroso.

Para as pessoas que ainda se deparam com isso - uma coisa que achei útil foi utilizar functions.ignore para evitar o upload de inchaço desnecessário. Eu acho que um especialmente bom para incluir é .git :

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

Isso realmente rendeu alguns resultados. Correndo em cerca de 65-70% do tempo agora. Obrigado!

Interessante - por padrão, o subdiretório functions está abaixo da raiz do projeto, portanto, não terá uma pasta .git . Pessoas para quem isso ajudou - como é a sua estrutura de diretórios?

@mbleigh Verdade. Meu melhor palpite é que é inteligente sobre isso e os aplica ao diretório de funções.

@mbleigh Eu tenho um repositório somente de funções, então parecia um pouco bobo ter um diretório de funções. Tudo se deslocou para a raiz.

Isso é um extrato do meu 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": "."
  },

Eu substituiria com prazer por:
```
{
"include": ["lib", "package.json", "package-lock.json"]
}

FWIW Eu acredito que eles aceitam globs para que você possa fazer:

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

Acabei de iniciar as funções de nuvem e o tempo de implantação é doloroso.

tempo de implantação doloroso :(

Nosso aplicativo Firebase tem 60 funções de nuvem em execução agora. No início, começamos a ter muitas falhas de implantação devido a cotas, então dividimos em lotes, como sugerem os documentos. Ele é implantado de forma consistente agora, mas cada lote leva cerca de 3 minutos para ser implantado como parte do CI de ações do GitHub nos executores padrão. Os lotes são cerca de 6 cada, portanto, 10 lotes no total, tornando nosso tempo de implantação da função em torno de 30 minutos.

As funções em si são pedaços muito pequenos de código com dependências mínimas. Não tenho certeza do que mais podemos fazer para acelerar o pipeline.

Isso é realmente triste de ouvir. Outra abordagem é agrupar vários pontos de entrada/rotas em uma única função. Obviamente, isso não é o melhor da separação de preocupações/tamanho/segurança, mas foi o que fizemos com todos os nossos endpoints de API (ponto de entrada único que usa um roteador interno) e não experimentamos muitos limites de cota desde (mas eles acontecem ocasionalmente).

Ainda assim, esse limite de cota parece muito baixo, pois o documento oficial lista "80 por 100 segundos" para "Chamadas para implantar ou excluir funções por meio da API do Cloud Functions". Estou assumindo que o suporte do Google não poderia aumentar ainda mais esse limite?

Ainda assim, esse limite de cota parece muito baixo, pois o documento oficial lista "80 por 100 segundos" para "Chamadas para implantar ou excluir funções por meio da API do Cloud Functions". Estou assumindo que o suporte do Google não poderia aumentar ainda mais esse limite?

@dinvlad Eu estava perguntando às vendas e ao suporte sobre como aumentar esse limite de API, ele está explicitamente desativado / acinzentado na seção de cotas do console do GCP. Eventualmente, consegui um engenheiro do Google nos hangouts que me informou "Essa cota não muda".... então acho que não.

Adicionamos .git à lista de ignorados padrão na próxima versão:
https://github.com/firebase/firebase-tools/pull/2395

Isso deve acelerar os lançamentos para alguns. É claro que não há muito que nós (a equipe da Firebase CLI) possamos fazer sobre a latência no back-end do Cloud Functions.

certifique-se de fazer firebase deploy --only hosting quando você não estiver atualizando funções

Por aqui também estamos agrupando funcionalidades relacionadas em uma função, então acaba parecendo "uma função por área de recurso" em vez de "uma função por grânulo individual de funcionalidade".

As características de desempenho da implantação estão impulsionando fortemente a arquitetura do que entra em uma função!

Quando e por que esse problema foi encerrado. Foi inaugurado em novembro de 2017 e parece que ainda é um problema tanto quanto era então. Não consigo ver uma referência a 'Fechado' aqui e gostaria de saber por que foi fechado.

Não estou reclamando, apenas imaginando. Tenho certeza que está sendo trabalhado, mas seria bom saber sobre qualquer progresso.

@chriscurnow foi fechado porque a causa real é aparentemente devido ao lado do servidor (código fechado) e não às ferramentas CLI, mesmo que se manifeste para os usuários finais como um problema CLI (por @samtstern em https://github.com /firebase/firebase-tools/issues/536#issuecomment-572830647).

Infelizmente, não há um bom rastreador público para o back-end, então recebemos atualizações aqui :(

Como podemos abrir esse bug para o google corrigi-lo em seu back-end?
é ridiculamente lento

Tipo, qual é o sentido de usar funções do Firebase se vai demorar tanto

Ei pessoal, talvez todos nós possamos relatar esse problema para o google e talvez eles ouçam?
https://firebase.google.com/support/troubleshooter/contact

Toda vez que tento usar algo do google para algo importante, lembro que eles são uma das empresas menos amigáveis ​​ao consumidor que existem, mas, ei, poderíamos tentar.

@RenFontes Acabei de registrar o caso 00075974: a implantação de funções do Firebase é tão lenta que é inutilizável com o suporte do Firebase. Vou atualizar esta mensagem com o que eles voltarem.

É possível implantar funções específicas. A CLI não poderia ter um "rastreador de soma de verificação" para cada função e apenas implantar as alteradas (e também rastrear tudo o que ela usa: vars, packages, ...)?

@SrBrahma com certeza, mas o problema ainda está presente mesmo se você implantar apenas uma única função (por exemplo, a implantação de função única ainda pode falhar devido ao tempo limite).

Não deve ter que recair sobre o usuário para gerenciar a implantação da função de lote e, em muitos casos, as atualizações de função são necessárias atomicamente, portanto, não podem ser divididas/em lote.

Aprecie as sugestões para uma solução alternativa, mas realmente o que precisamos aqui é um SLA do Google e sua adesão a ele.

É verdade que o Firebase Functions às vezes? (talvez muitas vezes) é péssimo no desempenho.. É muito lento.. Você deveria dar suporte ao Rust. é muito mais rápido que o Node?

Ainda esperando o Google melhorar o tempo de implantação do Google Functions, certo?
Passar de PWA para SSR me obrigou a esperar mais 7 min para cada deploy 😞