Firebase-tools: Используйте хостинг с prerender.io

Созданный на 10 окт. 2014  ·  93Комментарии  ·  Источник: firebase/firebase-tools

Привет

Мне интересно, есть ли способ использовать хостинг Firebase в сочетании с такой службой, как prerender.io?
Таким образом можно было бы развернуть веб-приложение (то есть приложение angularjs) с возможностями SEO.

благодаря

question

Самый полезный комментарий

Просто хотел быстро сказать, что это определенно есть на нашем радаре. Это важно, как и многие другие вещи (как перечислила Като). У нас есть несколько идей о некоторых отличных способах решения этой проблемы, но у них есть некоторые зависимости, которые мы должны сначала устранить. Постарайтесь сохранять терпение и знайте, что это определенно у нас на уме!

Все 93 Комментарий

Привет,

В настоящее время правила перезаписи / перенаправления хостинга Firebase недостаточно детализированы для предварительной отрисовки сервисов, но некоторые из наших клиентов добились успеха, встроив этап предварительной отрисовки в процесс сборки для довольно статичных сайтов с использованием html5 pushState. Они предварительно визуализируют каждую страницу на основе одностраничного приложения, так что правильный контент обслуживается поисковым роботом, а затем, если пользователь переходит на другую страницу, веб-приложение берет на себя и повторно отображает без обновления страницы.

Это, очевидно, довольно сложно и явно не идеально, но мы работаем над тем, чтобы сделать это гораздо менее болезненным.

надеюсь, это поможет

Крис

Я понимаю, что прошло всего два месяца, но есть ли новости по этому поводу? Поскольку вы, ребята, теперь принадлежите Google, я предполагаю, что они хотят, чтобы сайты, размещенные на firebase, индексировались их поисковой службой.

В настоящее время у нас нет конкретных обновлений по этому поводу, просто SEO, очевидно, важен для нас и сохраняет актуальность хостинга Firebase для разработчиков. Я надеюсь скоро получить для вас обновление

Привет, ребята! Я просто хотел узнать, каков статус этого обновления? это произойдет в ближайшее время? Я использую хостинг Firebase, и это здорово, единственное, что меня беспокоит, - это SEO, мой сайт нигде не отображается в Google, также я искал интеграции seo с firebase и не смог найти никакого решения. Мне очень нравится хранить все в одном месте, поэтому было бы стыдно переходить на другую службу, которая может обслуживать мои страницы для поисковой машины Google. Это было бы огромным улучшением, поскольку я знаю, что Firebase теперь принадлежит Google. Спасибо!

Также все еще интересуюсь этой услугой. Благодаря!

Добавляю свой голос в ветку - было бы здорово иметь эту функцию!

+1

Я тоже этого жду.

В качестве альтернативы я ищу использование https://divshot.com + firebase.

+1

В связи с недавним объявлением о слиянии DIvshot и Firebase эта проблема возникает снова. Я фактически перешел на Divshot, чтобы использовать возможности бесплатного настраиваемого домена и prerender.io. Как Fireabse решит эти проблемы? Собираетесь ли вы добавить пользовательские домены на уровень бесплатного пользования? А как насчет prerender.io?

Мы изучаем способы, с помощью которых мы могли бы перенести предварительную отрисовку JS на хостинг Firebase, но в настоящее время у нас нет никаких твердых планов, которыми можно было бы поделиться. (Личное примечание: я действительно хочу, чтобы это произошло).

Поскольку Firebase считает, что все сайты должны работать только по протоколу HTTPS, мы управляем предоставлением сертификатов SSL от имени наших пользователей. Стоимость, связанная с этим, не позволяет нам предлагать бесплатный хостинг для индивидуальных доменов.

Спасибо за невероятно быстрый ответ.

Некоторые возможности SEO более чем необходимы для платформ статического хостинга веб-приложений, поэтому я просто надеюсь, что вам удастся заставить это работать до середины декабря, иначе многим разработчикам придется переключиться на старых хостинг-провайдеров (к сожалению, включая меня ).

Второй ответ имеет смысл, и я считаю, что просто перейти на платный уровень, жаль, что он не обеспечивает такое же дополнительное масштабирование.

100% хостинговых сайтов Firebase находятся на молниеносной (каламбурной) сети CDN Fastly. Вы получаете все преимущества высокопроизводительного плана Divshot даже на бесплатном плане (только не на личном домене). Что касается пропускной способности, то 10 ГБ в конечном итоге составляют _лот_ полосы для статического веб-сайта.

Я должен признать, что я ничего не знал о высокопроизводительных преимуществах Divshot. В любом случае жаль, что мне, возможно, придется перенести свое приложение и подготовить бэкэнд (и отложить новые функции!), В то время как степень CS съедает почти все мое время. Хотя мой проект не настолько продвинутый, другие могут столкнуться с огромными задержками, поэтому я снова очень надеюсь, что Firebase поможет нам стать оптимизированными для SEO, или, возможно, Divshot задержит его закрытие. Я понимаю, что это, вероятно, не вариант, но если некоторые из нас мигрируют, они могут никогда не вернуться.

Поздравляю @mbleigh с приобретением!

@DamodarSojka , полностью с вами согласен. Я существующий платный пользователь Divshot. Предварительный рендеринг необходим для маркетинга / публикации моего сайта в Facebook. Если Firebase в ближайшее время не предложит эту возможность, мне придется перейти на другие службы веб-хостинга.

+1 за возможности SEO

Мы также платим клиентам Divshot, и нам необходима поддержка Prerender. Поддержка Prerender в Divshot не идеальна (из-за URL-адреса production.blabla.divshot.io после публикации), но если в Firebase нет поддержки Prerender, мы не сможем ее использовать. Благодарю.

Точно так же SEO имеет первостепенное значение, независимо от того, используете ли вы prerender.io или другое аналогичное решение. Эту проблему необходимо решить в Firebase до закрытия Divshot.

