À vos marques, prêts, feu !
Salut, Tom ici en train d'écrire ! Si vous êtes un utilisateur passionné de Firebase, vous savez à quel point la gestion de votre backend sans backend peut être simple. Grâce à Firebase Functions, j'écris simplement ma logique métier sous la forme d'une simple fonction, je déploie cette même fonction via la CLI et je peux y accéder depuis le cloud partout sur la planète. La configuration elle-même est si simple que le déploiement à lui seul ne prend que quelques minutes au maximum. Mais il existe un cas particulier avec les fonctions Firebase qui pourraient nécessiter un peu plus de travail - en utilisant un domaine personnalisé, et non celui fourni par Firebase.
Le défi
Si vous déployez simplement Firebase Functions comme décrit, vous obtiendrez un hôte sous un sous-domaine de Google, en particulier sous
cloudfunctions.net
Pour les cas d'utilisation simples, c'est principalement ce dont vous avez besoin - il suffit de déployer la chose et de la rendre disponible pour la consommation. Mais d'autres cas d'utilisation nécessitent que votre backend soit accessible sous votre domaine. Pour cet exemple, j'utiliserai mon propre domaine flaming.codes.
La mise en place
Voici les prérequis, juste pour être sûr :
- vous avez configuré un projet Firebase
- sous Hébergement, vous avez configuré votre domaine personnalisé ; il s'agit d'un processus simple, où il vous suffit de stocker un enregistrement TXT chez votre fournisseur d'hébergement
La config
Pour que votre domaine personnalisé fonctionne non seulement pour votre application Web hébergée, mais également pour vos fonctions, firebase.json doit être mis à jour (explication après l'exemple) :
{
"functions": {
...
},
"hosting": {
...,
"rewrites": [
{
"source": "/api/**",
"function": "api"
},
{
"source": "!/api/**",
"destination": "/index.html"
}
]
},
...
}
La seule astuce pour que cela fonctionne est de mettre à jour la clé d'hébergement, et non les fonctions, dans votre firebase.json. Ce que nous faisons essentiellement, c'est dire à Firebase qu'à partir de notre application Web hébergée, tous les appels à /api/... doivent être redirigés vers la fonction appelée api. La chose qui m'a pris le plus de temps était le deuxième élément, où je dois explicitement déclarer toute autre route que l'API à gérer comme route d'application Web par défaut.
En utilisant la configuration suivante, l'ancienne fonction cloud
https://uscentral1-flaming-codes.cloudfunctions.net/api
devient donc
Notez que l'ordre est important ici, les règles de réécriture sont traitées du premier au dernier élément, donc dans ce cas de haut en bas, visuellement parlant. L'utilisation d'un caractère générique pour remapper toutes vos fonctions n'est vraiment pas conseillé pour une utilisation générale, car cela endommagerait votre application Web.
Emballer
Et oui, ce n'est vraiment pas magique mais peut grandement aider lors de l'utilisation des fonctions Firebase dans certains cas d'utilisation. Nous avons vu comment réécrire vos fonctions cloud dans le cadre du domaine déjà enregistré, éliminant ainsi la nécessité d'un nouveau sous-domaine personnalisé - bien que cela soit également possible, mais hors de portée de ce didacticiel.
- Tom
