# chatbot

EXERCICE 1

Vérifier si node est bien installé sur l'ordinateur:

$ node --version
$ curl --version

Vérifier que git est bien connecté sur notre email de l'EEMI

\$ git config --global user.email

Créer un repertoire git & le cloner sur la machine

git clone -q <url_du_projet>

Installer les dépendances et faire tourner le programme

installer les dépendances requises à l'aide des commandes suivantes : npm install pour le node_modules et npm install express --save pour Express
npm start server.js dans le terminal
Ouvrir un navigateur à l'adresse suivante : localhost:3000/
-Si "Hello World" s'affiche alors le projet a correctement démarré.

EXERCICE 2

Creer un compte puis une appplication sur heroku.com
Suivre les instructions pour installer la commande heroku sur nos ordinateurs; puis se connecter à son compte depuis le terminale
Suivre les instructions fournies pour déployer le serveur en production sur l'application Heroku
Modifier le serveur definir sur le port 3000 pour l'execution en local
Créer une nouvelle release tag v1.2

EXERCICE 3

Ajouter un point d'entrer GET /hello qui repond systématiquement : Quel est votre nom ?

\$curl http://localhost:3000/hello

Chercher dans la doc de Express.js comment recuperer la valeur d'un get
Modifier le point d'entrer GEt /hello pour qu'il reponde Bonjour, ! si un nom a etet fournit dans le get et quel est votre nom? quand ce n'est pas le cas
Deployer une mise a jour du serveur en production
Creer une nouvelle release git tag v1.3

PARTIE 2

Exercice 1 - Lecture et écriture dans MongoDB
Le but est de découvrir comment manipuler une base de données MongoDB depuis un programme Node.js, à l’aide du package mongodb. (anciennement connu sous le nom de “MongoDB Native Driver for Node.js”)

Pour cela, nous allons:

créer une collection MongoDB “dates”;
découvrir comment lire et écrire des données dans cette collection depuis un programme Node.js, à l’aide du package mongodb.
Objectifs
Fonctionnel: Le programme doit se connecter à une base de données MongoDB, ajouter un document { date: (new Date()).toString() } dans la collection dates, puis afficher tous les documents actuellement stockés dans cette collection.
Lisibilité: 40 lignes de code max, utilisation de async/await pour les appels asynchrones à la base de données.
Structure: Le code source du projet ne doit pas contenir plus de 5 fichiers. (dont dates.js, package.json et README.md)
Production: À ce stade, vous n’aurez pas besoin de déployer quoi que ce soit en production.
Étapes proposées
Initialiser un serveur de base de données MongoDB. Il existe (au moins) trois manières de procéder:

(A) Utilisation d’un serveur MongoDB dans le cloud: Il suffit de créer un compte sur MongoDB Atlas puis de suivre les étapes proposées pour créer (puis tester) une base de données basée sur la plateforme “Azure”. ⚠ Vérifier que vous parvenez bien à vous connecter via le réseau WiFi de votre école, ce n’est pas toujours le cas.

(B) Sinon – si Docker fonctionne bien sur votre machine – lancer le serveur MongoDB via une image Docker, en suivant ces étapes:

Téléchager et exécuter l’image Docker du serveur de MongoDB avec la commande suivante:
$ docker run --rm --publish 27017:27017 --name mongodb-pour-nodejs mongo:4
Tester la connection au serveur MongoDB en exécutant cette commande:
$ docker run --rm -it --link mongodb-pour-nodejs:mongo mongo:4 mongo --host mongo test
(C) Sinon: installer, configurer et lancer un serveur MongoDB sur votre machine, en suivant ces étapes:

Installer MongoDB Server, community edition sur votre machine,
Après avoir redémarré votre terminal, si la commande mongod est introuvable, ajoutez le répertoire créé dans la variable PATH de votre système d’exploitation, en suivant les instructions de Install MongoDB,
Comme indiqué dans les instructions de Run MongoDB, créez un répertoire /data/db et assurez-vous qu’il sera accessible à mongod en donnant les permissions nécéssaires: \$ sudo chmod 777 /data/db.
Ensuite, vous devriez être en mesure de lancer le serveur mongod, et de vous y connecter à l’aide du client mongo, depuis une autre session de terminal. (cf étape suivante de l’exercice)
Dans une session de terminal, utiliser le client “mongo Shell” pour vérifier que la base de données est bien accessible. La commande show dbs devrait afficher une liste de bases de données, puis pressez Ctrl-C pour quitter le client.

De retour dans votre projet Node.js, installer le package mongodb avec npm, et vérifier qu’il a bien été ajouté au fichier package.json du projet.

Créer un programme dates.js qui se sert du package mongodb pour se connecter à la base de données créée à l’étape 1. (cf Connecting)

Note: Vous pouvez ignorer le message disant que la méthode de connexion est dépréciée. Par contre, votre programme devrait pouvoir s’exécuter sans erreur.

Après avoir vérifié que \$ node dates.js s’exécute sans erreur, modifier dates.js pour qu’il affiche la liste des documents de la collection dates dans la sortie standard. (cf Read methods)

Note: Sachant que nous n’avons pas encore ajouté de documents dans cette collection, la liste de documents doit être un tableau vide.

Modifier dates.js à nouveau pour ajouter un document { date: new Date() } dans la collection dates, avant l’affichage des documents. (cf Inserting documents)

Créer une nouvelle “release” dans votre dépôt: \$ git tag v2.1.

Sauvegarder votre projet dans un dépôt distant. (vous pouvez utilisez le même que celui de la partie précédente)

