Firebase-tools: Use hospedagem com prerender.io

Oi,

Atualmente, as regras de reescrita / redirecionamento do Firebase Hosting não são detalhadas o suficiente para serviços de pré-renderização, mas alguns de nossos clientes tiveram sucesso criando uma etapa de pré-renderização em seu processo de compilação para sites razoavelmente estáticos usando html5 pushState. Eles pré-renderizam todas as páginas com base no aplicativo de página única para que o conteúdo correto seja servido a um rastreador, então, se o usuário navegar para outra página, o aplicativo da web assume e processa novamente sem uma atualização de página

Isso é obviamente muito complicado e obviamente não é o ideal, mas estamos trabalhando para tornar isso muito menos problemático

espero que ajude

Chris

Sei que só se passaram dois meses, mas há uma atualização sobre isso? Como vocês são propriedade do Google agora, suponho que eles querem que os sites hospedados com o firebase sejam indexados por seu serviço de pesquisa.

Não temos nenhuma atualização específica sobre isso no momento, apenas que o SEO é obviamente importante para nós e mantém o Firebase Hosting relevante para os desenvolvedores. Espero ter uma atualização para você em breve

Oi pessoal! Eu só queria saber qual é o status desta atualização? está chegando em breve? Eu uso o Firebase hosting e é ótimo, a única coisa que me preocupa é o SEO, meu site não aparece em nenhum lugar do google, também procurei por integrações de SEO com o firebase e não encontrei nenhuma solução. Eu realmente gosto de manter tudo em um só lugar, então seria uma pena mudar para um serviço diferente que possa servir minhas páginas para o mecanismo de rastreamento do Google. Isso seria uma grande melhoria, pois agora eu sei que o Firebase é propriedade do Google. Obrigado!

Ainda estou interessado neste serviço. Obrigado!

Adicionando minha voz ao tópico - seria ótimo ter esse recurso!

+1

Estou esperando por isso também.

Como alternativa, estou tentando usar https://divshot.com + firebase.

+1

Devido ao anúncio recente da fusão do DIvshot e do Firebase, esse problema surge novamente. Na verdade, mudei para o Divshot para usar os recursos gratuitos de Domínio personalizado e prerender.io. Como a fireabse vai lidar com essas questões? Você vai adicionar domínios personalizados ao nível gratuito? E o prerender.io?

Estamos investigando maneiras de trazer a pré-renderização de JS para o Firebase Hosting, mas não temos planos firmes de compartilhar no momento. (Nota pessoal: Eu realmente quero ver isso acontecer).

Como o Firebase tem a opinião de que todos os sites devem ser somente HTTPS, gerenciamos o provisionamento de certificados SSL em nome de nossos usuários. O custo envolvido em fazer isso nos impede de oferecer hospedagem gratuita de domínio personalizado.

Obrigado por uma resposta rápida (trocadilho intencional).

Algum tipo de capacidade de SEO é mais do que necessário para plataformas de hospedagem estática de aplicativos da web, então espero que vocês consigam fazer isso funcionar até meados de dezembro, caso contrário, muitos desenvolvedores precisarão mudar para provedores de hospedagem tradicionais (infelizmente incluindo eu )

A segunda resposta faz todo o sentido e considero apenas saltar para o nível pago, é uma pena que não esteja fornecendo o mesmo escalonamento adicional para você.

100% dos sites de hospedagem do Firebase estão no CDN extremamente rápido (trocadilho regurgitado) de Fastly. Você obtém todas as vantagens do plano de alto desempenho do Divshot, mesmo no plano gratuito (mas não em um domínio personalizado). Quanto à largura de banda, 10GB acaba sendo um _muito_ de banda para um site estático.

Eu preciso admitir que não pensei sobre as vantagens de alto desempenho de Divshot. De qualquer forma, é uma pena que precise migrar meu aplicativo e preparar um back-end (e atrasar novos recursos!), Enquanto o grau de CS consome quase todo o meu tempo. Embora meu projeto não seja tão avançado, outros podem sofrer enormes atrasos, então, novamente, eu realmente espero que o Firebase nos ajude a nos tornarmos amigáveis ​​ao SEO ou talvez o Divshot atrase o seu fechamento. Eu entendo que provavelmente não é uma opção, mas se alguns de nós migrarem, eles podem nunca mais voltar.

Parabéns @mbleigh pela aquisição!

@DamodarSojka , concordo totalmente com você. Sou um usuário pago existente do Divshot. A pré-renderização é uma obrigação para o marketing / compartilhamento do meu site no Facebook. Se o Firebase não oferecer esse recurso em breve, terei que migrar para outros serviços de hospedagem na web.

+1 para capacidade de SEO

Também estamos pagando ao cliente Divshot e o suporte Prerender é necessário para nós. O suporte para Prerender no Divshot não é ideal (devido ao URL production.blabla.divshot.io após o compartilhamento), mas se não houver suporte para Prerender no Firebase, não poderemos usá-lo. Obrigado.

Da mesma forma, o SEO é de extrema importância, esteja você usando o prerender.io ou outra solução semelhante. Isso precisa ser corrigido no Firebase antes que o divshot seja encerrado.

Sim, ainda está tendo problemas com seo

+1 - Cliente pago da Divshot, precisaria do suporte do Prerender para migrar para o Firebase.

Completley concorda. O Firebase não é um substituto do Divshot se não tiver recursos de pré-processamento. Sou um usuário pago do Divshot. Com dois meses de antecedência do fechamento de Divshot. Devo trabalhar na migração para outro serviço? Tenho que gastar meu tempo configurando um servidor? Ou manter o foco no que eu estava fazendo? Não é essa a ideia do serviço? Não tendo que lidar com problemas de servidor? Explique se o Firebase será uma opção para 14 de dezembro ou se devo demorar um pouco para configurar um servidor.