Да все еще проблемы с поисковой оптимизацией

+1 - платный клиент Divshot, для перехода на Firebase потребуется поддержка Prerender.

Совершенно согласен. Firebase не является заменой Divshot, если у нее нет возможностей предварительной визуализации. Я платный пользователь Divshot. С двухмесячным уведомлением о закрытии Divshot. Стоит ли работать над переходом на другой сервис? Придется ли мне тратить время на настройку сервера? Или сосредоточиться на том, что я делал? Разве это не идея сервиса? Вам не нужно решать проблемы с сервером? Пожалуйста, объясните, будет ли Firebase вариантом для 14 декабря или мне нужно потратить время на настройку сервера.

Джентльмены, Майк уже полностью описал статус этой функции: мы изучаем способы, с помощью которых мы могли бы перенести предварительную визуализацию JS на хостинг Firebase, но в настоящее время у нас нет никаких твердых планов, которыми можно было бы поделиться. (Личное примечание: я действительно хочу, чтобы это произошло).

Нет временной шкалы. Мы хотим этого так же сильно, как и вы.

Вам нужно будет решить самостоятельно, что вам делать. У нас нет общественной дорожной карты. Мы не можем дать никаких гарантий относительно каких-либо сроков, независимо от количества требований или запросов. Извините, это не радует пушистых ответов, но, надеюсь, реалистичные ответы более полезны для вашего планирования.

☼, Като

Приятно видеть, что вы действительно заботитесь об этом :) Спасибо, ребята!

@mbleigh / @katowulf Один вопрос по поводу этого плана по

Основываясь на этом SO-ответе , Firebase уже предоставляет SEO прямо из коробки с ng-conf 2015.

Так что я не понимаю плюсов того, что все еще пытаюсь использовать Prerender.io на Firebase.

@douglascorrea для Google SEO улучшения будут незначительными, но (как оказалось) Google - не единственный сканер: smile:

Самый большой выигрыш от этого - для сайтов, которые хотят предложить лучшую поддержку тегов Facebook OpenGraph, карточек Twitter и поисковых систем, не относящихся к Google.

Спасибо @mbleigh , это проясняет ситуацию и заставляет меня думать, что мы действительно хотим этой поддержки или какой-то альтернативы, как сказал @drtriumph в своем комментарии.

