Firebase-tools: 関数領域がデフォルトでない場合、ホスティングは関数を実行しません

また、レポの例https://github.com/istarkov/firebase-hosting-error

こんにちは、これは予想される動作です。https： //firebase.google.com/docs/functions/locations#http_and_client_callable_functionsをご覧ください。青いボックスは、ホスティングリダイレクトとして機能するすべての関数が「us-central1」にある必要があることを示しています。これはそれがホスティングの起源であるという事実のためです。

ありがとう、この予想される動作が近い将来、または少なくとも将来変更される可能性はありますか？

こんにちは、それは将来変更されますが、近い将来には変更されません。 これは、FirebaseHostingが他の地域でいつ開始されるかによって異なります。

こんにちは、
私の問題はこれと非常に似ていますが、外部ネットワークを使用するため、私の機能はEUにあるはずです。このように、遅延ははるかに優れています（2〜4秒対4〜600ミリ秒）実行時間
私の問題を次のように説明しました：
https://github.com/firebase/firebase-js-sdk/issues/1101
それで、現時点で他の地域への書き換えを使用する解決策はまだありませんか？
（EU機能に到達するために直接リンクを使用する回避策がありますが、開発側からは理想的ではありません。テストするには、すべてを再デプロイする必要があります）

これが実装されるのを見たいです。 私の訪問者はヨーロッパから来ており、 us-central1からのTTFBはeurope-west1より少なくとも3倍大きいです。

こんにちは、それは将来変更されますが、近い将来には変更されません。 これは、FirebaseHostingが他の地域でいつ開始されるかによって異なります。

こんにちは@laurenzlong 、

それは、ホスティングがus-central1の他の場所で利用可能になる場合、次の制限を回避することもできるということですか？
ドキュメントから Important: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1.

私のアプリケーションにはその機能が必要です。 だから、早いほど良い:)！

どうもありがとうございました。

これが修正されるまで、太字の警告を書き込む必要があります。 何が起こるか気付くまで、私はあまりにも多くの時間を費やしてきました。
少なくともregionオプションを書き換えに追加して、ヨーロッパにリダイレクトできるようにします。

Firebaseのクラウド機能がcloud run設定のように$ regionオプションをサポートすることを願っています。 tokyoリージョンを使用しています。 us-central1からはかなり遠いです。

それは、ホスティングがus-central1の他の場所で利用可能になる場合、次の制限を回避することもできるということですか？
ドキュメントからImportant: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1.

こんにちは@laurenzlong 、

何か（良い）はありますか？ これについてのニュース？

@wangchouが言ったように、クラウドランが代替手段になることに同意しますが、それはサービス/テクノロジーのスタックを追加します。

すぐにお読みいただければ幸いです。 ありがとう！

これについてはまだ調査中ですが、現在、オリジンインフラストラクチャはus-centralに集中しています。つまり、他のリージョンで関数プロキシを許可すると、ほとんどの場合、余分なレイテンシが発生します。 例えば：

tokyo -> CDN edge -> origin (us-central) -> function (tokyo)

これは、往復時間が実際には2倍のようなことをすることを意味します。

元のインフラストラクチャの場所を拡張することを調査していますが、それまでは、この機能を追加することは、利益よりも害を及ぼす可能性が高いため、慎重に行っています。

@ mbleigh-ホスティングの起点が米国外にある場合の見積もりを教えてください。

Firebase環境全体は素晴らしいですが、これに切り替える前によく考えさせられます。 ありがとう

この問題が解決されていないのに、なぜこの問題が解決されたのか、+ 1を上げて本当にわかりません。

次に、Firebaseはすばらしいですが、ヨーロッパのユーザーにとってはこれが大きな注意点です。

申し訳ありませんが、タイムラインは変更される可能性が少し高いため、コメントできません。 これを機能としてサポートするための継続的な声に感謝します。これは、製品を計画および構築するときに間違いなく考慮に入れるものです。

これに関連する可能性のある問題がありますが、これを完全には理解していないため、わかりません。 よく知っていて時間のある人がそれについてコメントしたい場合は、この質問を参照してください。

