Backend for Frontend Pattern: When One API Doesn't Fit All Clients

Your mobile app needs a lightweight payload with offline support. Your web dashboard wants rich, nested data for complex visualizations. Your partner API requires strict versioning and backward compatibility guarantees. You've been cramming all these requirements into a single API, and the codebase is becoming a maze of conditional logic and client-specific hacks. It starts innocuously. A ?include=details query parameter here. A X-Client-Type header check there. Before long, your API handlers are littered with if (clientType === 'mobile') branches, your response schemas have grown fifteen optional fields that only one client uses, and your backend team dreads every frontend feature request because it inevitably means more conditional complexity in shared endpoints. The real cost isn't just code ugliness—it's velocity. Mobile teams wait on backend changes that web doesn't need. Web teams inherit breaking changes from mobile optimizations. Your API documentation becomes a choose-your-own