One project.
Full focus.

What Problem The App Solves

A music collection looks simple until the data starts fighting back.

At first glance, a music collection looks simple. In reality, it is full of messy data:

• inconsistent file names
• imperfect metadata
• multiple spellings for the same artist
• collaborative credits embedded in one text string
• duplicates that are not obvious until the data is normalized

A simple file browser cannot solve those problems well. It can only display the mess.

MyMusicCollection was built to solve the deeper problem:

• make the collection trustworthy
• make the relationships meaningful
• make the result explorable

That means the system is designed not only to store music, but to understand it as connected data.

How The Project Started

The flashy part came later.

The project began with collection cleanup and ingestion.

The first challenge was to turn a real folder of music files into a structured system that could support:

• reliable imports
• duplicate detection
• clean metadata normalization
• album grouping
• artist resolution

That early phase matters because it reveals a core engineering habit: do the foundational work properly before building the flashy part.

The graph interface and discovery features only became possible because the collection was first modeled carefully and loaded into a real relational system.

The Core Architectural Idea

Two layers work together.

The project has two major layers that work together:

The system is powerful because these two layers support each other. One gives trustworthy local truth. The other gives broader context.

Why PostgreSQL Was Chosen

Relationships needed a real relational foundation.

PostgreSQL was the right foundation because this project is fundamentally about relationships.

The system needed:

• strong relational modeling
• durable structured storage
• flexible querying
• safe concurrent access
• room to grow from collection tables into richer discovery structures

This was never just a matter of "where do we store some files?".

The project needed a database that could support both exacting cleanup work and a larger connected model of artists, albums, songs, and graph relationships. PostgreSQL provided that balance of power, rigor, and flexibility.

Why Secret Management Was Treated Seriously

Infrastructure discipline was part of the engineering story.

One of the architectural signals in this project is that infrastructure discipline was treated as part of the engineering work, not as an afterthought.

That includes secret management.

Instead of treating credentials as something to scatter across scripts and local config, the project adopted a proper secret-management pattern so that the system could:

• keep credentials out of source code
• reduce duplicated setup logic
• support repeatable runtime behavior
• establish a reusable pattern for future projects

That decision matters because it reflects engineering judgment. The goal was not only to make the app work, but to make it work in a way that could scale and be maintained responsibly.

The Shared Utility Layer

Consistency was treated as a first-class engineering concern.

Another important design choice was to avoid re-implementing the same infrastructure logic in every script.

The project relies on a shared utility layer for things like:

• database access patterns
• secret retrieval patterns
• connection handling
• transaction handling
• logging and error capture

That may sound less exciting than the graph UI, but it is one of the strongest signals in the project. It means the codebase was shaped intentionally around consistency and reuse.

In practical terms, the project does not just contain features. It contains engineering patterns that can be reused in other work.

The Collection Pipeline

A staged pipeline keeps the data trustworthy.

The ingestion side of the project follows a clear progression:

1. inventory the collection
2. import the tracks
3. model the albums and collections
4. normalize artist text
5. split compound artist strings
6. resolve those strings into canonical entities
7. validate the result

This is important because it shows the system was not built on vague heuristics. It was built as a staged pipeline where each step has a defined responsibility.

That structure makes the system easier to trust, easier to debug, and easier to extend.

The Canonical Artist Layer

Text has to become entities.

One of the most important ideas in the project is that artist identity cannot be left at the level of raw text strings.

Real collections contain:

• aliases
• nicknames
• alternate spellings
• combined credits
• partial names

If the system cannot unify those, it cannot answer meaningful questions later.

The canonical artist layer solves that by separating:

• the raw strings found in the collection
• the cleaned and split tokens
• the stable entity records those tokens resolve to

That move from text to entity is what allows the rest of the system to behave like a real knowledge model rather than a glorified tag browser.

The Discovery And Harvester Story

This is where the project became more than a personal catalog.

Once the collection side was working, the project expanded into discovery.

This is where the application became more than a personal catalog. It started to gather and connect broader musical information through harvesters and hydrators.

Those components are responsible for:

• discovering songs from historical chart sources
• identifying artists from those songs
• enriching artist and work records from external sources
• building a graph that can be explored through the UI

This is the point where the project becomes a showcase of both data engineering and software design. The system is no longer simply storing music. It is building a knowledge structure around it.

Why The Project Uses Queue-Backed Workflows

Asynchronous workflows are part of the architecture story.

The external enrichment side of the project is intentionally separated from the core app logic through queue-backed workflows.

That design improves several things at once:

• work can be submitted and collected asynchronously
• long-running enrichment does not have to block the user experience
• source-specific logic can be isolated cleanly
• retry behavior and source pacing can be controlled more deliberately
• the system remains more resilient under backlog or failure conditions

This is one of the strongest engineering signals in the entire project. It shows that the system was designed not just to fetch external data, but to do so in a way that respects scale, separation of concerns, and operational sanity.

What The External Sources Contribute

Each source has a job.

Different external sources bring different kinds of value.

Some are better for structured music identity and relationships. Some are better for listener context, similarity, and discovery. Some are better for narrative or historical context.

The important design point is that these sources are not there as decoration. Each one contributes something specific to the user experience and the data model.

Together, they help the app become:

• more useful
• more interesting
• more explainable
• more memorable

The Graph As A Product Decision

The shape of the relationships became the product.

At some point the project crossed an important threshold.

The interesting part of the data was no longer the list. It was the shape of the relationships.

That is why the UI evolved into a graph-first experience instead of staying a traditional library browser.

The graph interface supports:

• exploration
• rediscovery
• pivoting across people, albums, and songs
• chart-era browsing
• contextual fact display
• movement through connected musical relationships

That product decision reflects a deeper truth about the system: the point is not just to store facts. The point is to make those facts navigable in a way that feels human and intuitive.

Why The Interface Matters

The interface is where the engineering becomes legible.

The graph UI is not just presentation polish layered on top of data.

It is where the engineering work becomes understandable to a visitor.

The interface helps demonstrate that the project contains:

• careful data modeling
• deliberate hierarchy and navigation thinking
• meaningful source integration
• an understanding of how users actually remember and explore information

The result is a product that feels playful and surprising on the surface, while resting on a very serious foundation underneath.

What This Project Shows About The Engineering

This is more than a music project.

For a technically curious visitor, MyMusicCollection demonstrates several useful things at once:

• a strong relational mindset
• practical database design
• disciplined cleanup and normalization thinking
• willingness to build shared infrastructure instead of copy-pasting patterns
• architectural thinking around source integration and asynchronous workflows
• product design that makes technical work visible and engaging

In other words, it is not only a music project.

It is evidence of the ability to:

• design a schema
• structure a pipeline
• manage ambiguity in real-world data
• connect multiple systems cleanly
• keep the engineering coherent as the product grows

What Makes The Project Distinct

The full path is what makes it different.

Many projects can show a user interface. Many projects can show some database work. Fewer projects show the whole path from raw messy input to a polished, relationship-driven experience.

That full path is what makes MyMusicCollection distinctive.

It demonstrates:

• product ambition
• engineering follow-through
• architectural restraint where needed
• and the patience to turn a practical problem into a durable system

The Best Short Public Description

The shortest accurate public version

If someone wants the shortest accurate version for public display, it is this:

MyMusicCollection began as a serious effort to clean up and model a personal music collection, then grew into a graph-based discovery system that showcases database design, data engineering, source integration, and product thinking in one coherent application.

Related

Source and usage notes

• Internal long-form source: how_mymusiccollection_works.md
• Product-facing use: public site "How It Works" page