Senhores, Mike já declarou, na íntegra, o status desse recurso: Estamos investigando maneiras de trazer a pré-renderização de JS para Firebase Hosting, mas não temos planos firmes de compartilhar no momento. (Nota pessoal: Eu realmente quero ver isso acontecer).

Não há cronograma. Queremos isso tanto quanto você.

Você terá que decidir por conta própria o que deve fazer. Não temos um mapa rodoviário público. Não podemos dar qualquer garantia em qualquer cronograma, independentemente do número de demandas ou consultas. Desculpe, não são boas respostas fofas, mas espero que as mais realistas sejam mais úteis para o seu planejamento.

☼, Kato

É bom ver que você realmente se preocupa com isso :) Obrigado pessoal!

@mbleigh / @katowulf Uma pergunta sobre o plano de trazer a pré-renderização de JS para o Firebase: como a pré-renderização de JS será melhor com o suporte SEO atual que o Firebase está oferecendo?

Com base nessa resposta do SO , o Firebase já fornece SEO pronto para uso desde o ng-conf 2015.

Portanto, não entendo as vantagens de ainda tentar usar Prerender.io no Firebase.

@douglascorrea para Google SEO, as melhorias serão marginais, mas (como se constatou) o Google não é o único rastreador por aí: sorria:

O maior ganho para isso é para sites que desejam oferecer melhor suporte para tags OpenGraph do Facebook, cartões do Twitter e mecanismos de busca não pertencentes ao Google.

Obrigado @mbleigh , isso esclarece as coisas e me faz pensar que realmente queremos esse apoio, ou algum tipo de alternativa como @drtriumph disse em seu comentário.

Eu estava procurando uma solução e encontrei os seguintes detalhes que podem ser bons para outros leitores:

