Лет десять я пытался привести свои дела в порядок и всё это время наступал на одни и те же грабли. Заводил борды с задачами в Notion, они бодро наполнялись первые пару недель, потом помирали, а разгребать мёртвый борд руками настолько больно, что туда перестаёшь заходить. Складывал поток сознания в заметки, в них удобно записывать, но найти нужное потом всегда проблематично. Писал в Saved Messages в Телеге. Лучшее место, чтобы выгрузить голову за десять секунд, и худшее, чтобы через неделю там что-то отыскать.

Общее у всех попыток было одно: фиксация есть, разбора нет, а потом всё молча умирает под собственным грузом накопленных дел.

Ответ, почему так происходит, я нашёл у Стивена Кови. Его книгу «7 навыков высокоэффективных людей» я прочитал давным-давно и с тех пор являюсь её амбассадором, но у Кови есть и отдельная книга про планирование, «Главное внимание главным вещам». Там он раскладывает все подходы к организации дел на четыре поколения.

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя.

А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.