A shared facade
Centralising Navidrome access avoids rebuilding the whole integration in every client. The BFF becomes an additional component to host, observe and maintain; clients depend on its availability.
Technical study · personal project
YouggyDrome: one .NET API for web and Flutter
Listening to my self-hosted music library through a coherent web interface and Android app. I designed and developed this personal project, from the server facade to both clients.
ASP.NET Core 8Flutter / DartJavaScriptPostgreSQLSubsonic
Study checked on . Role: personal design and development.
Context and constraint
Navidrome already stores the music. The need is the listening experience: library, search, favourites, playlists and playback queue. The browser and Android need to share capabilities while Navidrome stays behind a server interface.
My scope
ASP.NET Core API, JavaScript web client, Flutter app, Subsonic integration and service tests. The work also includes authentication, media proxying and separating complementary data. Web and mobile code are published in two separate repositories.
Architecture
Web and Flutter clients call a shared API. This facade, or BFF, adapts Navidrome’s Subsonic API and proxies audio streams and artwork. PostgreSQL stores complementary podcast data and audiobook playback positions.
- 01
Web / Flutter
Interface, player state and navigation.
- 02
API ASP.NET Core
Session, common contract and media proxy.
- 03
Navidrome / PostgreSQL
Music library on one side, complementary data on the other.
Chosen trade-offs
Normalising external responses
The mobile client tolerates missing collections and variations in Subsonic response shapes. Models and deserialisation helpers isolate these details from the interface. This tolerance needs precise examples in tests.
Explicit client scope
A server capability does not automatically imply a finished interface in every client. Music playback, podcasts, audiobooks and media integrations need separate checks and their own delivery status.
Verification actually run
On 23 October 2026, the .NET service suite was run against the source project: 29 tests passed, no failures. It covers Subsonic request construction, response and error handling, and accepting or rejecting session tokens.
These tests verify covered behaviour in a development environment. They do not replace playback acceptance on devices, load testing or a security audit of the installation.
Public sources
Observable result: two clients use the same API boundary. This personal project illustrates design and verification without attributing performance or commercial results to a client.
A shared API for your tools?
Describe your web or mobile clients, connected systems and available access. Initial reply within 48 business hours, quote after scoping.