• Em outubro de 2015, o Google suspendeu a recomendação de usar _escaped_fragment_ e o hashbang (! #). Portanto, para o Google, todo SPA deve usar html5 pushstate (html5mode no angularjs). Mas eles continuarão apoiando o hashbang (! #) E traduzindo-o em fragmento de escape por enquanto.
• Facebook e provavelmente outros crawlers ainda precisam do escaped_fragment, a notação de hashbang de tradução automática do Facebook para _escaped_fragment. E provavelmente outros rastreadores fazem o mesmo, já que foi a recomendação anterior do google.
• Como o Firebase ainda não oferece suporte a redirecionamentos baseados em User-Agent, nossa esperança permanece nos rastreadores que traduzem hasbangs (! #) Para escape_fragament como este:
  Se seus URLs forem semelhantes a este:
  http://www.example.com/#!/user/1
  Em seguida, acesse seus URLs como este:
  http://www.example.com/?_escaped_fragment_=/user/1

Então, por enquanto, uma ideia para descobrir isso poderia ser esta:

• Não use pushstate html5 (modo html5 em Angular) e use hashbang (! #)
• Use prerender.io para criar uma versão estática / em cache de cada página que você deseja em seu aplicativo (como o processo normal de pré-processamento).
• Desenvolva um plugin que armazene essa versão em cache em uma estrutura de pasta que começa com a pasta ?_escaped_fragment_= e crie pastas como:
  Se seus URLs forem semelhantes a este:
  http://www.example.com/#!/user/1
  A pasta gerada será
  ?_escaped_fragment_= +- /user +- /1

Onde o 1 arquivo será o arquivo html real.

• Implante essa pasta em sua pasta raiz do firebase usando firebase-tools (esse processo pode ser automatizado em um cron job ou algo parecido).

Como acho que vai funcionar:

• Quando um rastreador vê seu url hashbang, ele tenta acessar o URL ?_escaped_fragment_= . Como temos arquivos HTML reais nessas pastas, o Firebase os veiculará e não redirecionará para index.html, portanto, o HTML lido pelo rastreador será a versão em cache e não a AngularJS.

Para conseguir isso, precisamos criar um trabalho agendado que execute o pré-renderizador para todas as páginas, salve essa pasta e execute a implantação do Firebase.

Como o Firebase deploy não suporta implantação parcial (sincronizada ou incremental), devemos manter uma cópia atualizada de nossa implantação no servidor que será responsável por este processo.

Vou tentar configurar isso e avisarei se funciona.

Você pode nos permitir definir "X-Prerender-Token" como fazemos com outras chaves de cabeçalho ???
https://www.firebase.com/docs/hosting/guide/full-config.html
https://prerender.io/install-token

+1

@ srk9 envie um problema separado em vez de redirecionar este tópico.

Por que este problema foi encerrado? Não vejo uma solução postada.

@douglascorrea , o que aconteceu com sua ideia?

Obrigado,
- D

Olá @bethuneco , desculpe por não postar o resultado aqui.

Na verdade eu estava prestes a escrever um artigo mas então percebi que essa solução consistirá em um monte de "maquinários" para fazer funcionar na produção, e não me senti confortável em "recomendar" porque não sei como será um comportamento em grande escala.

Mas basicamente, como descrevi antes, preciso de um servidor de "implantação / pré-renderização" que, para cada implantação, pré-renderize / descarta todas as páginas e armazene o HTML resultante nas pastas descritas acima (/? _ Escaped_framgment_ / xxxx). Esses htmls "reais / físicos" serão nossas páginas "pré-renderizadas".

Portanto, toda vez que um rastreador google / facebook / twitter vai para nossa página e solicita o "fragmento de escape" via prefixo "? _Escaped_fragment", ele na verdade aponta para uma pasta real com HTMLs reais, então, esses HTML serão indexados.
Quando um usuário real vai para o aplicativo, ele não usará? _Escaped_fragment, portanto, receberá a página dinâmica.

O problema é que essa "solução" é que precisamos continuar gerando HTMLs para cada uma das páginas adicionais. Por exemplo, se seu aplicativo for um CMS simples, para cada novo post / artigo / página, você precisará executar o processo para gerar a nova página HTML. Mas o problema vai ficar maior quando falamos de uma rede social dinâmica, por exemplo, onde cada usuário pode gerar centenas de páginas "pré-renderizáveis", então seu rastreador pré-renderizado / interno deve estar em execução o tempo todo. E isso, em um mundo real, pode ser um obstáculo.

Esta é uma solução muito "complicada" que poderia funcionar para aplicativos pequenos, mas não para aplicativos realmente grandes, porque na verdade estamos gerando HTMLs para estarmos presentes quando os rastreadores forem embora e não redirecionando automaticamente os rastreadores para nosso serviço pré-renderizado que irá pré-renderizar online (como um processo normal de pré-processamento é).

Portanto, agora, devemos usar um servidor Nginx como servidor estático para ser capaz de pré-processar, ou usar um concorrente Divshot como https://www.netlify.com/ que fornece Prerender pronto para uso para aplicativos de página única .

@douglascorrea ,

Obrigado por essa explicação expandida. Você é a primeira pessoa a mencionar o Netlify, então vou dar uma olhada nisso.

Você está certo ao dizer que pré-renderizar tudo só é adequado para sites pequenos. Felizmente, meu aplicativo é bastante pequeno (máximo de cerca de 1.200 páginas), então isso pode funcionar.

A solução mais simples (e aquela que o Google está evitando) é pré-renderizar o Javascript e servir HTML quando os agentes de usuário do robô são detectados. O Google já demonstrou a renderização fora do navegador, portanto, não é tecnicamente difícil. É um desafio estratégico para eles porque parece ajudar um concorrente no negócio de anúncios.

Se algo funcionar, postarei uma atualização aqui.

Deixe-me esclarecer aqui qualquer pessoa que possa estar confusa:

O Firebase Hosting oferece suporte à pré-renderização de JS no servidor? Não, não importa. A pré-renderização do lado do servidor é algo que gostaríamos de oferecer suporte e está em nosso roteiro de longo prazo, mas não temos datas ou cronogramas específicos para anunciar neste momento. Sabemos que este é um ponto problemático, especialmente para aqueles que usam o compartilhamento do Facebook ou cartões do Twitter, e esperamos poder compartilhar mais sobre isso no futuro.

Você não pode simplesmente apoiar, por exemplo, X-Prerender-Token ? Não, isso não vai funcionar. A pré-renderização deve servir o _conteúdo pré-renderizado real_ na URL ?_escaped_fragment_= , o que significa que não é apenas o cabeçalho, mas o conteúdo que o servidor deve conhecer e manipular adequadamente. Não existe uma solução pela metade, tanto quanto gostaríamos que houvesse.

Que tipo de pré-renderização é possível? O único tipo de "pré-renderização" real que você pode fazer no momento é a compilação estática do site. Normalmente, isso é feito com algo como Jekyll, mas certamente é possível usar um navegador sem cabeça localmente para "pré-renderizar" um site mais dinâmico. Você deve renderizar exaustivamente cada URL e então implantá-lo, portanto, este não é um caso de uso fantástico no momento. Observe também que criar nomes de arquivo com ?_escaped_fragment_ neles _não_ é possível, já que o CDN remove os parâmetros de consulta e geralmente não é um caso de uso compatível.

É algum tipo de estratégia do Google para manter outros rastreadores inativos? Não, absolutamente não. Queremos apoiar as vantagens da pré-renderização para o Firebase Hosting. É tudo questão de tempo e recursos.

Tive que mudar do Firebase hosting devido ao problema de tags de mídia social / SEO alternativo. É um problema quando pessoas que não são da área de tecnologia percebem que não temos boas fotos em nossos links como todo mundo na internet.

Você pode pré-renderizar com phantomjs e middleware pré-renderizar. É open source e funciona bem, mas usei o prerender.io para evitar o trabalho de ops. É um pouco lento na primeira solicitação, mas você pode armazenar páginas em cache solicitando preventivamente todas as páginas.

É bom solicitar todas as páginas também, porque então você pode executar alguns testes, analisar o html para ter certeza de que as tags e o conteúdo são renderizados corretamente.

Há uma enorme ressalva tho. O Prerender não funciona com dados Firebase ao vivo. Como poderia? Os dados do Firebase são em tempo real, a conexão é persistente. Prerender é único, a conexão é fechada. Não há como saber quando a página terminou de renderizar, porque você não pode contar as solicitações.

Tive algumas ideias para consertar isso:

1. Faça uma solicitação GET a cada assinatura do .on("value") firebase. Ignore a assinatura quando for uma solicitação de pré-processamento. Ignore a solicitação GET quando for um usuário normal. Isso não funcionará para eventos de .on("child_*") .
2. Defina o sinalizador de pré-renderização global false no topo de seu arquivo de entrada principal e, para cada componente da página, defina o sinalizador como true assim que os dados forem carregados. Com o design adequado, geralmente há um _estado de carregamento_ e um _estado de erro_ e um _estado de sucesso_, portanto, no método auxiliar do estado de erro / sucesso, defina o sinalizador como true .

É uma dor, mas apenas algumas páginas dinâmicas não são renderizadas corretamente e precisam de tratamento especial. Ainda acho que os benefícios estáticos superam os custos.

@mbleigh ansioso para saber o que vocês vão fazer no futuro. Com qualquer coisa, tenho certeza de que entrar no Google é um passo para trás, dois passos para frente.

Realmente esperando alguma solução alternativa. A única razão pela qual preciso do back-end são também os cartões do Twitter e opengraphs. O back-end seguro oferece alguns outros benefícios para aplicativos de página única, como renderização isomórfica, mas é bom ter isso. As tags do Twitter e OG são importantes para qualquer aplicativo que precise de compartilhamento.

Poderia haver algum tipo de regra de reescrita que comandaria o back-end do firebase para servir este ou aquele objeto / html do banco de dados?

Esse objeto pode ser preparado com antecedência, pois cada compartilhamento começa, bem, por visitar o url ou passar um botão Compartilhar primeiro.

bump .. Fiquei maravilhado com o Firebase e então percebi que não consigo usá-lo, lendo esses comentários ..
Como também preciso de um serviço como o Prerender para funcionar. Então, o que está acontecendo com o desenvolvimento disso?

Junte-se ao Google! Você é um motor de busca freegin '!! :rindo:

Sério. Isso é muito importante. Isso pode ser a coisa mais importante de todos os tempos.

Eu sei que foi uma brincadeira, mas para deixar claro, esse comentário seria direcionado à Pesquisa Google ou ao Google Firebase? Apenas um deles é um mecanismo de pesquisa e apenas um deles fornece Firebase Hosting (e a pré-compilação de páginas da web não é exatamente o escopo de nenhum deles, embora seja um claro valor agregado para o Hosting funcionar melhor com ferramentas que oferecem isso).

Em uma nota de manutenção relacionada, ele também não está relacionado a firebase-tools (ou seja, este rastreador de problemas de OSS). Cuidarei para garantir que seu voto seja adicionado à discussão de prioridades; a lista de e-mails é provavelmente o melhor lugar para entrar em contato com solicitações de recursos principais no futuro.

Mais importante ainda, não esquecemos isso. Ainda é muito importante para nós. Um pouco menos importante do que integrar com o Google Cloud Functions e fornecer insights sólidos por meio do Analytics, Crash Reporting e Test Labs, mas ainda é importante.

Vou trazer isso à tona novamente na próxima vez que discutirmos as prioridades. Nós realmente apreciamos você adicionar sua opinião aos comentários ☼☼☼

obrigado por seus esforços no firebase @katowulf !!
Isso é a única coisa que me impede de usar o firebase como um "host" para meus aplicativos ng1.

Você não está sozinho aqui. Outros encontraram a mesma limitação. Observe que, como o Google agora pode indexar conteúdo gerado por JavaScript e há algumas disposições especiais para indexar conteúdo do Firebase, os dados não autenticados do Firebase carregados em suas páginas já devem estar sendo indexados. Mas o suporte total ao pré-compilador está no radar.

@katowulf apenas como aviso (se você ainda não conheceu ou viu), mas o principal problema não é o rastreador do Google. Acho que as pessoas já sabem disso se usarem algo como o Prerender. São os outros crawlers como, por exemplo, LinkedIn, Facebook, Twitter e outros que não estão satisfeitos. Eles querem conteúdo estático

@samvloeberghs Acho, no entanto, que as implicações de o Google fornecer esse suporte é que outros provavelmente irão seguir o exemplo. Portanto, pretendia sugerir que é um passo na direção certa para tornar isso generalizado (e que pelo menos funciona com o Google hoje).

É improvável que o FB / LinkedIn / Twitter siga a capacidade do Google de avançar rapidamente como gostaríamos. Sempre haverá um grande jogador por trás, e simplesmente não podemos ignorá-lo. Por outro lado, o Google está resolvendo o problema trabalhando no NG2, que contará com a compilação do lado do servidor usando Angular Universal :) 👍

Angular para o resgate! Espere aí, você está dizendo que o aprendizado de máquina não resolverá tudo isso?

Para oferecer meus 2 centavos, estou descobrindo que os clientes parecem valorizar os cartões de mídia social pelo menos tanto quanto o SEO. Falando em projetos recentes, o Twitter / Facebook tem sido a principal forma de as marcas se promoverem por meio do compartilhamento de links para seus sites.

Obviamente, o SEO ainda é crítico, mas atacar os cartões de mídia social seria uma solução mais simples / de curto prazo? Como os cartões da web são apenas metatags, você poderia definir a estrutura em firebase.json (semelhante às regras de segurança)? O Firebase poderia então injetar as metatags certas para rastreadores do Twitter / Facebook, embora eu tenha certeza de que não é tão simples assim 😄.

Apesar de tudo, muito obrigado pelo excelente trabalho e apoio da comunidade. Ansioso por alguns dos recursos mais interessantes do Firebase (funções de nuvem 👍!).

@katowulf , meu comentário foi uma 'pancada' forte mais do que qualquer coisa ... vocês estão fazendo um trabalho incrível! Estou direcionando minha brincadeira mais para o Google como um todo. No entanto, acredito que o Firebase é a nova * divisão do Google que deve ser responsável por todo esse problema "SPA / PWA - renderização de página SEO".

Meus pensamentos sobre isso são ...

Quaisquer que sejam os produtos que o Google lança para o mundo, devem funcionar perfeitamente com todas as plataformas que usamos hoje e ser exemplos brilhantes que funcionam e refletem seu produto original, a Pesquisa Google.

Os SPAs já existem há algum tempo ... O Google tem 2 deles [Angular] e [Polímero]. Implementar SEO neles (Meta Tags / OpenGraph / Schema) é uma grande caixa preta (a menos que você seja um ninja backend). Foi uma ótima notícia que a Pesquisa Google começou a processar JS, mas isso é definitivamente apenas metade da batalha (talvez menos).

Firebase, sendo um back-end como serviço (BaaS), parece o novo * grupo do Google perfeito para realmente suavizar toda essa coisa de renderização de página do SPA. Eu sei que vocês vão chegar a isso, mas eu sinto fortemente que isso deve pertencer como um recurso de prioridade crítica / superior.

Imagine ler este título ...

PRESENTES DE FIREBASE ...
SEO novo e aprimorado para todos os aplicativos de página única (SPAs) e aplicativos web progressivos (PWAs) prontos para uso!

Os desenvolvedores se reunirão: +1:

Só queria avisar rapidamente que definitivamente temos isso em nosso radar. É importante, mas também são muitas outras coisas (como Kato enumerou). Temos algumas ideias sobre algumas maneiras excelentes de lidar com esse problema, mas elas têm algumas dependências que precisamos eliminar primeiro. Tente ser paciente e saiba que isso está definitivamente em nossas mentes!

Bem, isso é decepcionante. Agora estou procurando alternativas para o Firebase ...

Já se passaram quase 3 anos ...

alguma atualização disso.. ?

isso não deveria funcionar agora que o firebase possui divshot? atualize o PLZ!

Estamos bem cientes do desejo por esse tipo de funcionalidade e é uma prioridade para nós fornecer algumas soluções melhores aqui. Ainda não tenho nenhum tipo de cronograma para anunciar, mas não esquecemos de vocês.

+1

:( :( :(

Chegamos a uma conclusão semelhante. O que mais você viu? ;)

Eu apenas uso as funções do Firebase como meu ponto de extremidade do link de compartilhamento e, em seguida, redireciono com JavaScript e um link.

Você pode ou não ter visto isso, mas o Cloud Functions agora está integrado ao Firebase Hosting !!!

Isso pode ser considerado nossa solução canônica para renderização do lado do servidor com Firebase Hosting. Apreciar!

@mbleigh OK, então se eu tiver um arquivo de cabeçalho global com metadados como o abaixo, no momento isso não é replicado no frontend. Se eu instalar as funções do Cloud, isso é tudo que preciso para ativar este recurso.

<meta name="description" content="{{ pageDescription }}">

Incrível, obrigado pela atualização.

Em 17 de maio de 2017, 17:39, "Michael Bleigh" [email protected] escreveu:

Você pode ou não ter visto isso, mas o Cloud Functions agora está integrado
com Firebase Hosting https://firebase.google.com/docs/hosting/functions
!!!

Isso pode ser considerado nossa solução canônica para renderização do lado do servidor
com Firebase Hosting. Apreciar!

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-302268864 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbtWCdygdw4ozixK5_XcL2Dlznp4Jks5r65M-gaJpZM4CtPYG
.

Sei que esse pode não ser o melhor problema para esses comentários, mas a busca no Google por meus problemas me levou a isso e parece haver uma discussão ativa, então, por favor, me perdoe!

O que eu adoraria ver para resolver o problema de renderização de modelos de gráfico aberto para sites sociais em SPAs hospedados no firebase - é a capacidade de balancear a carga por meio do agente do usuário.

Eu gostaria de poder usar funções de nuvem para colher alguns dados de modelo do memcache / cloudsql e renderizar as tags de modelo para a plataforma social solicitante, mas recorrer à hospedagem estática para todos os outros clientes. Assim, não precisaríamos de renderização completa do lado do servidor para todas as solicitações.

@cdharris Totalmente, ATM, reescrevendo toda a solicitação para uma função que tentei usar window.location para fazer o redirecionamento adicional (para o cliente / visitante) para a hospedagem estática, para meus objetivos de SEO não funcionou, talvez para fins sociais, sim.

@mbleigh existe alguma opção para reescrever a solicitação de crawlers / redes sociais diferenciando-os dos clientes / visitantes? Eu testei com _escaped_fragment_ entre outras expressões glob ... Nada = / Agradecemos antecipadamente

Tomar a decisão do que retornar em uma função do firebase pode funcionar. Podemos dizer: o req vem do Facebot? Em seguida, retorne essas tags de gráfico aberto. Caso contrário, retorne o index.html. Mas como faço para retornar o maldito index.html de uma função firebase?

fs.readFileSync ('./ index.htm')

Em 13 de setembro de 2017 4:34, "Birowsky" [email protected] escreveu:

Tomar a decisão de conteúdo em uma função firebase pode funcionar. Nós podemos dizer:
o req vem do Facebot? Em seguida, retorne essas tags de gráfico aberto. Se não,
retorne o index.html. Mas como faço para retornar o maldito index.html de um
função firebase?

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329140134 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbrXQNbVMhRmeZQTbx3Z3vi0c1HXTks5sh728gaJpZM4CtPYG
.

@megamindbrian está implícito que as funções têm acesso aos arquivos hospedados? Está documentado em algum lugar? Obrigado de qualquer maneira!

Sim. É assim que me lembro de ter usado, boa pergunta tento achar docs.

Em 13 de setembro de 2017, às 7h09, "Birowsky" [email protected] escreveu:

@megamindbrian https://github.com/megamindbrian está implícito que o
funções têm acesso aos arquivos hospedados? Está documentado em algum lugar?
Obrigado, de qualquer maneira!

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

Aqui um
https://stackoverflow.com/questions/42960506/how-can-i-read-and-write-to-firebase-storage-from-within-cloud-functions-for-fir

Em 13 de setembro de 2017, às 7h09, "Birowsky" [email protected] escreveu:

@megamindbrian https://github.com/megamindbrian está implícito que o
funções têm acesso aos arquivos hospedados? Está documentado em algum lugar?
Obrigado, de qualquer maneira!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

Este usa um diretório temporário, mas acho que também funciona com arquivos
você carregou junto com seu projeto. Pode ser imutável, por isso
o exemplo é descarregar o arquivo para salvá-lo em outro lugar
https://firebase.google.com/docs/storage/extend-with-functions

Em 13 de setembro de 2017, 7h12 , "Brian Cullinan"

Aqui, um https://stackoverflow.com/questions/42960506/how-can-i-
read-and-write-to-firebase-storage-from-within-cloud-functions-for-fir

Em 13 de setembro de 2017, às 7h09, "Birowsky" [email protected] escreveu:

@megamindbrian https://github.com/megamindbrian está implícito que o
funções têm acesso aos arquivos hospedados? Está documentado em algum lugar?
Obrigado, de qualquer maneira!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

Ainda não vejo uma introdução adequada de como as funções são conceitualmente conectadas aos arquivos hospedados. Se você quiser explicar, tenho alguns pontos para você: https://stackoverflow.com/q/46192570/592641

Eu poderia me ver respondendo a isso com exemplos de código, mas não estava claro
que de dentro de sua função você pode responder com o conteúdo de um arquivo em
seu projecto? Não é um redirecionamento.
Vou desenterrar mais alguns códigos.

Em 13 de setembro de 2017, 7h18, "Birowsky" [email protected] escreveu:

Ainda não vejo uma introdução adequada de como as funções são
conceitualmente conectado aos arquivos hospedados. Se você se importar em explicar, eu tenho
alguns pontos para você: https://stackoverflow.com/q/46192570/592641

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329182385 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbnCSoaKUuVKUnfha5A-4K-p76kZ3ks5sh-QygaJpZM4CtPYG
.

@megamindbrian Acabei de tentar fs.readFileSync('./index.html') mas infelizmente o arquivo não está lá. Eu também esperava encontrar os arquivos hospedados em algum depósito de armazenamento gerado implicitamente, sem sorte. Como você procederia?

Se você aninhar seu diretório Hosting public dentro de seu diretório functions , ele estará disponível lá.

@Birowsky Sim, aqui está como estou lendo um arquivo de uma função de nuvem, por exemplo, index.js:

const page = fs.readFileSync(__dirname + '/facebook-meta.html').toString();

Mas se o layout do seu projeto for:

project/
project/src (<- actual source of app)
project/functions ( <- firebase functions)
project/dist (<- build output)

Você precisará copiar os arquivos relevantes de / dist para / funções

Este problema tem quase 3 anos (até agora) e ainda sem sorte neste momento ????

Provavelmente significa que o Google abandonará o firebase no meio do suporte a todos
nossos aplicativos.

Nossa solução oficial para essa classe de problemas é usar Cloud Functions
para fazer renderização do lado do servidor para o conteúdo que precisa ser visível para estático
rastreadores:

https://firebase.google.com/docs/hosting/functions

Esta é uma solução mais robusta e generalizada que permite todos os tipos de
coisas legais!

Se você sente fortemente que ainda há algo faltando, por favor, nos dê
um caso de uso detalhado para que possamos pensar em como lidar com isso! :)

Qui, 14 de setembro de 2017, 15:57 Brian Cullinan [email protected]
escrevi:

Provavelmente significa que o Google abandonará o Firebase no meio do suporte a todos
nossos aplicativos.

Na quinta-feira, 14 de setembro de 2017 às 15:52, tofanelli [email protected]
escrevi:

Este problema tem quase 3 anos (até agora) e ainda sem sorte neste momento ????

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
<
https://github.com/firebase/firebase-tools/issues/33#issuecomment -329630338
,
ou silenciar o tópico
<
https://github.com/notifications/unsubscribe-auth/AX5XbhBSDSl6TStSv7M02Dx0brb9MOPbks5sia44gaJpZM4CtPYG

.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329631266 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAD_iI6L-yu3RTECI88a2y_ZOzIxdDQks5sia9rgaJpZM4CtPYG
.

@mbleigh Você

Sim, se bem entendi. Você já teve problemas antes?

Qui, 14 de setembro de 2017, 18:38 Brian Cullinan [email protected]
escrevi:

@mbleigh https://github.com/mbleigh Você pode usar funções de nuvem em um
diretório raiz do firebase ainda?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329653711 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAAD_g7BV3TMM_5nVX92_-3ai_mZHfHBks5sidUvgaJpZM4CtPYG
.

@mbleigh

Esta é uma solução mais robusta e generalizada que permite todos os tipos de coisas legais!

SSR torna nosso sistema mais complexo 😢
Acho que a pré-renderização é mais legal, nem sempre, mas com frequência 💡
por exemplo, Facebook OGP, Twitter Cards, SEO para não-Google

@mbleigh @megamindbrian Obrigado por suas mensagens. Eu fiz minha hospedagem direcionando todas as solicitações para minha função e resposta index.html que está hospedada em functions/build/index.html para clientes. Mas não sei como confirmar é um pedido vindo do FaceBot? Tentei usar as ferramentas de depuração do Facebook para acessar a url do meu site, imaginei que a função de nuvem seria acionada, mas não foi. Não estou familiarizado com o desenvolvimento de back-end, você pode me dar uma dica? Obrigado.

Ao usar a ferramenta do Facebook, certifique-se de usar o botão que lê algo
como "Obter uma nova cópia", perto da visualização.

Na terça-feira, 17 de outubro de 2017 às 8h29, Jude [email protected] escreveu:

@mbleigh https://github.com/mbleigh @megamindbrian
https://github.com/megamindbrian Obrigado por suas mensagens. eu tenho
fiz minha hospedagem direcionando todas as solicitações para minha função e resposta
index.html que está hospedado em functions / build / index.html para clientes. Mas
Não sei como confirmar é um pedido vindo do FaceBot? eu tentei
usando ferramentas de depuração do Facebook para acessar a url do meu site, eu suponho que
a função da nuvem seria acionada, mas não foi. Não estou familiarizado com
desenvolvimento de back-end, você pode me dar alguma dica? Obrigado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-337266581 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbrCQ3mowcUnJjWYWsaiScoN1y4l0ks5stMfcgaJpZM4CtPYG
.

-
AVISO DE CONFIDENCIALIDADE: O conteúdo desta mensagem de e-mail e qualquer
anexos destinam-se exclusivamente ao (s) destinatário (s) e podem conter
informações confidenciais e / ou privilegiadas e podem ser legalmente protegidas
da divulgação. Em seguida, é compartilhado com empresas de tecnologia, bots, hackers,
agências governamentais e profissionais de marketing. A segurança desta mensagem é nenhuma,
e pode ser compartilhado no Instagram a qualquer momento. Se você está bem com isso,
por favor responda. Na verdade, não há segurança ou privacidade em lugar nenhum. E se
você discorda, pode querer ir acampar e conversar com as pessoas cara a cara
como nos velhos tempos.

Existe algo em seus logs do Firebase como "Execução de função iniciada"?

Na terça-feira , 17 de outubro de 2017 às 8:37 AM, Brian Cullinan
escrevi:

Ao usar a ferramenta do Facebook, certifique-se de usar o botão que diz
algo como "Obter uma nova cópia", perto da visualização.

Na terça-feira, 17 de outubro de 2017 às 8h29, Jude [email protected] escreveu:

@mbleigh https://github.com/mbleigh @megamindbrian
https://github.com/megamindbrian Obrigado por suas mensagens. eu tenho
fiz minha hospedagem direcionando todas as solicitações para minha função e resposta
index.html que está hospedado em functions / build / index.html para clientes. Mas
Não sei como confirmar é um pedido vindo do FaceBot? eu tentei
usando ferramentas de depuração do Facebook para acessar a url do meu site, eu suponho que
a função da nuvem seria acionada, mas não foi. Não estou familiarizado com
desenvolvimento de back-end, você pode me dar alguma dica? Obrigado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-337266581 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbrCQ3mowcUnJjWYWsaiScoN1y4l0ks5stMfcgaJpZM4CtPYG
.

-
AVISO DE CONFIDENCIALIDADE: O conteúdo desta mensagem de e-mail e qualquer
anexos destinam-se exclusivamente ao (s) destinatário (s) e podem conter
informações confidenciais e / ou privilegiadas e podem ser legalmente protegidas
da divulgação. Em seguida, é compartilhado com empresas de tecnologia, bots, hackers,
agências governamentais e profissionais de marketing. A segurança desta mensagem é nenhuma,
e pode ser compartilhado no Instagram a qualquer momento. Se você está bem com isso,
por favor responda. Na verdade, não há segurança ou privacidade em lugar nenhum. E se
você discorda, pode querer ir acampar e conversar com as pessoas cara a cara
como nos velhos tempos.

-
AVISO DE CONFIDENCIALIDADE: O conteúdo desta mensagem de e-mail e qualquer
anexos destinam-se exclusivamente ao (s) destinatário (s) e podem conter
informações confidenciais e / ou privilegiadas e podem ser legalmente protegidas
da divulgação. Em seguida, é compartilhado com empresas de tecnologia, bots, hackers,
agências governamentais e profissionais de marketing. A segurança desta mensagem é nenhuma,
e pode ser compartilhado no Instagram a qualquer momento. Se você está bem com isso,
por favor responda. Na verdade, não há segurança ou privacidade em lugar nenhum. E se
você discorda, pode querer ir acampar e conversar com as pessoas cara a cara
como nos velhos tempos.

A função

@judewang dê uma olhada em https://firebase.google.com/docs/hosting/functions#when_is_cached_content_served

Para um teste rápido e sujo, você pode tentar adicionar algum parâmetro de consulta aleatório ao URL testado.

Portanto, a questão inicial era como usar o pré-renderizador. Esta solução não resolve o problema de integração de pré-renderização, mas resolve o gráfico aberto para um aplicativo de página única.

1. Em meu script de construção, copio public/index.html para functions/hosting/index.html
2. Em firebase.json adiciono uma regra de reescrita para apontar para uma função de nuvem chamada "host"

"hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "**",
        "function": "host"
      }
    ]
  }

