Un service Firebase Data Connect comporte trois composants principaux :
- Une base de données PostgreSQL sous-jacente avec son propre schéma SQL
- un schéma d'application Data Connect (déclaré dans vos fichiers
.gql
) - Un certain nombre de connecteurs (déclarés dans vos fichiers
.gql
)
Le schéma SQL est la source de vérité pour vos données. Le schéma Data Connect permet à vos connecteurs de voir ces données, et les connecteurs déclarent les API que vos clients peuvent utiliser pour y accéder.
Lorsque vous déployez votre service Data Connect avec la CLI, vous devez : migrez votre schéma SQL, mettez à jour votre schéma Data Connect, puis mettez à jour chacun de vos connecteurs.
Concepts de déploiement importants
Pour bien comprendre le déploiement, il est important de noter les concepts clés concernant les schémas et les connecteurs.
Déploiements de schémas
Le déploiement d'un schéma Data Connect affecte le schéma SQL de votre base de données Cloud SQL. Data Connect vous aide à migrer vos schémas pendant le déploiement, que vous travailliez avec une nouvelle base de données ou que vous deviez adapter de manière non destructrice une base de données existante.
Les migrations de schéma Data Connect comportent deux modes de validation de schéma différents : strict et compatible.
La validation en mode strict exige que le schéma de la base de données corresponde exactement au schéma de l'application avant que le schéma de l'application puisse être mis à jour. N'importe quelle valeur de tables ou de colonnes qui ne sont pas utilisées dans votre schéma Data Connect sont supprimés de la base de données.
La validation du mode compatible nécessite que le schéma de base de données soit compatible avec le schéma de l'application avant que celui-ci puisse être mis à jour. tout les modifications supplémentaires qui suppriment des schémas, des tables ou des colonnes sont facultatives.
"Compatible" signifie que les migrations de schémas n'affectent que les tables et les colonnes référencées dans le schéma de votre application. Les éléments de votre base de données qui ne sont pas utilisés par le schéma de votre application ne sont pas modifiés. Par conséquent, après le déploiement, votre base de données peut contenir les éléments suivants :
- Schémas
- Tables
- Colonnes
Déploiements de connecteurs
Les requêtes et mutations Data Connect ne sont pas soumis par le code client et exécutés sur le serveur. Au lieu de cela, lors du déploiement, ces opérations Data Connect sont stockées sur le serveur, comme Cloud Functions. Cela signifie que le déploiement peut entraîner des erreurs chez les utilisateurs existants.
Suivre le workflow de déploiement
Vous pouvez travailler sur un projet Data Connect à la fois dans un répertoire de projet local et dans la console Firebase.
Un flux de déploiement recommandé implique les étapes suivantes :
- Répertorier les schémas et connecteurs actuellement déployés avec
firebase dataconnect:services:list
. - Gérer les mises à jour du schéma
- Recherchez les différences de schéma SQL entre vos instances Cloud SQL
et le schéma Data Connect local avec
firebase dataconnect:sql:diff
. - Si nécessaire, effectuez la migration du schéma SQL avec
dataconnect:sql:migrate
.
- Recherchez les différences de schéma SQL entre vos instances Cloud SQL
et le schéma Data Connect local avec
- exécuter des déploiements de schéma et de connexion en exécutant
firebase deploy
; pour votre schéma, pour vos connecteurs ou pour des combinaisons de ressources.
Déployer et gérer des ressources Data Connect
Il est recommandé de vérifier les ressources de production avant d'effectuer des déploiements.
firebase dataconnect:services:list
Lorsque vous travaillez dans un répertoire de projet local, vous utilisez généralement la commande firebase deploy
pour déployer votre schéma et vos connecteurs en production, avec des commentaires interactifs.
À l'aide de n'importe quelle commande deploy
, l'option --only dataconnect
vous permet de séparer
Data Connect déploiements à partir d'autres produits de votre projet.
Déploiement normal
firebase deploy --only dataconnect
Dans ce déploiement normal, la CLI Firebase tente de déployer votre schéma et vos connecteurs.
Il permet de vérifier que le nouveau schéma n'interrompt pas les connecteurs existants. Suivez les bonnes pratiques lorsque vous apportez des modifications incompatibles.
Il vérifie également que le schéma SQL est déjà migré avant de mettre à jour le schéma Data Connect. Si ce n'est pas le cas, il vous invite automatiquement les étapes nécessaires pour migrer des schémas.
Déploiement de l'option --force
firebase deploy --only dataconnect --force
Si les validations du connecteur ou du schéma SQL ne vous préoccupent pas, vous pouvez
réexécutez la commande avec --force
pour les ignorer.
Le déploiement --force
vérifie toujours si le schéma SQL correspond au schéma Data Connect, émet un avertissement en cas d'incompatibilité et affiche des invites.
Déployer les ressources sélectionnées
Pour un contrôle plus précis, utilisez l'option --only
avec la commande
l'argument serviceId
. Pour déployer uniquement les modifications de schéma pour un service particulier:
firebase deploy --only dataconnect:serviceId:schema
Vous pouvez également déployer toutes les ressources pour un connecteur et un service spécifiés.
firebase deploy --only dataconnect:serviceId:connectorId
Enfin, vous pouvez déployer le schéma et tous les connecteurs pour un seul service.
firebase deploy --only dataconnect:serviceId
Effectuer le rollback d'un déploiement
Pour effectuer un rollback manuel, consultez une version précédente de votre code et le déployer. Si le déploiement d'origine incluait des modifications destructives destructives, vous ne pourrez peut-être pas récupérer entièrement les données supprimées.
Migrer des schémas de base de données
Si vous effectuez des prototypes rapidement, si vous testez des schémas et si vous connaissez vos schémas sont destructrices, pensez à utiliser les outils Data Connect pour vérifier les modifications et superviser leur exécution.
Différences entre les modifications de schéma SQL
Vous pouvez vérifier les modifications :
firebase dataconnect:sql:diff
Vous pouvez transmettre une liste de services séparés par une virgule.
La commande compare le schéma local d'un service au schéma actuel de la base de données Cloud SQL correspondante. En cas de différence, Commandes SQL qui seraient exécutées pour corriger cette différence
Appliquer les modifications
Lorsque vous êtes satisfait et prêt à déployer les modifications apportées à l'instance Cloud SQL du schéma, exécutez la commande firebase dataconnect:sql:migrate
. Vous serez
invité à approuver les modifications.
firebase dataconnect:sql:migrate [serviceId]
Dans les environnements interactifs, les instructions de migration SQL et les invites d'action sont affiché.
Migrer en mode strict ou compatible
Dans un tout nouveau projet, le mode de validation du schéma par défaut s'applique. Le comportement de la commande migrate
consiste à appliquer toutes les modifications de schéma de base de données requises par le schéma de votre application, puis à vous inviter à approuver les opérations facultatives qui suppriment des schémas, des tables ou des colonnes pour forcer votre schéma de base de données à correspondre exactement à celui de votre application.
Vous pouvez ajuster ce comportement en modifiant votre fichier dataconnect.yaml
.
Annulez la mise en commentaire de la clé schemaValidation
et déclarez COMPATIBLE
pour que seule
les modifications requises sont appliquées lors des migrations.
schemaValidation: "COMPATIBLE"
Vous pouvez également définir le comportement sur STRICT
pour que toutes les modifications de schéma soient appliquées et
schéma de base de données doit obligatoirement correspondre au schéma de votre application.
schemaValidation: "STRICT"
Pour en savoir plus, consultez la documentation de référence de la CLI Data Connect.
Bonnes pratiques pour la gestion des schémas et des connecteurs
Firebase recommande certaines pratiques à suivre dans vos projets Data Connect.
Limiter les modifications destructives
- Firebase recommande de conserver votre schéma et votre connecteur Data Connect dans le contrôle des sources.
- Dans la mesure du possible, évitez les modifications importantes. Quelques exemples courants de défaillance
les modifications suivantes sont apportées:
- Supprimer un champ de votre schéma
- Rendre un champ pouvant avoir une valeur nulle dans votre schéma (par exemple,
Int
->Int!
) - Renommer un champ dans votre schéma
- Si vous devez supprimer un champ de votre schéma, envisagez de le scinder
en quelques déploiements pour minimiser l'impact:
- Commencez par supprimer toutes les références au champ dans vos connecteurs, puis déployez la modification.
- Ensuite, mettez à jour vos applications pour qu'elles utilisent les SDK nouvellement générés.
- Enfin, supprimez le champ dans le fichier
.gql
de votre schéma, migrez votre schéma SQL, puis déployez-le à nouveau.
Utiliser le mode strict lorsque vous travaillez avec de nouvelles bases de données
Si vous utilisez Data Connect avec une nouvelle base de données et que vous
développer le schéma de votre application et vous voulez vous assurer que le schéma
conforme au schéma de votre application, vous pouvez spécifier
schemaValidation: "STRICT"
dans votre dataconnect.yaml
.
Ainsi, les modifications facultatives seront également appliquées.
Utilisez le mode compatible lorsque votre base de données contient des données de production
Si vous apportez des modifications à une base de données qui contient des données de production, nous
nous vous recommandons d'exécuter vos migrations de schéma en mode compatible, pour vous assurer
les données existantes ne sont pas supprimées. Vous pouvez spécifier schemaValidation: "COMPATIBLE"
dans votre dataconnect.yaml
.
En mode compatible, seules les modifications de migration de schéma requises sont appliquées à votre base de données.
DROP SCHEMA
,DROP TABLE
etDROP COLUMN
sont considérés comme des instructions facultatives et ne seront pas générés pour votre plan, même si votre schéma de base de données contient des schémas, des tables ou des colonnes qui ne sont pas définis dans votre schéma d'application.- Si votre table de base de données contient une colonne non nulle qui n'est pas incluse dans votre schéma d'application, la contrainte
NOT NULL
sera supprimée afin que les données puissent toujours être ajoutées à la table avec les connecteurs définis.
Étape suivante
- Le déploiement et la gestion du code client que vous développez avec des SDK générés sont abordés dans les guides pour Android, iOS, Web et Flutter.
- Pour en savoir plus sur les outils de déploiement, consultez la documentation de référence de la CLI Data Connect. et la documentation de référence du fichier de configuration Data Connect.