Я искал решение и нашел следующие детали, которые могут пригодиться другим читателям:

  • В октябре 2015 года Google отказался от рекомендации использовать _escaped_fragment_ и хэшбанг (! #). Итак, для Google каждый SPA должен использовать html5 pushstate (html5mode в angularjs). Но они продолжат поддерживать hashbang (! #) И какое-то время переводить его в экранированный фрагмент.
  • Facebook и, возможно, другим сканерам по-прежнему нужен escaped_fragment, автоматический перевод хэшбэга Facebook в нотацию _escaped_fragment. И, вероятно, другие сканеры поступают так же, поскольку это была предыдущая рекомендация от Google.
  • Поскольку Firebase еще не поддерживает перенаправления на основе User-Agent, мы надеемся, что сканеры будут переводить hasbangs (! #) В escape_fragament следующим образом:
    Если ваши URL-адреса выглядят так:
    http://www.example.com/#!/user/1
    Затем получите доступ к своим URL-адресам следующим образом:
    http://www.example.com/?_escaped_fragment_=/user/1

Итак, пока одна идея выяснить это может быть такой:

  • Не используйте html5 pushstate (режим html5 в Angular) и используйте вместо него hashbang (! #)
  • Используйте prerender.io для создания статической / кэшированной версии каждой страницы, которую вы хотите в своем приложении (как обычный процесс предварительной визуализации).
  • Разработайте плагин, который хранит эту кешированную версию в структуре папок, которая начинается с папки ?_escaped_fragment_= и создает такие папки, как:
    Если ваши URL-адреса выглядят так:
    http://www.example.com/#!/user/1
    Созданная папка будет
    ?_escaped_fragment_= +- /user +- /1

Где 1 файл будет фактическим файлом html.

  • Разверните эту папку в корневой папке firebase с помощью инструментов firebase (этот процесс можно автоматизировать с помощью задания cron или чего-то подобного).

Как я думаю это будет работать:

  • Когда сканер увидит ваш URL-адрес хэшбэга, он попытается достичь URL-адреса ?_escaped_fragment_= . Поскольку в этих папках есть настоящие HTML-файлы, Firebase будет обслуживать их, а не перенаправлять на index.html, поэтому HTML, прочитанный сканером, будет кэшированной версией, а не AngularJS.

Для этого нам нужно создать запланированное задание, которое запускает предварительную визуализацию для каждой страницы, сохраняет эту папку и выполняет развертывание firebase.

Поскольку развертывание firebase не поддерживает частичное развертывание (синхронное или инкрементное), мы должны поддерживать обновленную копию нашего развертывания на сервере, который будет отвечать за этот процесс.

Я попробую настроить это и сообщу вам, сработает ли это.

Не могли бы вы разрешить нам установить «X-Prerender-Token», как мы делаем другие ключи заголовка ???
https://www.firebase.com/docs/hosting/guide/full-config.html
https://prerender.io/install-token

+1

@ srk9, пожалуйста, отправьте отдельную проблему, а не перепрофилируйте эту ветку.

Почему этот вопрос закрыт? Я не вижу опубликованного решения.

@douglascorrea , что случилось с твоей идеей?

Благодаря,
- D

Привет, @bethuneco , извини, что не опубликовал здесь результат.

На самом деле я собирался написать статью, но потом я понял, что это решение будет состоять из множества «механизмов», которые заставят его работать в производственной среде, и я не чувствовал себя удобным «рекомендовать» его, поскольку не знаю, как это будет поведение в большом масштабе.

Но в основном, как я описывал ранее, мне нужен сервер «развертывания / предварительной визуализации», который для каждого развертывания выполняет предварительную визуализацию / отбрасывание всех страниц и сохраняет полученный HTML в папках, описанных выше (/? _ Escaped_framgment_ / xxxx). Эти «реальные / физические» HTML-страницы будут нашими «предварительно обработанными» страницами.

Таким образом, каждый раз, когда сканер google / facebook / twitter переходит на нашу страницу и запрашивает «экранированный фрагмент» с помощью префикса «? _Escaped_fragment», он фактически указывает на реальную папку с реальными HTML-кодами, тогда этот HTML-код будет проиндексирован.
Когда реальный пользователь переходит в приложение, он не будет использовать? _Escaped_fragment, поэтому он получит динамическую страницу.

Проблема в том, что это «решение» состоит в том, что нам нужно продолжать генерировать HTML-коды для каждой или дополнительной страницы. Например, если ваше приложение представляет собой простую CMS, для каждой новой публикации / статьи / страницы вам нужно будет запускать процесс создания новой HTML-страницы. Но проблема усугубляется, когда мы говорим, например, о динамической социальной сети, где каждый пользователь может генерировать сотни страниц с предварительным отображением, тогда ваш предварительный поисковый робот / внутренний поисковый робот должен работать все время. И это в реальном мире может стать препятствием.

Это очень "хитрое" решение, которое может работать для небольших приложений, но не для действительно больших, потому что мы на самом деле генерируем HTML-коды, которые будут там, когда сканеры работают, а не автоматически перенаправляют их в нашу службу предварительной визуализации, которая будет выполнять предварительную визуализацию в Интернете (как нормальный процесс предварительной визуализации).

Итак, к настоящему моменту мы должны использовать сервер Nginx в качестве статического сервера, чтобы иметь возможность выполнять предварительную визуализацию, или использовать конкурента Divshot, например https://www.netlify.com/, который предоставляет Prerender для одностраничных приложений. .

@douglascorrea ,

Спасибо за развернутое объяснение. Вы первый, кто упомянул Netlify, поэтому я займусь этим.

Вы правы, что предварительная отрисовка всего подходит только для небольших сайтов. К счастью, мое приложение довольно маленькое (максимум около 1200 страниц), так что оно может работать.

Самым простым решением (которого избегает Google) является предварительная визуализация Javascript и предоставление HTML при обнаружении пользовательских агентов роботов. Google уже продемонстрировал рендеринг вне браузера, так что технически это несложно. Для них это стратегически сложно, потому что кажется, что это помогает конкурентам в рекламном бизнесе.

Если что-то заработает, я опубликую здесь обновление.

Позвольте мне внести некоторую ясность здесь для тех, кто может быть сбит с толку:

Поддерживает ли хостинг Firebase предварительную отрисовку JS на сервере? Нет, это не так. Предварительная рендеринг на стороне сервера - это то, что мы хотели бы поддержать, и это входит в нашу долгосрочную дорожную карту, но у нас нет конкретных дат или сроков для объявления в настоящее время. Мы знаем, что это болезненная точка, особенно для тех, кто использует совместное использование Facebook или Twitter-карты, и мы надеемся, что сможем рассказать об этом больше в будущем.

Разве вы не можете просто поддержать, например, X-Prerender-Token ? Нет, это не сработает. Предварительная отрисовка должна обслуживать _фактический предварительно отрисованный контент_ по URL ?_escaped_fragment_= , что означает, что это не только заголовок, но и контент, о котором сервер должен знать и правильно обрабатывать. Нет такого полумерного решения, как хотелось бы.

Какой возможен предварительный рендеринг? Единственный вид настоящего «предварительного рендеринга», который вы можете сделать на данный момент, - это компиляция статического сайта. Обычно это делается с помощью чего-то вроде Jekyll, но, безусловно, можно использовать локальный браузер без головы для «предварительной визуализации» более динамичного сайта. Вы должны полностью отобразить каждый URL-адрес, а затем развернуть его, так что на данный момент это не лучший вариант использования. Также обратите внимание, что создание имен файлов с ?_escaped_fragment_ в них _не_ возможно, поскольку CDN удаляет параметры запроса, и это обычно не поддерживается.

Является ли это своего рода стратегической мерой Google, направленной на подавление других поисковых роботов? Нет, абсолютно нет. Мы очень хотим поддержать преимущества, которые дает предварительная отрисовка на Firebase Hosting. Это всего лишь вопрос времени и ресурсов.

Мне пришлось отказаться от хостинга firebase из-за проблем с тегами социальных сетей / альтернативной SEO. Когда нетехнические люди замечают, что у нас нет хороших картинок на наших ссылках, как у всех в Интернете, это нарушает условия сделки.

Вы можете выполнить предварительную визуализацию с помощью промежуточного программного обеспечения phantomjs и prerender. Он с открытым исходным кодом и работает нормально, но я выбрал prerender.io, чтобы избежать работы с операционными системами. Это немного медленно при первом запросе, но вы можете кэшировать страницы, предварительно запрашивая каждую страницу.

Также приятно запросить все страницы, потому что тогда вы можете запустить на нем несколько тестов, проанализировать html, чтобы убедиться, что теги и контент отображаются правильно.

Есть огромное предостережение. Prerender не работает с живыми данными Firebase. Как это могло быть? Данные Firebase в реальном времени, соединение постоянное. Пререндер разовый, подключение закрытое. Невозможно определить, когда страница завершена, потому что вы не можете подсчитывать запросы.

У меня было несколько идей, как это исправить:

  1. Делайте GET-запрос с каждой подпиской .on("value") firebase. Пропустите подписку, если это предварительный запрос. Пропустите запрос GET, если это обычный пользователь. Это не сработает для событий .on("child_*") .
  2. Установите глобальный флаг предварительной визуализации на false в верхней части вашего основного файла записи, затем для каждого компонента страницы установите флаг на true после загрузки данных. При правильном проектировании обычно есть _состояние загрузки_, _состояние_ошибки_ и _состояние_успеха_, поэтому в вспомогательном методе состояния ошибки / успеха установите флаг в true .

Это неприятно, но только несколько динамических страниц отображаются некорректно и требуют особой обработки. Я по-прежнему считаю, что статические преимущества перевешивают затраты.

@mbleigh с нетерпением жду того, что вы придумаете в будущем. Я уверен, что присоединение к Google - это один шаг назад, два шага вперед.

Очень надеюсь на какое-то обходное решение. Единственная причина, по которой мне нужен бэкэнд, - это также карточки твиттера и opengraphs. Конечно, бэкэнд дает некоторые другие преимущества для одностраничных приложений, такие как изоморфный рендеринг, но это просто приятно иметь. Теги Twitter и OG важны для любого приложения, которым нужно поделиться.

Может ли быть какое-то правило, похожее на перезапись, которое заставляло бы серверную часть firebase обслуживать тот или иной объект / html из базы данных?

Такой объект можно было бы подготовить заранее, поскольку каждый обмен начинается с посещения URL-адреса или передачи кнопки «Поделиться».

удар .. Я был просто поражен Firebase, а потом понял, что не могу его использовать, прочитав эти комментарии ..
Поскольку мне также нужен сервис, похожий на Prerender, для работы. Так что там с развитием ??

Собери вместе, Google! Вы бесплатная поисковая машина !! :смеющийся:

Если серьезно. Это чертовски важно. Это может быть самая проклятая и самая важная вещь на свете.

Я знаю, что это было в шутку, но, чтобы уточнить, будет ли это замечание направлено на поиск Google или на Google Firebase? Только одна из них является поисковой системой, и только одна из них обеспечивает хостинг Firebase (и предварительная компиляция веб-страниц не совсем входит в компетенцию ни того, ни другого, хотя явное добавление ценности для хостинга для лучшей работы с инструментами, которые это предоставляют).

Кстати, это тоже не связано с инструментами firebase (то есть с этой системой отслеживания проблем OSS). Я позабочусь о том, чтобы ваш голос был добавлен в обсуждение приоритетов; список рассылки, вероятно, лучшее место для обращения с ключевыми запросами функций в будущем.

Самое главное, что мы этого не забыли. Для нас это по-прежнему очень важно. Немного менее важно, чем интеграция с Google Cloud Functions и предоставление надежной информации с помощью аналитики, отчетов о сбоях и тестовых лабораторий, но все же важно.

Я подниму этот вопрос еще раз, когда мы в следующий раз обсудим приоритеты. Мы очень признательны за то, что вы добавили свой голос в отзыв. ☼☼☼

спасибо за ваши усилия по firebase @katowulf !!
Это единственное, что мешает мне использовать firebase в качестве «хоста» для моих приложений ng1.

Вы здесь не одиноки. Другие столкнулись с тем же ограничением. Обратите внимание, что, поскольку Google теперь может индексировать контент, созданный с помощью JavaScript, и существуют некоторые специальные положения для индексации контента Firebase, неаутентифицированные данные Firebase, загруженные на ваши страницы, уже должны индексироваться. Но полная поддержка прекомпилятора не за горами.

@katowulf точно так же, как и хедз-ап (если вы этого еще не знали или не видели), но главная проблема не в поисковике Google. Я думаю, люди уже знают об этом, если они используют что-то вроде Prerender. Это другие сканеры, например LinkedIn, Facebook, Twitter и другие, не удовлетворены. Им нужен статический контент

@samvloeberghs Однако я думаю, что последствия предоставления этой поддержки Google заключаются в том, что другие, вероятно, последуют его примеру. Таким образом, я намеревался намекнуть, что это шаг в правильном направлении к широкому распространению (и что он по крайней мере работает с Google сегодня).

Маловероятно, что FB / LinkedIn / Twitter последуют за способностью Google двигаться вперед так быстро, как нам хотелось бы. За спиной всегда будет крупный игрок, и мы просто не можем игнорировать его. С другой стороны, Google решает проблему, работая над NG2, в котором будет реализована компиляция на стороне сервера с использованием Angular Universal :) 👍

На помощь приходит Angular! Подождите, вы говорите, что машинное обучение не решит все это?

Предлагая свои 2 цента, я обнаружил, что клиенты, похоже, ценят карты социальных сетей не меньше, чем SEO. Судя по недавним проектам, Twitter / Facebook были основным способом продвижения брендов посредством обмена ссылками на свои веб-сайты.

Очевидно, что SEO по-прежнему имеет решающее значение, но будет ли атака на карты социальных сетей более простым / краткосрочным решением? Поскольку веб-карты - это просто метатеги, не могли бы вы определить структуру в firebase.json (аналогично правилам безопасности)? Затем Firebase может внедрить нужные метатеги для поисковых роботов twitter / facebook, хотя я уверен, что это не так просто 😄.

Тем не менее, большое спасибо за отличную работу и поддержку сообщества. С нетерпением жду некоторых из наиболее интересных функций Firebase (облачные функции 👍!).

@katowulf , мой комментарий был более сильным, чем что-либо другое ... вы, ребята, делаете потрясающую работу! Я больше направляю свою шутку на Google в целом. Однако я верю, что Firebase - это новое * подразделение Google, которому должна принадлежать вся эта проблема «SPA / PWA - рендеринг страниц SEO».

Мои мысли по этому поводу ...

Какие бы продукты Google ни выпускал в мир, они должны безупречно работать со всеми платформами, которые мы используем сегодня, и быть яркими примерами, которые работают и отражают его оригинальный продукт, Google Search.

SPA существуют уже некоторое время ... В Google есть 2 из них [Angular] и [Polymer]. Внедрение в них SEO (мета-теги / OpenGraph / Schema) является важным черным ящиком (если вы не бэкэнд-ниндзя). То, что Google Search начал обрабатывать JS, было отличной новостью, но это определенно только половина дела (а может, и меньше).

Firebase, будучи серверной частью как сервисом (BaaS), кажется идеальной новой * группой Google, чтобы действительно сгладить рендеринг всей этой страницы SPA. Я знаю, что вы, ребята, справитесь с этим, но я твердо уверен, что это должна быть критически важная функция.

Представьте, что вы читаете этот заголовок ...

ПРЕДСТАВЛЕНИЯ ПОЖАРНОЙ БАЗЫ ...
Новое и улучшенное SEO для всех одностраничных приложений (SPA) и прогрессивных веб-приложений (PWA) прямо из коробки!

Собирались бы разработчики: +1:

Просто хотел быстро сказать, что это определенно есть на нашем радаре. Это важно, как и многие другие вещи (как перечислила Като). У нас есть несколько идей о некоторых отличных способах решения этой проблемы, но у них есть некоторые зависимости, которые мы должны сначала устранить. Постарайтесь сохранять терпение и знайте, что это определенно у нас на уме!

Что ж, это разочаровывает. Теперь я ищу альтернативы firebase ...

Прошло почти 3 года ...

какие-нибудь обновления по этому поводу ..?

Разве это не должно работать сейчас, когда firebase владеет divshot? обновите PLZ!

Нам хорошо известно о стремлении к такой функциональности, и для нас приоритетом является предоставление здесь лучших решений. Я все еще не могу объявить какой-либо график, но мы не забыли о вас, ребята.

+1

:( :( :(

Мы пришли к аналогичному выводу. Что еще вы видели? ;)

Я просто использую функции Firebase в качестве конечной точки ссылки для общего доступа, а затем перенаправляю с помощью JavaScript ссылку.

Возможно, вы этого не видели, но теперь облачные функции интегрированы с хостингом Firebase !!!

Это можно считать нашим каноническим решением для рендеринга на стороне сервера с помощью Firebase Hosting. Наслаждайтесь!

@mbleigh Хорошо, поэтому, если у меня есть глобальный файл заголовка с метаданными, такими как ниже, в настоящее время он не реплицируется во внешнем интерфейсе. Если я установлю облачные функции, это будет все, что мне нужно для включения этой функции.

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

Отлично, спасибо за обновление.

17 мая 2017 г. в 17:39 «Майкл Блей» [email protected] написал:

Возможно, вы этого не видели, но теперь интегрированы облачные функции.
с хостингом Firebase https://firebase.google.com/docs/hosting/functions
!!!

Это можно считать нашим каноническим решением для рендеринга на стороне сервера.
с хостингом Firebase. Наслаждайтесь!

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-302268864 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbtWCdygdw4ozixK5_XcL2Dlznp4Jks5r65M-gaJpZM4CtPYG
.

Я понимаю, что это может быть не лучшая проблема для этих комментариев, но поиск моих проблем в Google привел меня к этому, и, похоже, идет активное обсуждение, поэтому, пожалуйста, простите меня!

Что я хотел бы увидеть для решения проблемы рендеринга шаблонов открытых графов для социальных сайтов в SPA, размещенных на firebase, - это возможность балансировки нагрузки через пользовательский агент.

Я хотел бы иметь возможность использовать облачные функции для извлечения некоторых данных шаблона из memcache / cloudsql и рендеринга тегов шаблонов на запрашивающую социальную платформу, но вернуться к статическому хостингу для всех других клиентов. Тогда нам не потребуется полноценный рендеринг на стороне сервера для всех запросов.

@cdharris В общем , банкомат, переписывающий весь запрос на функцию, которую я пытался использовать window.location, чтобы сделать дополнительное перенаправление (для клиента / посетителя) на статический хостинг, для моих целей SEO это не сработало, возможно для социальных целей это было бы.

@mbleigh есть ли возможность переписать запрос от поисковых роботов / соцсетей,

Принятие решения о том, что возвращать в функции firebase, может работать. Мы можем сказать: req исходит от Facebot? Затем верните эти теги открытого графика. Если нет, верните index.html. Но как мне вернуть проклятый index.html из функции firebase?

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

13 сентября 2017 г. в 4:34 "Бировски" [email protected] написал:

Принятие решения о содержании в функции firebase может работать. Мы можем сказать:
запрос поступает от Facebot? Затем верните эти теги открытого графика. Если не,
верните index.html. Но как мне вернуть проклятый index.html из
функция firebase?

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329140134 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbrXQNbVMhRmeZQTbx3Z3vi0c1HXTks5sh728gaJpZM4CtPYG
.

@megamindbrian подразумевается, что функции имеют доступ к размещенным файлам? Это где-нибудь задокументировано? В любом случае спасибо!

Да. Вот как я его использовал, хороший вопрос, пытаюсь найти документы.

13 сентября 2017 г. в 7:09 «Бировски» [email protected] написал:

@megamindbrian https://github.com/megamindbrian подразумевается, что
у функций есть доступ к размещенным файлам? Это где-нибудь задокументировано?
В любом случае, спасибо!

-
Вы получаете это, потому что вас упомянули.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

Здесь один
https://stackoverflow.com/questions/42960506/how-can-i-read-and-write-to-firebase-storage-from-within-cloud-functions-for-fir

13 сентября 2017 г. в 7:09 «Бировски» [email protected] написал:

@megamindbrian https://github.com/megamindbrian подразумевается, что
у функций есть доступ к размещенным файлам? Это где-нибудь задокументировано?
В любом случае, спасибо!

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

Здесь используется временный каталог, но я думаю, он также работает с файлами.
вы загрузили вместе со своим проектом. Это может быть неизменным, поэтому
пример выгружает файл, чтобы сохранить его в другом месте
https://firebase.google.com/docs/storage/extend-with-functions

13 сентября 2017 г., 7:12, «Брайан Каллинан» [email protected] написал:

Вот один https://stackoverflow.com/questions/42960506/how-can-i-
чтение-и-запись-в-firebase-хранилище-из-внутри-облачных-функций-для-пихты

13 сентября 2017 г. в 7:09 «Бировски» [email protected] написал:

@megamindbrian https://github.com/megamindbrian подразумевается, что
у функций есть доступ к размещенным файлам? Это где-нибудь задокументировано?
В любом случае, спасибо!

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329179741 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbobjixHUterg61PAFmLc9v72C7kyks5sh-IogaJpZM4CtPYG
.

Извините, я до сих пор не вижу должного представления о том, как функции концептуально связаны с размещенными файлами. Если вы хотите объяснить, у меня есть для вас несколько очков: https://stackoverflow.com/q/46192570/592641

Я мог представить, как отвечаю на это примерами кода, но это было непонятно
что изнутри вашей функции вы можете ответить контентом из файла в
ваш проект? Это не перенаправление.
Я откопаю еще код.

13 сентября 2017 г. в 7:18 «Бировски» [email protected] написал:

Извините, я до сих пор не вижу должного представления о том, как работают функции
концептуально связаны с размещенными файлами. Если вы хотите объяснить, я получил
несколько очков для вас: https://stackoverflow.com/q/46192570/592641

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329182385 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbnCSoaKUuVKUnfha5A-4K-p76kZ3ks5sh-QygaJpZM4CtPYG
.

@megamindbrian Я только что попробовал fs.readFileSync('./index.html') но, к сожалению, файла там нет. Я также надеялся найти размещенные файлы в некотором неявно созданном ведре хранилища, но безуспешно. Как бы вы поступили?

Если вы вложите каталог Hosting public каталог functions , он будет там доступен.

@Birowsky Ага , вот как я читаю файл из облачной функции, например index.js:

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

Но если макет вашего проекта:

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

Вам нужно будет скопировать соответствующие файлы из / dist в / functions

Этому выпуску уже почти 3 года, и все еще не повезло ????

Вероятно, это означает, что Google откажется от Firebase в процессе поддержки всех
наши приложения.

Наше официальное решение для этого класса проблем - использовать Cloud Functions.
для рендеринга на стороне сервера контента, который должен быть виден статическим
краулеры:

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

Это более надежное и универсальное решение, которое позволяет использовать все виды
классные штучки!

Если вы уверены, что чего-то еще не хватает, сообщите нам
подробный пример использования, чтобы мы могли подумать, как с ним справиться! :)

В чт, 14 сентября 2017 г., 15:57 Брайан Каллинан [email protected]
написал:

Вероятно, это означает, что Google отказался от firebase в процессе поддержки всех
наши приложения.

14 сентября 2017 г., в 15:52, tofanelli [email protected]
написал:

Этому выпуску уже почти 3 года, и все еще не повезло ????

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
<
https://github.com/firebase/firebase-tools/issues/33#issuecomment -329630338
,
или отключить поток
<
https://github.com/notifications/unsubscribe-auth/AX5XbhBSDSl6TStSv7M02Dx0brb9MOPbks5sia44gaJpZM4CtPYG

.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329631266 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAD_iI6L-yu3RTECI88a2y_ZOzIxdDQks5sia9rgaJpZM4CtPYG
.

@mbleigh Можете ли вы использовать облачные функции в корне домена firebase?

Да, если я вас правильно понял. Были ли у вас проблемы раньше?

В четверг, 14 сентября 2017 г., 18:38 Брайан Каллинан [email protected]
написал:

@mbleigh https://github.com/mbleigh Можете ли вы использовать облачные функции на
корневой каталог firebase еще нет?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-329653711 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAAD_g7BV3TMM_5nVX92_-3ai_mZHfHBks5sidUvgaJpZM4CtPYG
.

@mbleigh

Это более надежное и универсальное решение, позволяющее создавать самые разные интересные вещи!

SSR делает нашу систему более сложной 😢
Думаю, что пререндеринг круче не всегда, но часто often
например, Facebook OGP, Twitter Cards, SEO для сторонних разработчиков.

@mbleigh @megamindbrian Спасибо за ваши сообщения. Я сделал свой хостинг, направляя все запросы к моей функции и ответ index.html который размещен в functions/build/index.html для клиентов. Но я не знаю, как подтвердить, что запрос исходит от FaceBot? Я пробовал использовать инструменты отладки facebook для доступа к URL-адресу моего веб-сайта, я предполагал, что сработает облачная функция, но этого не произошло. Я не знаком с серверной разработкой, вы можете мне подсказать? Благодарю.

При использовании инструмента Facebook убедитесь, что вы используете кнопку, которая что-то читает
например "Получить новую копию" рядом с превью.

Во вторник, 17 октября 2017 г., в 8:29, Джуд [email protected] написал:

@mbleigh https://github.com/mbleigh @megamindbrian
https://github.com/megamindbrian Спасибо за ваши сообщения. я имею
заставил мой хостинг направлять все запросы на мою функцию и ответ
index.html, который размещен для клиентов в functions / build / index.html. Но
Я не знаю, как подтвердить, что запрос исходит от FaceBot? я пытался
используя инструменты отладки facebook для доступа к URL-адресу моего веб-сайта, я предположил, что
Облачная функция должна была сработать, но этого не произошло. Я не знаком с
back-end разработка, вы можете мне подсказать? Благодарю.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-337266581 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbrCQ3mowcUnJjWYWsaiScoN1y4l0ks5stMfcgaJpZM4CtPYG
.

-
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: содержание этого сообщения электронной почты и любых
вложения предназначены исключительно для адресатов и могут содержать
конфиденциальная и / или привилегированная информация, которая может быть защищена законом
от раскрытия. Затем он передается технологическим компаниям, ботам, хакерам,
государственные учреждения и маркетологи. Безопасность этого сообщения нет,
и им можно поделиться в Instagram в любое время. Если вас это устраивает,
пожалуйста ответьте. На самом деле нигде нет никакой безопасности или конфиденциальности. Если
вы не согласны, вы можете пойти в поход и поговорить с людьми лицом к лицу
как в старые времена.

Есть ли что-нибудь в ваших журналах firebase, например «Выполнение функции начато»?

Во вторник, 17 октября 2017 г., в 8:37, Брайан Каллинан, [email protected]
написал:

При использовании инструмента Facebook убедитесь, что вы используете кнопку с надписью
что-то вроде "Получить новую копию" рядом с превью.

Во вторник, 17 октября 2017 г., в 8:29, Джуд [email protected] написал:

@mbleigh https://github.com/mbleigh @megamindbrian
https://github.com/megamindbrian Спасибо за ваши сообщения. я имею
заставил мой хостинг направлять все запросы на мою функцию и ответ
index.html, который размещен для клиентов в functions / build / index.html. Но
Я не знаю, как подтвердить, что запрос исходит от FaceBot? я пытался
используя инструменты отладки facebook для доступа к URL-адресу моего веб-сайта, я предположил, что
Облачная функция должна была сработать, но этого не произошло. Я не знаком с
back-end разработка, вы можете мне подсказать? Благодарю.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-337266581 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbrCQ3mowcUnJjWYWsaiScoN1y4l0ks5stMfcgaJpZM4CtPYG
.

-
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: содержание этого сообщения электронной почты и любых
вложения предназначены исключительно для адресатов и могут содержать
конфиденциальная и / или привилегированная информация, которая может быть защищена законом
от раскрытия. Затем он передается технологическим компаниям, ботам, хакерам,
государственные учреждения и маркетологи. Безопасность этого сообщения нет,
и им можно поделиться в Instagram в любое время. Если вас это устраивает,
пожалуйста ответьте. На самом деле нигде нет никакой безопасности или конфиденциальности. Если
вы не согласны, вы можете пойти в поход и поговорить с людьми лицом к лицу
как в старые времена.

-
УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: содержание этого сообщения электронной почты и любых
вложения предназначены исключительно для адресатов и могут содержать
конфиденциальная и / или привилегированная информация, которая может быть защищена законом
от раскрытия. Затем он передается технологическим компаниям, ботам, хакерам,
государственные учреждения и маркетологи. Безопасность этого сообщения нет,
и им можно поделиться в Instagram в любое время. Если вас это устраивает,
пожалуйста ответьте. На самом деле нигде нет никакой безопасности или конфиденциальности. Если
вы не согласны, вы можете пойти в поход и поговорить с людьми лицом к лицу
как в старые времена.

@megamindbrian Функция срабатывала, если я

@judewang взгляните на https://firebase.google.com/docs/hosting/functions#when_is_cached_content_served

Для быстрого и грубого теста вы можете попробовать добавить какой-нибудь случайный параметр запроса к проверяемому URL-адресу.

Итак, первоначальный вопрос заключался в том, как использовать пререндер. Это решение не решает проблему интеграции с предварительной визуализацией, но решает проблему открытого графа для одностраничного приложения.

  1. В моем сценарии сборки я копирую public/index.html в functions/hosting/index.html
  2. В firebase.json я добавляю правило перезаписи, чтобы указать на облачную функцию, называемую "хост".
"hosting": {
    "public": "dist",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "**",
        "function": "host"
      }
    ]
  }
  1. Я определяю облачную функцию с именем host . В большинстве случаев это просто возвращает файл index.html который я скопировал в functions/hosting/index.html , но если агент является одним из известных анализаторов открытого графа, я возвращаю данные базы данных в формате открытого графа на основе маршрут.
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());
  }
});