https://stackoverflow.com/questions/57367131/403-from-deployed-firebase-function

これがあれば素晴らしいことです。ヨーロッパ西部にすでに存在する関数にホスティングリライトを追加することができます1。

確かに素晴らしいでしょう。 今のところ、 @ hgghyxoが述べたようにリダイレクトも使用します。

関数名api
リージョンeurope-west1

firebase.json

"redirects": {
    {
          "source": "/api/endpoint",
          "destination": "https://europe-west1-project-id.cloudfunctions.net/api/endpoint",
          "type": 301
    },
    ...
}

@mcoevertは2019年8月19日午前10時36分GMT + 2にコメントしました：

確かに素晴らしいでしょう。 今のところ、 @ hgghyxoが述べたようにリダイレクトも使用します。

ただし、リダイレクトはCORSの問題を解決しません。

ヨーロッパ地域のサポートも見たいです。

europe-west1リージョン（現在、Cloud Runで利用できる唯一のヨーロッパリージョン）でホストされているCloudRunサービスを使用して書き換えを行うことができるようになりました。 まったく同じではありませんが、かなり近いです。

こんにちは、これは予想される動作です。https： //firebase.google.com/docs/functions/locations#http_and_client_callable_functionsをご覧ください。青いボックスは、ホスティングリダイレクトとして機能するすべての関数が「us-central1」にある必要があることを示しています。これはそれがホスティングの起源であるという事実のためです。

申し訳ありませんが、小さな青いボックスは簡単に見落とされます。 私たちは、この問題が私たちの最終的な構成の問題であると考えて、この問題に多くの時間を費やしてきました。

なぜこれが閉鎖されているのか-それはヨーロッパの私たちにとって問題です。 それが私たちの地域でのみ機能している理由はありますか？

この問題は、FirebaseCLIで直接対処できないFirebaseHostingの機能リクエストであるため解決されました。 機能のリクエストは社内で追跡されます。このフォームから追加のリージョンのサポートをリクエストすることをお勧めします。

フィードバックのおかげで、多くの方がこの機能を望んでいることを確信しています。

この問題は、FirebaseCLIで直接対処できないFirebaseHostingの機能リクエストであるため解決されました。 機能のリクエストは社内で追跡されます。このフォームから追加のリージョンのサポートをリクエストすることをお勧めします。

フィードバックのおかげで、多くの方がこの機能を望んでいることを確信しています。

機能リクエストは内部でのみ追跡されますか？ それは多くの重複したリクエストをもたらしませんか？ 米国以外の地域を含めるために、これらの機能のサポートを示したいと思います。

はい-機能リクエストを送信すると、内部追跡のために他のリクエストと重複排除されます（そして、リクエストに対するサポートが増えることは間違いありません！）。

VPCが必要ない場合は、CloudFunctionの代わりにCloudRunを使用できます。 Cloud Run（完全に管理されている）は現在、VPCネットワークに接続できません。 VPC +カスタムドメイン+ Cloud Functionを使用するためにテストした回避策は、CloudFunctionのプロキシであるカスタムドメインでCloudRunを使用することです。 少しオーバーヘッドが追加されますが、CloudRunとCloudFunctionが同じリージョンにある場合、理論的には、それほど遅延は発生しないはずです。 そうは言っても、私は1か月以上監視してきましたが、Cloud Runベータ版は100％安定していません。

これは、Cloud Runにデプロイして、 https：//github.com/reactgraphqlacademy/cloud-run-proxyを試してみたい場合に使用したプロキシのリポジトリです。

Cloud Functionと同じリージョンでプロキシを使用してCloudflareワーカーをテストし、同じ期間にわたって監視しました。 100％信頼性はありましたが、CloudRunよりも低速でした。

Cloudflareワーカーhttps://gist.github.com/alexlbr/814446f03cf12e22f07ccaa580eb1154をテストする場合は、このコードを使用できます。 @wangchou私が間違っていなければ、東京でCloudflareワーカーを実行できます。その地域では、Cloud Runがまだサポートされていないため、ユーザーがいる場所の端に近づくことができます。

以下は、同じ期間中にプロキシなしでクラウド機能を直接監視します。