1. Eu defino uma função de nuvem chamada host . Na maioria dos casos, isso apenas retorna o arquivo index.html que copiei para functions/hosting/index.html , mas se o agente for um dos analisadores de gráfico abertos conhecidos, eu retorno os dados do banco de dados em formato de gráfico aberto com base no rota.

exports.host = functions.https.onRequest((req, res) => {
  var userAgent = req.headers['user-agent'];
  if (userAgent.startsWith('facebookexternalhit/1.1') ||
    userAgent === 'Facebot' ||
    userAgent.startsWith('Twitterbot')){

    //getOpenGraph() parses the path, and gets some data from the firebase database to construct open graph data.
    // eg: <meta property="og:description" content="My super cool webpage." /> <meta property="og:title"...

    res.status(200).send(getOpenGraph(req.path));
  }
  else{
    //optional - turn on caching: res.set('Cache-Control', 'public, max-age=300, s-maxage=600');
    res.status(200).send(fs.readFileSync('./hosting/index.html').toString());
  }
});

Eu acho que é isso. Espero que isso ajude algumas pessoas!

Devo dizer que isso é decepcionante, pois os concorrentes mais recentes têm isso, como https://www.netlify.com/features/ , que definitivamente o torna mais atraente para aplicativos da web que precisam de integração SEO / Social.