Думаю, все. Надеюсь, это поможет некоторым людям!

Я должен сказать, что это разочаровывает, у новых конкурентов это есть, например, https://www.netlify.com/features/ , что определенно делает его более привлекательным для веб-приложений, которым требуется интеграция с SEO / социальными сетями.

Firebase убивает его для мобильных / нативных приложений, и я действительно наслаждаюсь им как платформой в целом, но это довольно большой недостаток для веб-приложений IMO.

В общем, мы обнаружили, что контент, которому требуется предварительная отрисовка, также является контентом, который лучше всего обслуживается рендерингом на стороне сервера (по причинам производительности и первой загрузки). По этой причине общий предварительный рендеринг не входит в нашу ближайшую дорожную карту.

При этом мы прислушиваемся к отзывам о желании, чтобы интеграция функций была более гибкой, чтобы можно было «иногда» выполнять функции. Поскольку хостинг Firebase в значительной степени полагается на кэширование CDN, нам технически сложно достичь такой гибкости. Мы продолжим прислушиваться к отзывам и постараемся найти способы улучшить платформу для вашего варианта использования. :улыбка:

Пользовательский интерфейс в Firebase для подключения функций напрямую к домену
имя исправит мой вариант использования.

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

Пт, 5 января 2018 г., в 15:33, Майкл Блей [email protected]
написал:

