Firebase-tools: L'hébergement n'exécute pas la fonction si la région de la fonction n'est pas par défaut

Également un exemple de dépôt https://github.com/istarkov/firebase-hosting-error

Salut, c'est un comportement attendu, veuillez voir https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions , la boîte bleue indique que toutes les fonctions qui servent de redirections d'hébergement doivent être dans 'us-central1', c'est en raison du fait que c'est là que se trouve l'origine de l'hébergement.

Merci, y a-t-il une chance que ce comportement attendu soit modifié dans un avenir proche ou du moins dans un avenir ?

Salut, ça va changer dans un futur, mais pas dans un futur proche. Cela dépend du moment où Firebase Hosting lance ses origines dans d'autres zones géographiques.

Bonjour,
Mon problème est très similaire à celui-ci, mais mes fonctions devraient être dans l'UE, car il utilise un réseau externe, et la latence est bien meilleure de cette façon (2-4 sec vs 4-600 ms) temps d'exécution
J'ai décrit mon problème dans :
https://github.com/firebase/firebase-js-sdk/issues/1101
il n'y a donc pas encore de solution pour utiliser les réécritures vers une autre région pour le moment ?
(J'ai une solution de contournement, en utilisant des liens directs pour accéder à la fonction UE, mais ce n'est pas idéal du côté du développement, je dois tout redéployer pour le tester)

J'adorerais voir cela mis en œuvre. Mes visiteurs viennent d'Europe, et le TTFB de us-central1 est au moins 3x plus grand que europe-west1 .

Salut, ça va changer dans un futur, mais pas dans un futur proche. Cela dépend du moment où Firebase Hosting lance ses origines dans d'autres zones géographiques.

Salut @laurenzlong ,

cela signifie-t-il que lorsque l'hébergement sera disponible via d'autres emplacements que us-central1 , nous pourrons également contourner la limitation suivante ?
Important: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1. du document

J'ai besoin de cette fonctionnalité pour mon application. Alors, le plus tôt sera le mieux :) !

Merci beaucoup pour tout cela.

Un avertissement en gras doit être écrit jusqu'à ce que cela soit corrigé. J'ai passé trop de temps jusqu'à ce que je réalise ce qui se passe.
Ajoutez au moins une option region aux réécritures afin que nous puissions rediriger vers l'Europe.

Hope fonction cloud pour Firebase prend en charge l'option region comme le paramètre cloud run l'a fait. J'utilise la région tokyo . C'est vraiment loin de us-central1 .

cela signifie-t-il que lorsque l'hébergement sera disponible via d'autres emplacements que us-central1 , nous pourrons également contourner la limitation suivante ?
Important: If you are using HTTP functions to serve dynamic content for hosting, you must use us-central1. du document

Salut @laurenzlong ,

en avez-vous (bon) ? des nouvelles à ce sujet ?

Je suis d'accord que, comme l'a dit @wangchou , le cloud run serait une alternative, mais cela ajoute une pile de services / technologies.

En espérant vous lire bientôt. Merci!

Nous étudions toujours la question, mais pour le moment, notre infrastructure d'origine est concentrée dans us-central , ce qui signifie qu'autoriser le proxy de fonction dans d'autres régions finirait par créer une latence supplémentaire dans la plupart des cas. Par exemple:

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

Cela signifie que le temps aller-retour fait quelque chose comme doubler.

Nous étudions l'expansion des emplacements de notre infrastructure d'origine, mais jusque-là, nous hésitons à ajouter cette capacité car elle est plus susceptible de causer du mal que du bien.

@mbleigh - Pourriez-vous nous donner des estimations lorsque l'origine de l'hébergement sera située en dehors des États-Unis ?

L'ensemble de l'environnement Firebase est incroyable, mais cela nous fait réfléchir à deux fois avant de passer à celui-ci. Merci

Je ne sais vraiment pas pourquoi ce problème a été fermé s'il n'a pas été résolu, cogner +1.

Deuxièmement, Firebase est incroyable, mais pour les utilisateurs européens, c'est une mise en garde majeure.

Désolé, nous ne pouvons pas commenter les délais car ils sont un peu trop sujets à changement. J'apprécie la voix continue pour soutenir cela en tant que fonctionnalité, c'est certainement quelque chose que nous prenons en compte lorsque nous planifions et construisons le produit.

J'ai un problème qui pourrait être lié à cela, mais je ne comprends pas tout à fait cela, donc je ne sais pas. Si quelqu'un qui sait mieux et a le temps veut commenter cela, s'il vous plaît voir cette question:

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

Ce serait une bonne chose d'avoir cela, nous pourrions enfin ajouter une réécriture d'hébergement à nos fonctions déjà présentes dans europe-west1.