監視にはhttps://uptimerobot.comを使用しました。

クラウドランは私には非常に有望に見えます、私は完全なリリースを待つことができません

これに関する更新はありますか？ なぜ閉まっているのですか？

不可能？

@abdellahaski @ l2aelbaここで問題点を確実に聞きます。 @mbleighが以前に言ったように、機能要求としてそれを提出すること（以下を参照）は、これが私たちの内部で牽引力を得るのを助けるための最良の方法です。 ありがとう！

この問題は、FirebaseCLIで直接対処できないFirebaseHostingの機能リクエストであるため解決されました。 機能のリクエストは社内で追跡されます。このフォームから追加のリージョンのサポートをリクエストすることをお勧めします。

フィードバックのおかげで、多くの方がこの機能を望んでいることを確信しています。

asia-east2のサポートも見たいです。

ドキュメントが悪いため、Firebaseをあきらめようとしています。

絶対的な最小値は、usに関数がない場合に警告を発行することです-リダイレクトの関数と中央で一致します！

Firebaseチームは、ユーザーが米国外にいるプロジェクトを誰かに開発させようとすることをお勧めします。 この種の警告が表示されないのはおかしいです。

彼らが尋ねるようにすることによってお互いを助けましょう-機能リクエストを投稿してください：
https://firebase.google.com/support/troubleshooter/report/features

これがあなたがコピー/貼り付けするためのドラフトです-ただそれを成し遂げてください:)

米国以外の地域の関数へのホスティングの書き換え
https://github.com/firebase/firebase-tools/issues/842

US-Central1以外の地域の関数への書き換えを作成できる必要があります。

私たちのターゲットオーディエンスは米国にいません。この機能の欠如は私たちにとって大きな問題であり、私たちの技術スタックをFirebase全体に捧げることができません。

近い将来、この機能を優先することを検討してください。
ありがとう、

すぐにこの機能を期待しています！

クラウド機能の代わりにクラウドランを使用することを研究した人はいますか？

クラウドランは他の地域でも機能を提供します

2年経っても、これはまだ問題です。ところで、なぜこれが閉鎖されているのですか？

こんにちは、これは予想される動作です。https： //firebase.google.com/docs/functions/locations#http_and_client_callable_functionsをご覧ください。青いボックスは、ホスティングリダイレクトとして機能するすべての関数が「us-central1」にある必要があることを示しています。これはそれがホスティングの起源であるという事実のためです。

ページング@laurenzlong

Cloud Functionsは、次の地域で利用できます。

• us-central1（アイオワ）
• us-east1（サウスカロライナ）
• us-east4（バージニア州北部）
• europe-west1（ベルギー）
• europe-west2（ロンドン）
• europe-west3（フランクフルト）
• asia-east2（香港）
• asia-northeast1（東京）

eur3（europe-west）を選択したのは、それがus-central1と一緒にリストの一番上にあり、他の場所から分離されていたためです。 これら2つはデフォルトだと思いました。

私は何をすべきですか、これに何か修正はありますか？

なぜ？？？？？

こんにちは皆さん、これに関するすべてのフィードバックに感謝します。 us-central1以外のFirebaseHostingサポート機能をぜひご覧ください。 残念ながら、それがうまく機能する前に行わなければならないインフラストラクチャの作業がかなりあるため、単に「スイッチを入れて」他の地域をオンラインにすることはできません。

これについては機能のリクエストとして頻繁に耳にします。特定のタイムラインについてコメントすることはできませんが、ロードマップに記載されています。 このリポジトリは、Firebase Hosting製品全体の機能リクエストを投稿するのに適切な場所ではありません。この機能に関心がある場合は、機能リクエストを送信してください。これにより、引き続き社内で関心を追跡し、作業に優先順位を付けることができます。それを有効にするために起こる必要があります。

皆さんありがとう！

こんにちは、

どこでホストするかは誰も気にしないと思います。エラーが表示されないように、簡単な修正が必要です。

この修正はコードで行うことができ、ホスティングを行う場所では何もしません。

そして、これは機能の要求ではなく、バグの削除は機能にはなりません。 そのバグを削除するだけです

ありがとう..