В целом мы обнаружили, что контент, который требует предварительной визуализации, также
контент, который лучше всего обслуживается рендерингом на стороне сервера (для производительности и
причины первой загрузки). Общая предварительная отрисовка не входит в нашу ближайшую дорожную карту
по этой причине.

При этом мы прислушиваемся к отзывам о желании
интеграция функций должна быть более гибкой, чтобы позволить «иногда» функционировать
исполнение. Поскольку хостинг Firebase в значительной степени полагается на кеширование CDN такого типа
гибкости нам технически сложно достичь. Мы продолжим
чтобы выслушать отзывы и попытаться найти способы улучшить платформу для
ваш вариант использования. 😄

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/33#issuecomment-355683821 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AX5XbtVDQSPOIAZFyozujQQUektf2WM1ks5tHqM8gaJpZM4CtPYG
.

-
"Я изучал инженерное дело"

УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: содержание этого сообщения электронной почты и любых
вложения предназначены исключительно для адресатов и могут содержать
конфиденциальная и / или привилегированная информация, которая может быть защищена законом
от раскрытия. Затем он передается технологическим компаниям, ботам, хакерам,
государственные учреждения и маркетологи. Безопасность этого сообщения нет,
и им можно поделиться в Instagram в любое время. Если вас это устраивает,
пожалуйста ответьте. На самом деле нигде нет никакой безопасности или конфиденциальности. Если
вы не согласны, вы можете пойти в поход и поговорить с людьми лицом к лицу
как в старые времена.