O Firebase está matando para mobile / react native, e estou realmente gostando dele como uma plataforma geral, mas esta é uma grande falha para aplicativos web IMO.

Em geral, descobrimos que o conteúdo que precisa de pré-renderização também é melhor servido pela renderização do lado do servidor (por motivos de desempenho e primeiro carregamento). A pré-renderização genérica não está em nosso roteiro imediato por esse motivo.

Dito isso, estamos ouvindo o feedback sobre o desejo de que a integração de funções seja mais flexível para permitir a execução de funções "às vezes". Como o Firebase Hosting depende muito do cache de CDN, esse tipo de flexibilidade é difícil de conseguir tecnicamente para nós. Continuaremos a ouvir comentários e tentar encontrar maneiras de tornar a plataforma melhor para seu caso de uso. :sorriso:

Uma IU no Firebase para conectar funções diretamente à frente de um domínio
name consertaria meu caso de uso.

https: //us-central1-...dsaflk; sdafkljsdafkl; jsdf;
lkjsadfkljasdfkljsdaflk.cloudfunctions.net

Na sexta-feira, 5 de janeiro de 2018 às 15h33, Michael Bleigh [email protected]
escrevi:

Em geral, descobrimos que o conteúdo que precisa de pré-renderização também é
conteúdo que é melhor servido pela renderização do lado do servidor (para desempenho e
motivos de primeiro carregamento). A pré-renderização genérica não está em nosso roteiro imediato
por esta razão.

