Spotify API Emotion Music App – Moodify

Overview

Moodify maps user mood to recommendation profiles and returns playable content using Spotify APIs. The main challenge was balancing personalization with API reliability. Recommendation quality depends on both mood mapping and Spotify data availability, so the system needs deterministic fallbacks when specific seeds are sparse or restricted by market availability.

I designed the product with a session-first flow: connect account, choose mood, review generated tracks, and refine with quick controls. This structure keeps the app intuitive while capturing enough feedback to improve future recommendations. The key technical focus was reducing response lag after mood selection, because latency directly impacts whether the experience feels expressive or mechanical.

Problem

Most music apps prioritize popularity and listening history, which works for passive discovery but often misses short-term emotional context. Users may want music for focus, decompression, or motivation right now, not another replay of long-term taste patterns. Generic recommendations can feel disconnected during those moments.

Emotion-aware systems often fail because they overfit to weak signals or ignore authentication and data constraints. With Spotify integrations, token expiration, scope restrictions, and rate limiting can break flows unexpectedly. The core problem was to deliver mood-aware output while handling OAuth lifecycle complexity and third-party API variability in production-like conditions.

Approach

I built a deterministic mood-to-feature mapping layer that translates mood states into Spotify recommendation parameters such as valence, energy, acousticness, and tempo ranges. This mapping is transparent and tunable, so behavior can be adjusted without retraining a model. For ambiguous inputs, the service blends mood defaults with recent listening vectors to avoid extreme outputs.

Authentication uses Spotify OAuth 2.0 authorization code flow with secure token refresh handling. Access tokens are short-lived and refreshed server-side, never exposed in persistent client storage. I added cache-aware request shaping and response normalization so front-end render paths stay fast even when Spotify responses are partial or inconsistent.

Architecture

Moodify follows a frontend-backend integration model with strict separation between user interface state and token-sensitive operations. The frontend handles interactions, while backend endpoints own Spotify API calls, token refresh, retry policy, and recommendation assembly. This structure improves security and keeps auth edge cases centralized.

To stabilize latency, I combined short-lived caching with fallback generation rules. Frequently requested recommendation templates are memoized for a limited window, while user-specific outputs still respect fresh account context. The result is fast first-response time without serving stale personalization for too long.

• - Next.js/React UI for mood selection, recommendation list, and playback intent actions.
• - Node.js API layer for Spotify OAuth exchange, refresh token logic, and scoped API requests.
• - Spotify Web API integration for recommendations, top tracks, and playlist metadata.
• - Redis cache for short TTL recommendation payloads and reduced repeated API calls.
• - PostgreSQL table for session-safe preference snapshots and product analytics events.
• - Background refresh routines to pre-warm mood templates and smooth response spikes.
• - Dockerized local stack and Vercel deployment for frontend delivery and preview testing.

What I Built

The implementation centered on reliability under real OAuth constraints. I built the complete auth lifecycle, including account connect, token storage policy, refresh strategy, and graceful failure handling when users revoke scopes. Every mood request path checks token validity first, then proceeds through recommendation generation with bounded retries.

On the product side, I built a compact interface for fast decisions: select a mood, inspect recommendations, and trigger alternatives if the first set does not fit. This avoids overloading users with controls while still allowing enough steering for subjective preferences. I also instrumented response timings to measure API performance improvements over time.

• - OAuth 2.0 authorization code integration with secure callback handling and token rotation.
• - Mood selector UX with deterministic mapping to Spotify recommendation parameters.
• - Recommendation endpoint with fallback seeds when Spotify returns sparse or blocked content.
• - Rate-limit-aware request scheduler and bounded retry logic for unstable API responses.
• - Session-aware caching strategy that reduced repeat recommendation latency significantly.
• - Playback context panel showing track metadata, artist links, and quick regeneration controls.
• - Instrumentation for latency, failure rate, and recommendation acceptance interactions.

Challenges & Tradeoffs

Token lifecycle issues were the most common operational failure mode. Access tokens can expire mid-session, and refresh tokens can become invalid if users change account permissions. I implemented explicit re-auth prompts and minimal retry loops to avoid silent errors. This improved trust because users saw clear recovery paths instead of broken states.

Another tradeoff was emotional precision versus interpretability. A heavier ML model could potentially infer finer states, but it also adds opacity and maintenance cost. I prioritized transparent mapping with controlled heuristics so outputs remain debuggable. This made the system easier to tune and explain, while still delivering recommendation quality that users considered meaningfully mood-aware.

Results

Moodify reached a stable product state where recommendation generation remained responsive under normal load and common Spotify API edge cases. Directionally, users reported faster discovery for intent-driven listening sessions compared with default algorithmic feeds. The fallback pipeline prevented hard failures and preserved flow continuity.

From an engineering perspective, the project improved my API integration discipline. I developed stronger patterns for secure OAuth handling, resilient third-party orchestration, and latency-focused backend design. The final architecture is reusable for other personalization systems where external APIs introduce uncertainty but UX still demands immediacy.

Tech Stack

• React
• Next.js
• Node.js
• Spotify Web API
• OAuth 2.0
• Redis
• PostgreSQL
• Docker
• Vercel

Moodify uses React/Next.js on the client, Node.js for token and API orchestration, Spotify Web API for music data, Redis for short-lived caching, and PostgreSQL for preference and telemetry records. Where needed, Python utilities supported experimentation around mood labeling and offline parameter validation.

Deployment is optimized for quick iteration: preview environments validate auth callback behavior, and production uses separate credentials with restricted scopes. Containerized local development mirrors production dependencies so OAuth and cache interactions are tested consistently before release.

Links

Use the source reference for endpoint patterns, OAuth flow handling, and recommendation fallback logic. The live demonstration and this case study are intended to show both product behavior and architecture decisions.

If you are building recommendation systems with third-party APIs, reach out through the contact page for implementation or performance consulting.