@mbleigh , разве эта точка зрения не противоречит духу бессерверного использования и использования поставщика BaaS / FaaS, такого как firebase? Учитывая тенденцию к использованию SPA за последние несколько лет, это довольно распространенный вариант использования, настолько большой, что его начали решать конкуренты, например, netlify и roast. Хотя они меньше по размеру, для хостинга это имеет смысл, поскольку обеспечивает более быстрое время загрузки, а также критическую возможность обнаружения и совместного использования.

Вместо того, чтобы добавлять дополнительные затраты на разработку и обслуживание для клиентов, дополнительную услугу предварительной обработки или, по крайней мере, возможность интеграции со сторонней службой, такой как prerender.io, будет значительным улучшением.

Firebase - действительно отличная платформа, но, похоже, она более ориентирована на мобильные устройства, и единственной ее слабой частью для меня является хостинг.

Спасибо за быстрый ответ.

@mbleigh

В общем, мы обнаружили, что контент, которому требуется предварительная отрисовка, также является контентом, который лучше всего обслуживается рендерингом на стороне сервера (по причинам производительности и первой загрузки).

Помимо точного аргумента

Одностраничные приложения или разделы приложений должны прибегать к некоторой степени рендеринга на стороне клиента, и, к сожалению, сканеры, в том числе собственные поисковые системы Google, пока не очень хороши в индексировании таких страниц. Мне пришлось прибегнуть к PrerenderIO после нескольких месяцев неудачных попыток позволить Google правильно проиндексировать мои веб-сайты, что вынудило меня придерживаться подхода на основе сервера express.js, __ только из-за проблемы с индексированием__.

