Génération des types graphql
on écrit un fichier _query.gql
ou _mutation.gql
# _query.gql
query SearchBeneficiaries($filter: String) {
beneficiary(
where: {
_or: [
{ peNumber: { _ilike: $filter } }
{ cafNumber: { _ilike: $filter } }
{ lastname: { _ilike: $filter } }
{ mobileNumber: { _ilike: $filter } }
]
}
) {
dateOfBirth
firstname
id
lastname
mobileNumber
}
}
on génère les types avec codegen
# depuis le répertoire app
npm run codegen
Les types graphql sont générés dans src/_gen
. On peut alors les utiliser dans les composants
export const load: Load = async ({ page }) => {
const filter = page.query.get('filter');
const result = operationStore(SearchBeneficiariesDocument, {
filter: `%${filter}%`,
});
return {
props: {
result,
filter,
},
};
};
Modification des metadata Hasura
après avoir modifié des metadatas hasura dans la console (permissions, GraphQL field name, etc), ne pas oublier de les exporter
# depuis le répertoire ~/hasura
hasura metadata export
Migration de la base de données
Si les modifications du schéma de la base de données ont faites à partir de la console hasura http://localhost:9695/
, hasura génère automatiquement des fichiers de migrations dans hasura/migrations
.
avant de merge
une PR, ne pas oublier de (squash)[https://hasura.io/docs/latest/graphql/core/hasura-cli/hasura_migrate_squash.html] les fichiers.
Les migrations sont appliquées automatiquement au lancement de hasura
# depuis le répertoire racine
docker compose up --build
Les modifications apportées au code doivent passer par des PR qui seront validées avant de pouvoir être versées dans la branche principale. On n'assigne pas forcément de relecteur, tout le monde est libre de relire la PR d'une autre personne.
Dans le cas où une personne de l'équipe de dev est seule, elle peut valider sa PR elle-même pour pouvoir avancer.
Lorsque la PR est validée, on laisse le soin à l'auteur de la PR de faire le merge.
L'équipe privilégie les "squash and merge" avec un message de commit qui suit le formalisme conventional commit de manière à pouvoir générer le fichier CHANGELOG.md automatiquement.
Pour les environnements de review les mails envoyés par l'application sont visible sur une instance de maildev que l'on déploie lorsqu'on déploie nos environnements de review-branch.
Pour la preprod, nous utilisons mailtrap (demander l'accès)
docker compose exec -T db psql --dbname carnet_de_bord --user cdb < hasura/migrations/carnet_de_bord/${migration_name}/${up|down}.sql
Si la table account
peut porter un professional_id
, il n'est pas possible de faire la requête suivante, pourtant valide pour des propriétés "internes" :
query GetProfessionalsNotLinkedFromAccount {
professional_aggregate(where: { account: { _is_null: true } }) {
aggregate {
count
}
}
}
Il faut la formuler comme suit :
query GetProfessionalsNotLinkedFromAccount {
professional_aggregate(where: { _not: { account: {} } }) {
aggregate {
count
}
}
}