在欧盟使用 Firebase Hosting/Functions 提供动态内容

Question

我想使用 Firebase 托管和函数功能在欧洲提供 Next.js 应用程序。

我从文档中了解到：

If you are using HTTP functions to serve dynamic content for Firebase Hosting, you must use us-central1

还有那个

Firebase Hosting supports Cloud Functions in us-central1 only

很清楚：你必须使用 us-central。但我的主要目标是欧洲..

我已阅读 Cloud Functions 位置指南中的以下内容：

For HTTP and callable functions, we recommend that you first set your function to the destination region, or closest to where most expected customers are located, and then alter your original function to redirect its HTTP request to the new function (they can have the same name). [Solution 1] If clients of your HTTP function support redirects, you can simply change your original function to return an HTTP redirect status (301) along with the URL of your new function. [Solution 2] If your clients do not handle redirects well, you can proxy the request from the original function to the new function by initiating a new request from the original function to the new function. The final step is to ensure that all clients are calling the new function.

我已经强调了似乎是我最初问题的两个解决方案：

解决方案 1

有一个 us-central1 函数发送 301 重定向到 https://europe-west1-[myProject]。cloudfunctions.net/[myEuropeanFunction]
有一个 europe-west1 函数来完成这项工作（在我的例子中，服务于 Next.js 应用程序）
愉快地使用位于 europe-west1 的 Firestore

这仅在 HTTP 功能的客户端支持重定向时有效。就我而言，没问题：所有浏览器都支持重定向。

exports.nextServer = functions
    .https
    .onRequest((req, res) => {
        res.set('location', 'https://europe-west1-<my-project>.cloudfunctions.net/nextServerEurope');
        res.status(301).send()
    });

exports.nextServerEurope = functions
    .region('europe-west1')
    .https
    .onRequest((req, res) => {
        return server.prepare().then(() => nextjsHandle(req, res));
    });

该解决方案的问题是 URL 在浏览器中更改为 https://europe-west1-.cloudfunctions。net/nextServerEurope :-/

解决方案 2

具有向 europe-west1 函数发起 new/proxy 请求的 us-central1 函数
具有相同的 europe-west1 功能来完成这项工作（在我的例子中，服务于 Next.js 应用程序）
仍然愉快地使用位于 europe-west1 的 Firestore

通过代理请求（如指南中所建议的），这将意味着使用像我想的 axios 这样的库。我知道有一些库可以执行节点可用的代理请求。

但是，使用该解决方案，我能想到的第一个问题是经过 us 端点时引入的不必要的延迟：

client -> us endpoint -> eu endpoint -> do stuff -> us endpoint -> client

明智的计费，我想知道会有什么影响..

我知道来自不同区域的两个服务相互调用会增加延迟和计费（出口）。

对于第一个解决方案，没有出口流量，因为它只是重定向到欧洲端点。但在我的情况下，重定向本身并不是一个有效的解决方案。

我不清楚第二种解决方案的额外计费成本是多少（除了延迟成本）：从我们到欧盟的代理请求的流量会很昂贵吗？

总结：

解决方案 1 很简单，但会导致非透明重定向
解决方案 2 似乎没问题，但它需要额外的 http 请求，这会导致额外的延迟（并可能产生额外的费用）最后，这两种解决方案似乎都不太好。

因此我的问题是：

你们如何使用 Firebase 托管和函数在欧洲提供动态内容？

Answer 1

Firebase 托管仅支持 Us-Central 中的 Cloud Functions，正如您提到的和 Firebase Hosting Official Documentation 中所述。

我在 Public 问题跟踪器中创建了一个 Feature Request 以在将 Firebase 托管与 Cloud Functions 结合使用时支持其他地区。请注意，没有具体实施时间。

正如@Doug Stevenson 所建议的那样，您可以使用 Firebase Hosting with Cloud Run 来提供您的动态内容。

在欧盟使用 Firebase Hosting/Functions 提供动态内容

Serve dynamic content with Firebase Hosting/Functions in EU

firebase-hosting

google-cloud-functions