Is My Spotify Web Player Broken?
57k minutes of listening taught me that it’s not a bug, it’s architecture. Let’s talk about why your apps act differently on every device.
My Spotify Wrapped just called me out: 57,000 minutes of music last year. That’s roughly 40 days of straight audio. I know, I might be a bit crazy, but music is the literal soundtrack to my day.
Because I’m so attached to my playlists, I’ve noticed something weird. I use Spotify everywhere: the web player in a browser tab, the desktop app while I’m working, and the mobile app when I’m out and about. But they aren’t the same.
The web player feels... restricted. The audio quality isn’t quite as crisp, the shuffle algorithm feels a bit “lazy,” and there’s no offline mode. Initially, I just thought, “Eh, it’s just a browser tab, it’s probably a memory and bandwidth thing.” But as I dug deeper, I realized there’s a massive architectural reason for this.
How does one single backend handle the same user so differently across three platforms?
That curiosity led me to the concept of the BFF. And no, I don’t mean “Best Friends Forever,” though, for a developer, it is. I’m talking about Backend for Frontend.
The Starting Point: General-Purpose APIs
Before things got fancy, most companies relied on a General-Purpose API Backend. Think of this as the “one size fits all” approach. You build a single server-side API and keep adding functionality to it as you roll out new platforms, such as mobile or desktop.
At first, this seems efficient, one API for everything! But it quickly becomes a mess because a mobile experience is drastically different from a desktop one.
Why the “General Backend” didn’t work:
Different Needs: Mobile devices have less screen real estate and require fewer calls to conserve battery and data plan usage.
Feature Bloat: As you add mobile-specific logic to a general API, it takes on too many responsibilities.
The Bottleneck: The single API becomes a massive bottleneck for releases because every team (Web, Android, iOS) is trying to change the same code at the same time.
Team Friction: Frontend teams end up stuck waiting on a separate “API team” to balance priorities and make changes.
What is BFF (Backend for Frontend)?
The BFF pattern says: Stop trying to make one API please everyone.
Instead of a general API, you have one backend tailored explicitly to a single user experience. Conceptually, the user-facing app is split into two parts: the client-side app on your device and the server-side BFF inside the perimeter.
How BFF Operates:
Client Request: Each client (mobile, web, etc.) communicates directly with its own dedicated BFF layer.
BFF Layer: This layer pulls data from various microservices, formats it precisely as the specific client needs, and sends it back.
Microservices Interaction: The BFF acts as an orchestrator, communicating with the core backend services (such as user data or orders) so the frontend doesn’t have to.
Why the Big Players Use It
Netflix and Spotify use this to make things feel seamless. When you view a movie on your phone, your Mobile BFF prioritizes low-resolution thumbnails to save data. But when you switch to a Fire TV Stick or a laptop, that TV/Desktop BFF kicks into high gear, pulling the highest quality video and audio available.
The Key Advantages:
Optimized Performance: It reduces “over-fetching” (fetching too much data) and “under-fetching” (fetching too little data).
Autonomy: The team building the UI usually owns the BFF as well. They can iterate and release features fast without waiting on other teams.
Simplified Structure: Each BFF is smaller and focused only on its specific client.
Security: BFFs can handle strict security like token validation, keeping the core services safer.
Things We Need to Watch Out For (The Disadvantages)
It’s not all perfect. There are some trade-offs to keep in mind:
Maintenance: Managing multiple BFFs increases complexity in monitoring and scaling.
Duplication: You might end up with similar code across different BFFs. Some duplication is okay to avoid tight coupling, but it’s a fine line.
Logic Trap: Avoid putting complex business logic in the BFF; keep it focused on formatting and orchestration.
Final Notes
Learning about BFF made me realize that the “limitations” I found in Spotify Web weren’t just browser bugs. They were intentional design choices. It’s about giving the user exactly what they need, for the device they are holding, right now.
References:
Sam Newman - “Backends For Frontends”
Medium - “Understanding Backend for Frontend (BFF) Architecture”
Nayeem Islam - “BFF: Building Faster, Better, and Customized User Experiences”