Всем привет, дорогие читатели! Расскажу вам о том как сделать интернет-радио на «скорую руку» без особых хлопот.

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.

И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку?

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

«Мы передали им всю документацию, но они все равно постоянно отвлекают нас вопросами». Знакомо? В этой статье разбираем, почему классический сценарий передачи проекта в IT почти всегда ведет к хаосу. Почему код и документация — это лишь верхушка айсберга?

Привет, хаброжители! Представьте в самых общих чертах сценарий при старте нового проекта или доработке существующей системы. Команды собирают всевозможные артефакты для изучения контрактов систем, устанавливают контакты – круг заинтересованных лиц и т.д. Далее команды собираются на встречах, где договариваются о дальнейших шагах интеграции. В идеальном случае архитекторы команд начинают взаимодействие с отрисовки контекстов систем и потоков их взаимодействия. Но зачастую на практике обсуждаются только общие моменты интеграции, под протокол фиксируются общие вопросы и команды расходятся с надеждой на уточнения в перспективе. В таком случае команды ожидают ряд рисков и проблем при реализации решения.