Dito isso, estamos ouvindo o feedback sobre o desejo de
integração de funções para ser mais flexível para permitir a função "às vezes"
execução. Como o Firebase Hosting depende muito do armazenamento em cache de CDN desse tipo
de flexibilidade é difícil de alcançar tecnicamente para nós. Nós continuaremos
ouvir feedback e tentar encontrar maneiras de tornar a plataforma melhor para
seu caso de uso. 😄

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-355683821 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AX5XbtVDQSPOIAZFyozujQQUektf2WM1ks5tHqM8gaJpZM4CtPYG
.

-
"Eu estudei engenharia"

AVISO DE CONFIDENCIALIDADE: O conteúdo desta mensagem de e-mail e qualquer
anexos destinam-se exclusivamente ao (s) destinatário (s) e podem conter
informações confidenciais e / ou privilegiadas e podem ser legalmente protegidas
da divulgação. Em seguida, é compartilhado com empresas de tecnologia, bots, hackers,
agências governamentais e profissionais de marketing. A segurança desta mensagem é nenhuma,
e pode ser compartilhado no Instagram a qualquer momento. Se você está bem com isso,
por favor responda. Na verdade, não há segurança ou privacidade em lugar nenhum. E se
você discorda, pode querer ir acampar e conversar com as pessoas cara a cara
como nos velhos tempos.

