Une façade commune
Centraliser l’accès à Navidrome évite de réimplémenter toute l’intégration dans chaque client. En contrepartie, le BFF devient un composant à héberger, observer et maintenir ; sa disponibilité conditionne l’accès des clients.
Étude technique · projet personnel
YouggyDrome : une API .NET pour le web et Flutter
Écouter ma bibliothèque musicale auto-hébergée avec une interface web et une application Android cohérentes. J’ai conçu et développé ce projet personnel, de la façade serveur aux deux clients.
ASP.NET Core 8Flutter / DartJavaScriptPostgreSQLSubsonic
Étude vérifiée le . Rôle : conception et développement personnels.
Contexte et contrainte
La musique est déjà stockée dans Navidrome. Le besoin porte sur l’expérience de lecture : bibliothèque, recherche, favoris, playlists et file d’attente. Il faut partager les mêmes fonctions entre le navigateur et Android tout en conservant Navidrome derrière une interface serveur.
Mon périmètre
API ASP.NET Core, client web JavaScript, application Flutter, connexion à Subsonic et tests des services. Le travail comprend aussi l’authentification, le proxy des médias et la séparation des données complémentaires. Le code web et le code mobile sont publiés dans deux dépôts distincts.
Architecture
Les clients web et Flutter appellent une API commune. Cette façade, ou BFF, adapte l’API Subsonic de Navidrome et relaie les flux audio et les pochettes. PostgreSQL conserve les données complémentaires de podcasts et les positions de lecture des livres audio.
- 01
Web / Flutter
Interface, état du lecteur et navigation.
- 02
API ASP.NET Core
Session, contrat commun et proxy des médias.
- 03
Navidrome / PostgreSQL
Bibliothèque musicale d’un côté, données complémentaires de l’autre.
Compromis retenus
Des réponses externes à normaliser
Le client mobile tolère les collections absentes et certaines variations de forme des réponses Subsonic. Les modèles et les helpers de désérialisation isolent ces particularités de l’interface. Cette tolérance doit rester couverte par des exemples précis.
Des clients au périmètre explicite
Une fonction disponible dans le serveur n’implique pas automatiquement son interface sur chaque client. Lecture musicale, podcasts, livres audio et intégrations médias se vérifient séparément, avec leur propre état d’avancement.
Validation réellement exécutée
Le 23 octobre 2026, la suite des services .NET a été exécutée sur le projet source : 29 tests réussis, aucun échec. Elle couvre notamment la construction des requêtes Subsonic, le traitement des réponses et erreurs, ainsi que l’acceptation ou le refus de jetons de session.
Ces tests valident les comportements couverts dans un environnement de développement. Ils ne remplacent pas une recette de lecture sur les appareils, un test de charge ou un audit de sécurité de l’installation.
Sources publiques
Résultat observable : deux clients utilisent une même frontière API. Ce projet personnel donne un exemple de conception et de validation, sans chiffre de performance ou résultat commercial attribué à un client.
Une API commune pour vos outils ?
Décrivez vos clients web ou mobiles, les systèmes à connecter et les accès disponibles. Premier retour sous 48 h ouvrées, devis après cadrage.