Serve dynamic content with Firebase Hosting/Functions in EU

I would like to serve a Next.js app in europe using Firebase Hosting & Functions capabilities.

I do understand from the doc that:

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

and that

Firebase Hosting supports Cloud Functions in us-central1 only

It's pretty clear: you must use us-central. But my main target is Europe..

I've read the following on the Cloud Functions locations guide:

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.

I've highlighted what seems to be two solutions to my initial problem:

Solution 1

Have a us-central1 function that send a 301 redirection to https://europe-west1-[myProject].cloudfunctions.net/[myEuropeanFunction]
Have a europe-west1 function that does the job (in my case, serve the Next.js app)
Happily using Firestore located in europe-west1

This would only work if clients of the HTTP function support redirects. In my case, it's fine: all browsers support redirection.

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));
    });

The issue with that solution is that the URL changes in the browser to https://europe-west1-.cloudfunctions.net/nextServerEurope :-/

Solution 2

Have a us-central1 function that initiate a new/proxy request to the europe-west1 function
Have the same europe-west1 function that does the job (in my case, serve the Next.js app)
Still happily using Firestore located in europe-west1

By proxy request (as suggested in the guide), it would mean using a lib like axios I suppose. I know there are some libraries to perform proxy request available for node as well.

However, with that solution, the first issue I can think of is the unnecessary delay introcuded by passing by the us endpoint:

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

Billing wise, I'm wondering what would be the impact..

I know that two services from different regions calling each others can increase the latency and the billing (egress).

With the first solution, there's no egress traffic as it's only a redirection to the european endpoint. But the redirection itself is not a valid solution in my case.

It's unclear for me what would be the additional billing cost with the second solution (beside the latency cost): is the traffic for the proxy request from us to eu going to be expensive?

To wrap-up:

The solution 1 is easy but leads to a non-transparent redirection
The solution 2 seems ok but it requires extra http request which leads to extra-latency (and potentially extra billing) In the end, both solutions doesn't seem quite okay.

Therefore my question:

How do you serve in Europe dynamic content using Firebase Hosting and Functions?

Solution

Firebase Hosting only supports Cloud Functions in Us-Central as you mentioned and as stated in the Firebase Hosting Official Documentation.

I have created a Feature Request in Public Issue Tracker to support other regions when using Firebase Hosting with Cloud Functions. Please note, there is no ETA when this will be implemented.

So as @Doug Stevenson suggest, you can use Firebase Hosting with Cloud Run instead to serve your Dynamic Content.