Ce projet vise à développer l'API backend de l'application Snacks Analytics pour l'association Label[i]. Il s'agit du service centralisé de notre application web, conçu pour répondre à deux besoins principaux :

Pour les adhérents : Fournir toutes les informations en temps réel concernant les snacks proposés par l'association, notamment l'état des stocks et les prix.

Pour les gérants de l'association : Offrir un outil de pilotage complet pour suivre la rentabilité, analyser les variations de prix, gérer les factures et automatiser le suivi des flux financiers en intégrant notamment l'API SumUp.

Technologies

Les technologies utilisées pour ce projet sont :

Language

Autres

Installation

L'installation du projet peut se faire de deux manières :

Installation manuelle : Cloner le dépôt GitHub et installer les dépendances nécessaires

git clone ssh://git@git.labeli.org:2223/AlexLoup/Snacks-Analytics-backend.git
cd Snacks-Analytics-backend
npm install

L'API sera accessible à l'adresse http://localhost:5000 une fois le serveur démarré.

Utilisation

Pour lancer le projet en mode développement, utiliser la commande suivante :

npm run server

Contribution

Afin de contribuer au projet, veuillez suivre les étapes suivantes, celle ci peuvent paraitre assez strictes mais elles permettent de garder une bonne qualité de code et une bonne organisation du projet.

Branche principale : La branche principale du projet est main (dites branche de production). Toutes les modifications doivent être fusionnées dans cette branche via des demandes de pull request donc le code devra être soumis à une revue avant d'être intégré.
Branches de développement : La branche de développement est dev (dites branche de développement). Toutes les nouvelles fonctionnalités, corrections de bugs et autres modifications doivent être développées dans des branches distinctes créées à partir de dev. Le nom des branches doit suivre le format suivant : feature/nom-de-la-fonctionnalité, bugfix/description-du-bug, hotfix/description-du-hotfix.
Pull Requests : Une fois les modifications terminées dans une branche de développement, créer une pull request pour fusionner les modifications dans la branche develop. Assurez-vous que la pull request est examinée et approuvée par au moins un autre membre de l'équipe avant de procéder à la fusion.
Tests : Avant de fusionner une pull request, assurez-vous que toutes les modifications ont été testées et qu'elles n'introduisent pas de régressions. Si des tests automatisés sont en place, assurez-vous qu'ils passent tous avec succès.
Mises à jour de la documentation : Si les modifications apportées nécessitent une mise à jour de la documentation, assurez-vous que cela est fait avant de fusionner la pull request.
Revue de code : Encouragez les membres de l'équipe à revoir le code des autres avant de fusionner les pull requests. Cela aide à maintenir la qualité du code et à partager les connaissances au sein de l'équipe.
Gestion des conflits : Si des conflits surviennent lors de la fusion d'une pull request, résolvez-les en local avant de procéder à la fusion. Assurez-vous que le code résultant est testé et fonctionne correctement.

Pour toute question ou problème, n'hésitez pas à contacter l'équipe de développement ou à ouvrir une issue sur le dépôt GitHub.

Formatage des commits : Pour la création de commits, veuillez suivre la convention de nommage suivante pour assurer une meilleure lisibilité de l'historique des commits :

<type>(<scope>): <subject>

type : Le type de changement effectué. Les types couramment utilisés sont :
- feat : Une nouvelle fonctionnalité
- fix : Une correction de bug
- docs : Des modifications de la documentation
- style : Des modifications de style (formatage, espaces, etc.) qui
- update : Une mise à jour du code existant
- refactor : Un changement de code qui n'ajoute ni fonctionnalité ni corrige de bug
- test : Ajout ou modification de tests
- n'affectent pas le code
scope : La portée du changement (par exemple, le nom du module ou de la fonctionnalité affectée). Cela peut être omis si ce n'est pas pertinent.
subject : Une brève description du changement (utilisez l'impératif, par exemple "ajoute la fonctionnalité X" ou "corrige le bug Y").

PS : Il est conseillé d'ajouter un 2ème paragraphe dans la description du commit pour expliquer le pourquoi du changement si nécessaire.

Exemple de commit :

git commit -m "update (README): rework complet" -m "Ecrire complète du README.md pour expliquer comment contribuer au projet"

Licence

Le projet ci présent est sous licence MIT. La licence MIT est une licence permissive qui permet une grande liberté d'utilisation, de modification et de distribution du code source. Voici un résumé des principales caractéristiques de la licence MIT :

Permission est accordée à quiconque d'utiliser, de copier, de modifier, de fusionner, de publier, de distribuer, de sous-licencier et/ou de vendre des copies du logiciel.
Le logiciel est fourni "tel quel", sans garantie d'aucune sorte, expresse ou implicite, y compris mais sans s'y limiter les garanties de qualité marchande, d'adéquation à un usage particulier et de non-contrefaçon.
Les avis de copyright et de licence doivent être inclus dans toutes les copies ou parties substantielles du logiciel.

Auteurs

Alexandre Lou-Poueyou - a.loupoueyou@icloud.com

N'hésitez à compléter la liste des contributeurs