La technologie que nous avons décidé d'adopter pour le Backend est Django, pour plusieurs raisons. La plus importante est sa puissante capacité d'intégration avec les autres technologies de notre stack. En effet, Django dispose notamment d'un ORM intégré ^[2] pour gérer nos bases de données PostgreSQL, d'un outil natif d'authentification, et de la librairie Graphene ^[1] permettant de travailler efficacement et rapidement avec GraphQL. Django apporte également de la structure et des conventions, permettant de maintenir notre code rigoureux afin de le porter à échelle.

Django est un des leaders en termes de backend, et sa simplicité d'utilisation nous permet de bénéficier d'une meilleure efficacité dans les étapes du développement. Comparé aux autres technologies côté serveur, nous y avons trouvé une majorité d'avantages, mais il est également important de mentionner quelques inconvénients :

• Par rapport à ExpressJS, Django rajoute de la complexité car il nécessite d'ajouter un langage de programmation à la stack (car le frontend emploie JavaScript), et dispose également d'une communauté moindre comparée à celle d'Express. Cependant, la philosophie minimaliste d'Express ne convient pas forcément à notre use case, là où Django est un réel avantage en termes d'intégration. La structure que nous amène Django est également un point positif qui nous a écarté d'Express ^[4] .
• Ruby on Rails aurait également pu nous apporter des avantages, grâce à sa rapidité de développement très intéressante. Cependant, son manque de flexibilité et ses faibles performances nous ont amenés à nous tourner vers Django, qui est une meilleure alternative à ce niveau ^[5] .

La question de la technologie de stockage de données s'est rapidement posée, et le problème initial fut le choix entre une base de données de type relationnel et une base de données non-relationnelle. Nous avons rapidement opté pour le premier choix, car notre base de données sera amenée à être interrogée par des requêtes complexes, nécessitant une intégrité stricte des données, qui sont des avantages typiques des bases de données relationnelles ^[22] . En échange, nous perdons les avantages du non-relationnel, notamment la flexibilité et la capacité de traitement de gros flux d'informations.

Une fois le type relationnel sélectionné, il a fallu choisir entre les différentes technologies. À notre échelle, il était évident de choisir une technologie open-source, étant donnée l'échelle relativement moyenne de notre projet, ainsi que les moyens disponibles. Les choix que nous avons envisagés étaient :

• SQLite, le SGBDR le plus simple à mettre en place, excellent en termes de légèreté, facilité d'utilisation et portabilité. Cependant, ses capacités sont limitées, notamment par son absence de gestion d'utilisateurs et de mesures de sécurité ^[7] .
• MySQL, classé comme le SGBDR open-source le plus populaire ^[23] , bénéficie de ce fait d'un large écosystème. Il est conçu pour la simplicité, mais offre cependant des fonctionnalités de sécurité, et une rapidité excellente. MySQL présente toutefois quelques défauts, comme par exemple un manque de support pour certaines instructions SQL (telles que FULL JOIN ^[7] .
• PostgreSQL, la solution la plus avancée répondant à nos besoins. Même s'il est moins populaire, et plus lourd que MySQL, nous avons sélecionné ce SGBDR pour ses avantages en termes d'intégrité complète des données, de compatibilité accrue avec les instructions SQL, et de gestion des opérations complexes, ainsi qu'un support pour des écritures simultanées ^[7] .

Nous avons choisi React pour le frontend en raison de sa flexibilité ^[13] , de sa performance optimisée grâce à la DOM virtuelle ^[11] , et de son écosystème riche. React permet de créer des interfaces modulaires avec des composants réutilisables, ce qui est idéal pour une application dynamique comme la nôtre. De plus, React s'intègre parfaitement avec notre backend en Django et GraphQL ^[18] , permettant une communication fluide via des requêtes API modernes. La communauté massive et la documentation exhaustive de React facilitent également le développement et la résolution de problèmes.

Comparé à Angular, React est plus léger et plus adapté à des projets de taille moyenne, évitant la complexité inutile d'un framework complet ^[12] . Vue.js est une alternative simple, mais React offre un écosystème plus mature et une communauté plus large ^[12] . Enfin, bien que Svelte soit performant, il est moins établi que React, ce qui rend ce dernier plus fiable pour un projet à long terme ^[15] . React reste donc le meilleur choix pour notre plateforme de partage de musique.

Cependant, React présente quelques inconvénients. Sa courbe d'apprentissage initiale peut être intimidante, notamment à cause de concepts comme le JSX, les hooks et la gestion d'état, qui nécessitent un temps d'adaptation. De plus, React étant une bibliothèque et non un framework complet, il faut souvent recourir à des bibliothèques tierces pour des fonctionnalités avancées (notamment Apollo Client pour nos requêtes). Cela peut ajouter de la complexité à la configuration initiale du projet. Enfin, bien que React soit performant, une mauvaise gestion des composants ou des rendus inutiles peut entraîner des problèmes de performance dans des applications très complexes ^[16] .

L'approche hybride que nous avons choisi d'adopter a pour intérêt d'optimiser les performances de notre application en limitant le trafic circulant entre le front- et le back-end. En effet, puisque nous serons souvent amenés à récupérer des données dans des formats assez différents, nous estimons important de concentrer nos requêtes à l'API grâce à GraphQL. Nous disposerons alors d'un mécanisme nous permettant de récupérer uniquement les données nécessaires depuis un unique endpoint, réduisant ainsi la charge du serveur ^[21] .

Cependant, notre application est destinée à travailler avec des fichiers audio, qui ne sont pas efficacement traités par GraphQL (encodage en Base64, qui augmente la taille des fichiers). Nous avons donc décidé d'implémenter une API RESTful qui aura pour but de transmettre les fichiers audios. Cette approche rajoute un degré de complexité à notre projet, mais apporte une meilleure structure ainsi qu'une meilleure efficacité à l'application.

Nous avons mis en place des conteneurs Docker pour chaque section (frontend, backend, db) de notre application

La Dockerisation de nos services a demandé un certain temps à être configurée, mais nous estimons que cette approche nous apporte énormément de positif, principalement au niveau de la portabilité ^[19] . Puisque notre groupe utilise des systèmes d'exploitations différents, l'emploi des conteneurs nous permet de tous travailler dans les mêmes environnements isolés sans avoir besoin d'installer de librairies/packages localement, ce qui mène souvent à des problèmes de compatibilité.

Il existe des alternatives de conteneurisation, telles que Podman ou runC, qui peuvent apporter des avantages, comme par exemple davantage de légèreté ^[20], mais Docker reste tout de même une évidence, par la capacité d'intégration de tous ses services (Compose, Swarm, ...), et de son écosystème (notamment Docker Hub)