Une fois que vous aurez terminé cet exercice, merci d’aider vos camarades qui auraient des difficultés.

Exercice 2 - Stockage de l’historique dans MongoDB
Le but est:

de tenir un historique des messages envoyés au point d’accès POST /chat (cf dernier exercice de la partie précédente) et de leurs réponses, dans une collection MongoDB,
et de donner accès à cet historique via deux nouveaux points d’accès: GET /messages/all et DELETE /messages/last.
Exemples de conversation / cas d’usage:

$ curl -X POST --header "Content-Type: application/json" --data "{\"msg\":\"ville\"}" http://localhost:3000/chat répondra “Nous sommes à Paris” (comme dans le dernier exercice de la partie précédente)
$ curl -X GET http://localhost:3000/messages/all affichera l’historique des conversations (messages de l’utilisateur et réponses du chat-bot), tel que décrit ci-dessous, y compris après redémarrage du serveur
\$ curl -X DELETE http://localhost:3000/messages/last supprimera le dernier échange de l’historique (message de l’utilisateur + réponse du chat-bot)
Pour cela, nous allons:

nous connecter à la collection “messages” de la base de données “chat-bot”, puis y lire et écrire des documents JSON possédant trois propriétés:
\_id (type: ObjectId) contiendra un identifiant généré automatiquement par MongoDB pour chaque message,
from (type: string) contiendra le nom de l’émetteur du message, (ex: bot ou user)
msg (type: string) contiendra le contenu du message. (ex: demain = Mercredi)
enregistrer chaque message de l’utilisateur et du chat-bot dans la collection “messages” de notre base de données MongoDB;
ajouter les points d’accès (routes) GET /messages/all et DELETE /messages/last, permettant respectivement de retourner un tableau JavaScript contenant tous les messages dans l’ordre chronologique, et de supprimer le dernier échange (message de l’utilisateur + réponse du chat-bot) de l’historique.
Description de l’affichage de l’historique des conversations
Voici ce que devrait retourner le serveur si on requête GET /messages/all après avoir suivi le cas d’usage ci-dessus:

[
{
from: 'user'
msg: 'demain',
},
{
from: 'bot'
msg: 'Demain: Mercredi',
}
]
Objectifs
Fonctionnel: Le serveur implémente bien le cas d’usage fourni et respecte le format d’affichage décrits ci-dessus.
Lisibilité: 140 lignes de code max, utilisation de async/await pour tous les appels asynchrones.
Structure: Le code source du projet doit être disponible dans un dépôt git public, et celui-ci ne doit pas contenir plus de 5 fichiers. (dont server.js, package.json et README.md)
Accessibilité: Votre README.md doit décrire les 3 commandes (max.) nécessaires pour télécharger et faire fonctionner ce serveur depuis une autre machine.
Production: À ce stade, vous n’aurez pas besoin de déployer ce serveur en production.
Cet exercice s’appuie à la fois sur le code écrit lors de la partie précédente, et sur le code écrit dans l’exercice 1 (ci-dessus).

Libre à vous d’enregistrer vos modifications dans un nouveau dépôt distant, ou de compléter le dépôt de la partie précédente (à condition que vous ayez bien créé un tag pour garder une trace de la version précédente de votre serveur).

Étapes proposées
Modifier server.js pour qu’il se connecte à la base de données “chat-bot”.
Implémenter et tester le point d’accès GET /messages/all. (il devrait retourner un tableau vide)
Faire en sorte que ce point d’accès retourne l’historique des conversations => Enregistrer les messages de l’utilisateur et les réponses du chat-bot dans la collection messages.
Implémenter le point d’accès DELETE /messages/last, et vérifier à l’aide d’une requête à GET /messages/all qu’il fonctionne bien comme prévu.
Créer une nouvelle “release” pour garder une trace de cette version du serveur dans votre dépôt: \$ git tag v2.2.
Exercice 3 - API et base de données en production
Le but de cet exercice est de mettre le serveur API développé ci-dessus en production, afin qu’il soit accessible en permanence et à quiconque sur internet.

Objectifs
Fonctionnel: Même fonctionnalités que l’exercice précédent.
Lisibilité: 80 lignes de code max, utilisation de async/await pour les appels asynchrones.
Structure: Le code source du projet doit être disponible dans un dépôt git public, et celui-ci ne doit pas contenir plus de 5 fichiers. (dont server.js, package.json et README.md)
Accessibilité: Votre README.md doit décrire les 3 commandes (max.) nécessaires pour télécharger et faire fonctionner ce serveur depuis une autre machine.
Production: Le serveur et sa base de données sont accessible sur Internet.
ℹ️ Rendu: Il faudra fournir l’URL du dépôt dans lequel votre code est disponible, ainsi que l’URL à laquelle l’API est accessible sur internet.

Libre à vous d’enregistrer vos modifications dans un nouveau dépôt distant, ou de compléter le dépôt de la partie précédente (à condition que vous ayez bien créé un tag pour garder une trace de la version précédente de votre serveur).

Étapes proposées
Enregistrer l’URL d’accès à votre base de données MongoDB dans une variable d’environnement de votre application sur Heroku: MONGODB_URI.
Modifier server.js pour qu’il parvienne à se connecter à cette base de données, que celui-ci s’exécute en production ou en local, grâce à cette variable d’environnement.
Documenter les points d’accès de votre API dans README.md, afin que d’autres utilisateurs comprennent rapidement comment l’utiliser, que ce soit en production ou localement.
Créer une nouvelle “release” pour garder une trace de cette version du serveur dans votre dépôt: \$ git tag v2.3.