@mbleigh não é este ponto de vista um tanto oposto ao ethos de serverless, e usando um provedor BaaS / FaaS como o firebase? Com a tendência de SPAs nos últimos anos, este é um caso de uso bastante comum, tanto que tem sido abordado por concorrentes como netlify e roast, por exemplo. Embora sejam menores, para hospedar isso faz sentido, proporcionando tempos de carregamento mais rápidos, juntamente com capacidade de descoberta e compartilhamento essenciais.

Em vez de adicionar sobrecarga adicional de desenvolvimento e manutenção para os clientes, um serviço de pré-processamento opcional ou, pelo menos, a capacidade de integração com um serviço de terceiros, como o prerender.io, seria uma grande melhoria.

O Firebase é realmente uma ótima plataforma, mas parece mais voltada para dispositivos móveis, com a hospedagem sendo a única parte sem brilho para mim.

Obrigado pela resposta rápida.

@mbleigh

Em geral, descobrimos que o conteúdo que precisa de pré-renderização também é melhor servido pela renderização do lado do servidor (por motivos de desempenho e primeiro carregamento).

Além do argumento direto de

Aplicativos de página única ou seções de aplicativos precisam recorrer a algum grau de renderização do lado do cliente e, infelizmente, os rastreadores, incluindo o próprio Google, ainda não são muito bons em indexar tais páginas. Tive que recorrer ao PrerenderIO após meses de tentativas fracassadas de permitir que o Google indexasse meus sites corretamente, algo que me forçou a manter uma abordagem baseada no servidor express.js, __apenas para o problema de indexação__.

