Configurer et lancer le frontend

Installer l’environnement virtuel NodeJS avec nvm

L’installation de nvm se fait en suivant les instructions du dépot principal de l’outil nvm par creationix creationix/nvm.

Une fois l’environnement installé, installer la dernière version stable de nodejs:

nvm install v10.16

Pour utiliser cette version:

nvm use v10.16

Installer angular CLI (version LTS 6) et les dépendances requises:

npm install -g @angular/cli@v8-lts
npm install

Lancer du frontend

Vous pouvez lancer le frontend dans deux modes:

En mode développement et client-side rendering:

ng serve

En mode Server Side Rendering, optimisé pour le SEO et réservé aux robots d’indexation:

npm run build:ssr && npm run serve:ssr

Gestion du Server Side Rendering

Le SSR a été intégré au projet à partir de la commande :

npm run ng add @nguniversal/express-engine --clientProject frontend

NB: L’intégration Leaflet.MarkerCluster a nécessité de déclarer une variable globale L et d’y importer Leaflet; c’est dans le script server.ts.

Les modules BrowserTransferState et ServerTransferState importés, nous avons créé un couple {clé: valeur} pour être transféré du serveur au client.

La clé est créée avec la fonction factory makeStateKey :

const PROGRAMS_KEY = makeStateKey("programs");

Le transfert d’état s’effectue avec accesseur et mutateur:

this.programs = this.state.get(PROGRAMS_KEY, null as any);
if (!this.programs) {
  /*
    code exécuté côté serveur Node, express
    qui effectue donc un appel à l'API de GN-Citizen
    et génère une capture d'état
  */

  this.state.set(PROGRAMS_KEY, programs as any);
} else {
  /*
    code exécuté côté présentation qui consomme l'état "cristallisé"
    transféré depuis le serveur.
  */
}

La redirection de port pourrait se faire au niveau du serveur web / reverse proxy, avec un filtre sur l’entête de requête User-Agent

Gestion de l’internationalisation (i18n)

La fonctionnalité i18n a été intégrée selon la recette originale.

L’interface est paramétrée par défaut en langue française.

Si l’on souhaitait la servir en langue anglaise:

npm run ng serve -- --configuration=en

La stratégie en cas de traduction manquante est de faire remonter une erreur.

(Ré)génération des fichiers de traduction:

npm run -- ng xi18n --output-path locale --out-file _messages.fr.xlf --i18n-locale fr
npm run -- ng xi18n --output-path locale --out-file _messages.en.xlf --i18n-locale en

Les fichiers de traduction se retrouvent dans le répertoire frontend/src/locale.

Les copier en messages.fr.xlf et messages.en.xlf après édition (mon approche est de les mettre à jour depuis un éditeur de différence).

Génération du rendu SSR dans le context de l’i18n:

La commande suivante permet de générer un rendu SSR multilingue et le servir en langue française.

npm run build:i18n-ssr && npm run serve:ssr

Déploiement

Préparer la distribution avec:

npm run ng build -- --prod

ou:

npm run ng build -- --configuration=en --prod

pour une version en langue anglaise.

Tout est contenu dans le répertoire frontend/dist, qu’il faut copier sur la plateforme acceuillant le service.

Annexe:

Exemple de fichier de configuration serveur Apache2:

/etc/apache2/sites-enabled/citizen.conf

# Configuration GeoNature-citizen
Alias /citizen /home/utilisateur/citizen/frontend/dist/browser

<Directory /home/utilisateur/citizen/frontend/dist/browser>
  Require all granted
  AllowOverride All

  <IfModule mod_rewrite.c>
      Options -MultiViews

      RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteCond %{REQUEST_FILENAME} !-f
          RewriteRule ".*" "index.html" [QSA,L]
  </IfModule>

</Directory>
<Location /citizen/api>
  ProxyPass http://127.0.0.1:5002/api
  ProxyPassReverse  http://127.0.0.1:5002/api
</Location>

Suivi des journaux d’évenements et d’erreurs:

Backend:

tail -f /var/log/supervisor/citizen.log

Gunicorn (option de gestion de processus pour lancer le backend):

tail -f ~/citizen/var/log/gn_errors.log

Apache:

sudo tail -f /var/log/apache2/{error,access,other_vhosts_access}.log

Utiliser PgAdmin pour la gestion de la BDD distante (production):

~/.ssh/config

Host nom_du_raccourci
Hostname son_addresse_ip
User mon_user
LocalForward 5433 localhost:5432

Se logguer en SSH (ssh nom_du_raccourci) sur l’hôte distant va opérer une redirection de port et rendre la BDD distante accessible sur le port local 5433 pour un client PostgreSQL.

Il suffit alors d’ajuster les paramètres de psql en CLI ou ceux de l’assistant de configuration de PgAdmin pour son interface graphique.