Il s'agit d'un projet Next.js démarré avec create-next-app.
Démarrage
Lancement en local
⭐ Protocole d'installation ⭐
Assurez-vous d'avoir Node.js LTS 20.10.0 d'installé sur votre ordinateur.
Puis, effectuez l'ensemble de ces commandes dans l'ordre :
# Cloner le projet
git clone git@github.com:ODALYS-GROUPE/odalys-v4-next.git odalys-v4-next
# Se déplacer dans le dossier du projet
cd $_
# Installation des dépendances
pnpm i
Puis, avant de lancer le projet, merci de prendre le temps d'installer le Backoffice BOOM et le Projet GraphQL.
Puis
# Lancer le Backoffice en local
# Lancer le projet GraphQL en local
# Et seulement après, lancer le projet Next.js
pnpm run dev
Le projet sera accessible en local à l'adresse suivante : http://localhost:3001.
Version de Node
Le projet utilise un fichier .nvmrc pour définir la version de node à utiliser.
# Basculer vers la version de node définie dans le projet
nvm use
# Installer la version de node requise
nvm install
Afin d'automatiser le changement de version en changeant de répertoire dans votre terminal, merci de suivre la configuration suivante en fonction de votre shell : https://github.com/nvm-sh/nvm#deeper-shell-integration
Exécuter avec docker-compose
Pour exécuter le projet avec Docker, vous aurez besoin de Docker et de Docker-Compose sur votre ordinateur. Voir install Docker.
Ensuite, pour exécuter le proxy stack (nginx) + front nextjs, à la racine du projet, exécutez :
docker-compose up
pour reconstruire complètement les images docker, lancez : bash docker-compose up :
docker-compose up --build
pour redémarrer la pile
docker-compose restart
pour démarrer ou reconstruire un service particulier
docker compose up $SERVICE # $SERVICE peut être next-v4 ou proxy
pour arrêter la pile
docker-compose down
L'application sera disponible à http://127.0.0.1/ en passant par le proxy nginx ou à http://127.0.0.1:3001/ pour accéder directement à nextjs
En savoir plus
Pour en savoir plus sur Next.js, consultez les ressources suivantes :
- Next.js Documentation - pour en savoir plus sur les fonctionnalités et l'API de Next.js.
- Learn Next.js](https://nextjs.org/learn) - un tutoriel interactif sur Next.js.
Vous pouvez consulter le dépôt Next.js GitHub - vos commentaires et contributions sont les bienvenus !
Déployer sur Vercel
La façon la plus simple de déployer votre application Next.js est d'utiliser la Plate-forme Vercel des créateurs de Next.js.
Consultez notre documentation sur le déploiement de Next.js pour plus de détails.
Si les tests ne demarrent pas
chmod +x ./ci/unitests.sh
Déploiements AWS
Les déploiements sont effectués par la CI. L'image docker est construite à l'intérieur du CI et les variables env sont modelées et poussées vers S3 pour être utilisées par le service ECS.
Ajouts de variables Dans la CI pour les envs AWS
Fichier de variables .env
Pour ajouter des variables et secret dans la CI pour les environnements situés sur AWS :
Les variables doivent être situées dans le fichier .env.$PREFIX_ENV situé à la racine du projet, celui ci sera templaté est envoyé vers un S3 spécifique afin d'être utilisé par l'application.
La valeur des environnements (PREFIX_ENV) sont définies au sein de la CI dans la partie de mapping entre les branches git et les variables de CI par exemple :
map: |
{
"main": {
"environment": "production",
"AWS_ROLE_ARN": "${{ env.PROD_AWS_ROLE_ARN }}",
"ECR_REPO": "${{ env.PROD_ECR_REPO }}",
"ECS_CLUSTER": "${{ env.PROD_ECS_CLUSTER }}",
"ECS_SERVICE": "${{ env.PROD_ECS_SERVICE }}",
"S3_ENVVARS": "${{ env.PROD_S3_ENVVARS }}",
"CLOUDFRONT_DISTRIBUTION": "${{ env.PROD_CLOUDFRONT_DISTRIBUTION }}",
"CLOUDFRONT_PATHS": "${{ env.PROD_CLOUDFRONT_PATHS }}"
},
"staging": {
"environment": "staging",
"AWS_ROLE_ARN": "${{ env.STAGING_AWS_ROLE_ARN }}",
"ECR_REPO": "${{ env.STAGING_ECR_REPO }}",
"ECS_CLUSTER": "${{ env.STAGING_ECS_CLUSTER }}",
"ECS_SERVICE": "${{ env.STAGING_ECS_SERVICE }}",
"S3_ENVVARS": "${{ env.STAGING_S3_ENVVARS }}",
"CLOUDFRONT_DISTRIBUTION": "${{ env.STAGING_CLOUDFRONT_DISTRIBUTION }}",
"CLOUDFRONT_PATHS": "${{ env.STAGING_CLOUDFRONT_PATHS }}"
},
"develop": {
"environment": "dev",
"AWS_ROLE_ARN": "${{ env.DEV_AWS_ROLE_ARN }}",
"ECR_REPO": "${{ env.DEV_ECR_REPO }}",
"ECS_CLUSTER": "${{ env.DEV_ECS_CLUSTER }}",
"ECS_SERVICE": "${{ env.DEV_ECS_SERVICE }}",
"S3_ENVVARS": "${{ env.DEV_S3_ENVVARS }}",
"CLOUDFRONT_DISTRIBUTION": "${{ env.DEV_CLOUDFRONT_DISTRIBUTION }}",
"CLOUDFRONT_PATHS": "${{ env.DEV_CLOUDFRONT_PATHS }}"
}
}
-
Pour l'env de développement lié à la branche develop dans git a pour nom d’environnement dev la valeur de $.$PREFIX_ENV sera donc dev. Le fichier de variables d’environnements sera donc .env.dev
-
Pour le staging (preprod) lié a la branche staging le nom d’environnement est staging. Donc le nom du fichier sera .env.staging
-
Pour la production lié a la branche main le nom d’environnement est production. Donc le nom du fichier sera .env.production
Contenu d'un fichier .env.$PREFIX_ENV
Les variables non semsibles peuvent être déclaré de la même manière que dans tout fichier .env c'est à dire sous la syntaxe
MY_VAR=testvar
Les variables sensibles doivent par contre utilisent Github secrets. (l'utilisateur doit avoir les droits)
Imaginons que je souhaite déclarer la variable sensible MY_SECRET sur tous mes environnements
-
sur le repo github aller dans settings > partie security > secrets and variables > actions
-
afin de lier une variable a un environnement, il faut préfixer son nom par $PREFIXENV . Par exemple pour notre variable MY_SECRET if faudra déclarer :
- DEV_MY_SECRET pour l’env de dev
- STAGING_MY_SECRET pour le staging
- PRODUCTION_MY_SECRET pour la production
- enfin de retour dans le point .env.$PREFIX_ENV déclarer notre variable sensible comme suit.
MY_SECRET={{ .my_secret }} # le nom celui dans github secrets doit être en minuscule entre {{ }} prefixé par un point et sans le préfixe d’env
La CI s’occupera de récupérer et de templatiser la variable au moment du déploiement pour créer le fichier à envoyer vers S3.
Envs AWS
Les Urls sont : pour le dev : https://fr.dev-web.odalys-aws.com/
Internationalisation
L'internationalisation sur le projet est gérer via la librairie next-intl.
Fonction de traduction
// Dans un composant client side
import { useTranslations } from 'next-intl';
const ClientSideComponent = () => {
const t = useTranslations('UserProfile');
return <div></div>;
};
// Dans un composant server side
import { getTranslations } from 'next-intl/server';
const ServerSideComponent = async () => {
const t = await getTranslations();
return <div></div>;
};
Exemples
// traduction simple
// simple-trad: "Ceci est une traduction simple"
t('simple-trad');
Output: `Ceci est une traduction simple`;
// traduction avec variable
// variable-trad: "Ouvert du {start} au {end}"
t('variable-trad', { start: 'lundi', end: 'vendredi' });
Output: `Ouvert du lundi au vendredi`;
// traduction avec du style. Par defaut la traduction s'affiche comme une string simple, il faut présicer à next-intl comme interpréter c'est balise pour rendre du html valide
// styled-trad: Bonjour<br></br>Ce texte est en <strong>gras</strong>
t.rich('styled-trad', {
br: () => <br />,
strong: (chunk) => <span className='font-maax-bold'>{chunk}</span>,
});
Output: `Bonjour</br>Ce texte est en <span className='font-maax-bold'>gras</span>`;
// Gestion des pluriels
// my_message: "Vous {count, plural, =0 {n'avez aucun message} =1 {avez un message} other {avez # messages}}.",
t('my_message', { count: 0 });
Output: `Vous n'avez aucun message`;
t('my_message', { count: 1 });
Output: `Vous avez un message`;
t('my_message', { count: 123 });
Output: `Vous avez 123 messages`;
Processus de partage des modifiactions des traductions entre Boom et Next
Vous trouverez la documentation sur notion ici