Ce serait génial en effet. Pour l'instant, utilisez également les redirections comme @hgghyxo l'a mentionné :

Nom de la fonction api
Région europe-west1

firebase.json

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

@mcoevert a commenté le 19 août 2019 à 10 h 36 GMT+2 :

Ce serait génial en effet. Pour l'instant, utilisez également les redirections comme @hgghyxo l'a mentionné :

Les redirections ne résoudront cependant pas les problèmes de CORS.

J'aimerais aussi voir le soutien de la région Europe.

Il semble qu'une réécriture puisse désormais être effectuée avec un service Cloud Run hébergé sur la région europe-west1 (actuellement la seule région européenne disponible pour Cloud Run). Ce n'est pas tout à fait pareil, mais assez proche.

Salut, c'est un comportement attendu, veuillez voir https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions , la boîte bleue indique que toutes les fonctions qui servent de redirections d'hébergement doivent être dans 'us-central1', c'est en raison du fait que c'est là que se trouve l'origine de l'hébergement.

Désolé, mais une petite boîte bleue passe facilement à côté. Nous avons perdu trop d'heures sur ce problème, pensant qu'il s'agissait d'un problème de configuration de notre côté.

Pourquoi est-ce fermé - c'est un problème pour nous en Europe. Y a-t-il une explication pourquoi cela ne fonctionne que pour la région nous ?

Ce problème est résolu, car il s'agit d'une demande de fonctionnalité pour l'hébergement Firebase qui ne peut pas être traitée directement dans la CLI Firebase. Les demandes de fonctionnalités sont suivies en interne et je vous encourage à demander de l'aide pour des régions supplémentaires via ce formulaire .

Nous sommes certainement conscients que vous êtes nombreux à souhaiter cette fonctionnalité, merci pour vos commentaires !

Ce problème est résolu, car il s'agit d'une demande de fonctionnalité pour l'hébergement Firebase qui ne peut pas être traitée directement dans la CLI Firebase. Les demandes de fonctionnalités sont suivies en interne et je vous encourage à demander de l'aide pour des régions supplémentaires via ce formulaire .

Nous sommes certainement conscients que vous êtes nombreux à souhaiter cette fonctionnalité, merci pour vos commentaires !

Les demandes de fonctionnalités ne sont suivies qu'en interne ? Cela n'apporte-t-il pas beaucoup de demandes en double ? J'aimerais montrer la prise en charge de ces fonctionnalités pour inclure les régions autres que les États-Unis.

Oui - si vous envoyez une demande de fonctionnalité, nous la dédoublonnerons des autres pour notre suivi interne (et cela aide certainement à montrer plus de support pour les demandes !).

Vous pouvez utiliser Cloud Run au lieu d'une fonction Cloud si vous n'avez pas besoin d'un VPC. Cloud Run (entièrement géré) ne peut pas se connecter au réseau VPC pour le moment. Une solution de contournement que j'ai testée pour utiliser le VPC + le domaine personnalisé + la fonction Cloud consiste à utiliser un Cloud Run avec un domaine personnalisé qui est un proxy de la fonction Cloud. Cela ajoute un peu de surcharge, mais si votre Cloud Run et Cloud Function se trouvent dans la même région, alors, en théorie, il ne devrait pas y avoir beaucoup de latence. Cela étant dit, je l'ai surveillé pendant un mois et la version bêta de Cloud Run n'est pas aussi stable à 100 % :

Ceci est un référentiel avec le proxy que j'ai utilisé si vous souhaitez le déployer sur Cloud Run et l'essayer https://github.com/reactgraphqlacademy/cloud-run-proxy

J'ai testé un travailleur Cloudflare avec un proxy dans la même région que la fonction Cloud et je l'ai surveillé sur la même période. Il était plus lent que le Cloud Run, même s'il était fiable à 100 %.

Vous pouvez utiliser ce code si vous souhaitez tester le travailleur Cloudflare https://gist.github.com/alexlbr/814446f03cf12e22f07ccaa580eb1154 . @wangchou Si je ne me trompe pas, vous pouvez exécuter le travailleur Cloudflare dans Tokio, afin qu'il soit plus proche du bord où se trouve l'utilisateur puisque Cloud Run n'est pas encore pris en charge dans cette région.

Ce qui suit surveille la Fonction Cloud directement sans aucun proxy pendant la même période.

J'ai utilisé https://uptimerobot.com pour la surveillance.

Cloud Run m'a l'air très prometteur, j'ai hâte de voir la version complète

Des mises à jour à ce sujet ? Pourquoi c'est fermé ?

Impossible?

