Я хотел бы обслуживать приложение Next.js в Европе, используя возможности хостинга и функций Firebase.
Я понимаю из документа, что:
Если вы используете функции HTTP для предоставления динамического контента для Firebase Хостинг, вы должны использовать us-central1
и что
Firebase Hosting поддерживает облачные функции только в us-central1
Это довольно ясно: вы должны использовать us-central. Но моя главная цель - Европа..
Я прочитал следующее в руководстве по расположению облачных функций:
Для HTTP и вызываемых функций мы рекомендуем сначала установить функции в регионе назначения или ближайшем к наиболее ожидаемому находятся клиенты, а затем измените исходную функцию на перенаправить свой HTTP-запрос на новую функцию (они могут иметь одинаковые имя).
[Solution 1]
Если клиенты вашей функции HTTP поддерживают перенаправления, вы можете просто изменить исходную функцию, чтобы она возвращала Статус перенаправления HTTP (301) вместе с URL-адресом вашей новой функции.[Solution 2]
Если ваши клиенты плохо справляются с редиректами, вы можете прокси-запрос от исходной функции к новой функции с помощью инициирование нового запроса от исходной функции к новой функция. Последним шагом является обеспечение того, чтобы все клиенты вызывали новая функция.
Я выделил то, что кажется двумя решениями моей первоначальной проблемы:
Решение 1
Это будет работать только в том случае, если клиенты функции 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
По прокси-запросу (как предлагается в руководстве) это будет означать использование библиотеки, такой как axios, я полагаю. Я знаю, что есть некоторые библиотеки для выполнения прокси-запросов, доступных и для node.
Однако с этим решением первая проблема, о которой я могу подумать, — это ненужная задержка, вызванная передачей конечной точки us:
client -> us endpoint -> eu endpoint -> do stuff -> us endpoint -> client
Что касается выставления счетов, мне интересно, как это повлияет ..
Я знаю, что две службы из разных регионов, звонящие друг другу, могут увеличить задержку и биллинг (исход).
В первом решении нет исходящего трафика, так как это только перенаправление на европейскую конечную точку. Но само перенаправление не является допустимым решением в моем случае.
Для меня неясно, какова будет дополнительная стоимость выставления счетов со вторым решением (помимо стоимости задержки): будет ли трафик для запроса прокси от нас к ЕС дорогим?
Обернуть:
Поэтому мой вопрос:
Как вы обслуживаете динамический контент в Европе с помощью хостинга и функций Firebase?
Да, я сделал. Первое решение нежизнеспособно (как объяснено). Второе решение просто неправильно с точки зрения архитектуры (я не эксперт, но мне кажется неправильным размещать прокси-запрос для обхода ограничения). Вы можете найти множество руководств по развертыванию Next.js в облачных функциях, поэтому мой вопрос. Но, в конце концов, с таким ограничением, кажется, это относится только к американской аудитории. Немного удивлен/озадачен этим ограничением. Вот и все. Я проверю Cloud Run. Спасибо, в любом случае
Хостинг Firebase поддерживает только облачные функции в Us-Central, как вы упомянули и как указано в Официальной документации Firebase Hosting.
Я создал запрос функции в Public Issue Tracker, чтобы поддерживать другие регионы при использовании Firebase Hosting с облачными функциями. Обратите внимание, что нет ETA, когда это будет реализовано.
Поэтому, как предлагает @Doug Stevenson, вместо этого вы можете использовать Firebase Hosting with Cloud Run для обслуживания своего динамического контента.
Спасибо за ваш вклад. Я буду рад поддержать этот запрос функции, если он будет работать так (хотя я не могу получить доступ к предоставленной вами ссылке)
При доступе к запросу функции в Public Issue Tracker выдает ли он какую-либо ошибку или что-то в этом роде?
Да: «Отказано в доступе для: [email protected]». Как ни странно, когда я посещаю issuetracker.google.com/issues , я получаю полный список запросов об ошибках/функциях, и я могу щелкнуть по ним, чтобы увидеть подробности (например, этот случайный issuetracker.google.com/issues). /175796493)
Теперь вы должны увидеть запрос функции, так как теперь он общедоступен. Пожалуйста, попробуйте еще раз, чтобы получить к нему доступ.
Обратите внимание, что эта функция будет работать только с обновленным интерфейсом командной строки Firebase, так как было внесено несколько изменений в развертывание.
Лишь бы обновить. По состоянию на август 2022 г.
Наконец, проблема с задержкой может быть легко решена на данный момент.
Перезапись Firebase Hosting на CF3 может быть выполнена для любого CF3. регион, а не только сша-центр1.
Ссылка: Билет запроса функции
Вы на самом деле пробовали что-то из того, что здесь предлагали? Я подозреваю, что они не будут работать так, как вы ожидаете, по разным причинам. Я предлагаю вам вообще не использовать облачные функции. Вместо этого используйте Cloud Run.