Pense em um site que tem uma página /product/**.html que processa QUALQUER produto, dependendo do URL profundo detectado no lado do cliente. A lógica por trás desse design é que carregar uma página separada real para um produto, mesmo levando em consideração o navegador e o cache do cdn, não é tão fácil da perspectiva de UX quanto carregar os dados de outro produto e renderizá-los enquanto muda a url. Os clientes passam a maior parte do tempo nas páginas dos produtos quando navegam para comprar enquanto estão em um site de comércio eletrônico e frequentemente navegam para outros produtos por meio de links de "produtos relacionados" ou links de pesquisas Ajax na página.

Estamos presos ao mecanismo absurdo (IMHO) de _escaped_fragment_ para que não sejamos penalizados por camuflagem ... o Google está achando difícil contratar engenheiros com soluções bacanas para esse problema onipresente?

Acho até mesmo a ausência total de uma seção de indexação de site / webapp na documentação __unjustificável__.
Os aplicativos móveis podem dominar o mercado consumidor, mas e quanto ao B2B? A maioria dos departamentos de escritório opera em computadores desktop. Indexar sites de desktop para alcançar departamentos de P&D ou compras não é "bom ter", é fundamental para empresas fornecedoras de B2B.

Se o Firebase / Google não estiver interessado nisso porque aplicativos chamativos executados em gadgets brilhantes geram mais receita, seria bom saber disso; 4 anos dando respostas evasivas a fiéis adotantes de tecnologia são um insulto à inteligência de qualquer pessoa.

Ranty? Sim, mas sou eu que tenho que justificar os custos adicionais de infraestrutura, tempos de desenvolvimento adicionais e comportamentos inesperados dos rastreadores para meus clientes.

quatro anos em que esta edição está aberta parece um pouco bobo. @cleverplatypus - não poderia concordar mais com seus sentimentos.

Essa área de problema geral não é algo em que paramos de pensar, mas ainda não temos planos imediatos para a pré-renderização do fragmento escapado.

Reconheço que definitivamente há momentos em que um aplicativo de página única estático pode se beneficiar do pré-processamento; no entanto, ainda acredito que na maioria (mas não em todos) os casos desses tipos de sites são ainda melhor atendidos pela renderização do lado do servidor que pode inicializar o SPA a partir de qualquer URL.

Nosso objetivo é tornar o Firebase Hosting uma plataforma fantástica para fornecer todos os tipos de experiências na web. Embora aprecie o feedback franco e apaixonado fornecido neste tópico, temos recursos limitados e temos que priorizar o trabalho que achamos que terá o maior impacto para nossa base de clientes em geral. Se você quiser ajudar a mudar nossa opinião sobre a priorização de um recurso que você acredita fortemente, a melhor maneira é registrar uma solicitação de recurso - eles são computados e ajudam a nos orientar em direção ao trabalho que é exigido por nossa comunidade de desenvolvedores.

Vou encerrar este tópico, pois não acho que haja realmente algum lugar para a conversa ir, mas eu encorajo qualquer um que não seja bem servido por nossa integração do Cloud Functions a arquivar uma solicitação de recurso para pré-renderização para que podemos ver diretamente o quão grande é a demanda!

Obrigado por usar o Firebase Hosting, todos 😸