@abdellahaski @l2aelba Nous entendons certainement le point douloureux ici. Comme @mbleigh l' a dit plus tôt, le déposer en tant que demande de fonctionnalité (voir ci-dessous) est le meilleur moyen d'aider cela à gagner du terrain pour nous en interne. Merci!

Ce problème est résolu, car il s'agit d'une demande de fonctionnalité pour l'hébergement Firebase qui ne peut pas être traitée directement dans la CLI Firebase. Les demandes de fonctionnalités sont suivies en interne et je vous encourage à demander de l'aide pour des régions supplémentaires via ce formulaire .

Nous sommes certainement conscients que vous êtes nombreux à souhaiter cette fonctionnalité, merci pour vos commentaires !

J'aimerais aussi voir le support asia-east2.

Je suis sur le point d'abandonner Firebase à cause de la mauvaise documentation.

Un minimum absolu serait d'émettre un avertissement s'il n'y a pas de fonction dans us-central correspondant à la fonction dans la redirection !

Je suggère que l'équipe Firebase essaie de laisser quelqu'un développer un projet où les utilisateurs sont en dehors des États-Unis. C'est fou qu'on ne reçoive pas d'avertissements pour ce genre de choses.

Aidons-nous les uns les autres en faisant ce qu'ils demandent - postez une demande de fonctionnalité :
https://firebase.google.com/support/troubleshooter/report/features

Voici un brouillon à partir duquel vous pouvez copier/coller - faites-le simplement :)

L'hébergement réécrit les fonctions dans une région autre que les États-Unis
https://github.com/firebase/firebase-tools/issues/842

Vraiment besoin d'être en mesure de créer des réécritures pour les fonctions dans des régions autres que US-Central1.

Notre public cible n'est pas aux États-Unis et l'absence de cette fonctionnalité est un grand problème pour nous, ce qui nous rend incertains de dédier notre pile technologique à Firebase dans son ensemble.

Veuillez envisager de donner la priorité à cette fonctionnalité dans un avenir proche.
Merci,

Ici, j'espère que cette fonctionnalité sera bientôt disponible !

Quelqu'un a-t-il fait des recherches sur l'utilisation du cloud run au lieu des fonctions cloud ?

Cloud run fournit également des fonctionnalités dans d'autres régions

Deux ans après et c'est toujours un problème.. Pourquoi est-ce fermé d'ailleurs ?

Salut, c'est un comportement attendu, veuillez voir https://firebase.google.com/docs/functions/locations#http_and_client_callable_functions , la boîte bleue indique que toutes les fonctions qui servent de redirections d'hébergement doivent être dans 'us-central1', c'est en raison du fait que c'est là que se trouve l'origine de l'hébergement.

Radiomessagerie @laurenzlong

Cloud Functions est disponible dans les régions suivantes :

• us-central1 (Iowa)
• us-east1 (Caroline du Sud)
• us-east4 (Virginie du Nord)
• europe-ouest1 (Belgique)
• europe-west2 (Londres)
• europe-west3 (Francfort)
• asia-east2 (Hong Kong)
• asie-nord-est1 (Tokyo)

J'ai choisi eur3 (europe-ouest) car il était en haut de la liste avec us-central1 et séparé des autres emplacements. Pensé que ces deux sont par défaut.

Que dois-je faire, y a-t-il une solution à ce problème ?

Pourquoi?????

Salut les gens, merci pour tous les commentaires à ce sujet. Nous vous entendons certainement dire que vous aimeriez voir les fonctions de support de Firebase Hosting en dehors de us-central1 . Malheureusement, il y a une quantité importante de travaux d'infrastructure qui doivent être effectués avant que cela fonctionne bien, nous ne pouvons donc pas simplement "actionner un interrupteur" et mettre d'autres régions en ligne.

Nous en avons entendu parler assez souvent en tant que demande de fonctionnalité, et c'est sur notre feuille de route, bien que je ne puisse pas commenter les délais spécifiques. Ce référentiel n'est pas le bon endroit pour publier des demandes de fonctionnalités pour le produit Firebase Hosting dans son ensemble - si vous êtes intéressé par cette fonctionnalité, veuillez soumettre une demande de fonctionnalité afin que nous puissions continuer à suivre l'intérêt pour cela en interne et prioriser le travail cela doit arriver pour l'activer.

Merci a tous!

Salut,

Je pense que personne ne se soucie de l'endroit où vous hébergez, nous voulons juste une solution simple pour que cette erreur ne s'affiche pas.

Ce correctif peut être fait dans votre code, rien à faire là où vous faites votre hébergement..

Et ce n'est pas une demande de fonctionnalité, la suppression d'un bogue ne devient pas une fonctionnalité. Supprimez simplement ce bogue

Merci..