Подумайте о веб-сайте, на котором есть страница /product/**.html, отображающая ЛЮБОЙ продукт в зависимости от обнаруженного клиентской стороной глубокого URL. Обоснование этого дизайна заключается в том, что загрузка фактической отдельной страницы для продукта, даже с учетом кеширования браузера и cdn, не так гладко с точки зрения UX, как загрузка данных другого продукта и их рендеринг при изменении URL-адреса. Клиенты проводят большую часть своего времени на страницах продуктов, когда просматривают страницу с целью покупки, находясь на веб-сайте электронной коммерции, и часто переходят к другим продуктам через ссылки «похожие продукты» или ссылки для поиска на странице с помощью ajax.

Мы застряли в абсурдном (ИМХО) механизме _escaped_fragment_, чтобы нас не наказали за маскировку ... трудно ли Google нанять инженеров с изящными решениями этой вездесущей проблемы ??

Я нахожу даже полное отсутствие раздела индексации веб-сайта / веб-приложения в документации __unjustifiable__.
Мобильные приложения могут доминировать на потребительском рынке, но как насчет B2B? Большинство офисных отделов работают на настольных компьютерах. Индексирование веб-сайтов для настольных компьютеров для доступа к отделам исследований и разработок или отделам закупок - это не «хорошо», это критически важно для предприятий поставщиков B2B.

Если Firebase / Google не заинтересованы в этом, потому что яркие приложения, работающие на блестящих гаджетах, приносят больше дохода, было бы неплохо узнать об этом; Четыре года уклончивых ответов лояльным приверженцам технологий оскорбительны для любого интеллекта.

Рэнти? Да, но мне приходится оправдывать дополнительные затраты на инфраструктуру, дополнительное время на разработку и неожиданное поведение сканеров для моих клиентов.

четыре года, когда этот вопрос остается открытым, действительно кажутся немного глупыми. @cleverplatypus - не могу больше согласиться с вашими чувствами.

В целом, мы не перестали думать об этой проблемной области, но у нас все еще нет никаких непосредственных планов по предварительной визуализации ускользнувших фрагментов.

Я понимаю, что есть моменты, когда статическое одностраничное приложение может выиграть от предварительной отрисовки; однако я по-прежнему считаю, что в большинстве (но не во всех) случаях сайты этих типов лучше обслуживаются рендерингом на стороне сервера, который может загружать SPA с любого URL-адреса.

Наша цель - сделать Firebase Hosting фантастической платформой для предоставления всевозможных веб-приложений. Хотя я ценю откровенные и страстные отзывы, представленные в этой ветке, у нас действительно ограниченные ресурсы, и мы должны расставлять приоритеты в работе, которая, по нашему мнению, окажет наибольшее влияние на нашу клиентскую базу в целом. Если вы хотите помочь изменить наше мнение о приоритезации функции, которая вас сильно волнует, лучший способ - это подать запрос на

Я собираюсь закрыть эту ветку, так как не думаю, что для разговора действительно есть куда идти, но я бы посоветовал всем, кто не очень хорошо обслуживается нашей интеграцией облачных функций, подать запрос функции для предварительной визуализации, чтобы мы сразу видим, насколько велик спрос!

Спасибо за использование хостинга Firebase, всем 😸

Была ли эта страница полезной?
0 / 5 - 0 рейтинги