вас никто не затыкает. вам привели много объективных и адекватных примеров того, почему так сделано у нас и как можно сделать по другому, вы упорно доказываете ту точку зрения, которая даже к теме статьи не относится. что мне еще остается вам сказать? я вижу в ваших комментариях лишь попытку доказать свою правоту любыми способами, вы манипулируете фактами и подкидываете разные медиа материалы, которые якобы подтверждают ваши слова, но только они вообще не метчатся с идеей статьи.
что мне остается делать? вероятно, не стоит просто поддерживать ваш энтузиазм своими ответами, в попытке объяснить свою позицию и суть неуместности ваших набросов. чтож, так и поступлю. всего вам доброго!
Я лишь показал схематично сложность системы. Это архитектура 2024, много легаси наша команда переписала на более чисты архитектурные патерны. Да и в принципе, у сервиса 19-ти летняя история, много технических команд сменилось, наша команда существует 3,5 года и благодаря нашим усилиям, инфраструктура систем и приложений работает безотказно для 18M ежедневных пользователей.
А вам предлагаю все же успокоиться и перестать искать все новый и новые попытки захейтить сервис, к которому испытываете неприязнь. Оставьте свои личные психологические травмы для психотерапевта и не вываливайте их в комментариях на технической площадке. Спасибо!
Можно и так, вопрос конкретной задачи и дальнейшего развития сервисов. У нас получилось много таких кейсов, где приходилось собрать данные из разных апишек или как-то изменять структуры данных для разных клиентов. Мы решили, что отдельный сервис нам поможет с этим, так и получилось.
В свою очередь, бэкенд из большого и тяжелого монолита получил возможность трансформироваться в несколько десятков сервисов, которые теперь отвечали за конкретную задачу, а не за то, чтобы сходить в разные базы данных и учесть потребности каждого из клиентов, которые очень быстро менялись с точки зрения визуализации интерфейса.
Ваш вариант похож скорее на реализацию Public API, который могут использовать как собственные клиенты, так и партнеры. Но это API должен быть достаточно стабилен и клиенты должны подстваиваться под него, а не он под клиентов. Ключевое преимущество BFF в том, что он меняется так же часто, как и перестраивает свой интерфейс клиентское приложение.
Не отрицаю. Если команда решает внедрять BFF, то она должна понимать, что BFF - это отдельный сервис, который требует поддержки и ресурсов. Если дополнительных ресурсов нет нет, то идти в разработку этого сервиса нет смысла.
Позвать архитектора из пункта выше, который знает как внутри кода разбить отвественность, а не раскидывать все по микросервисам
Вы серьезно? Архитектор должен ходить в код разработчиков и помогать разработчикам декомпозировать их код? а зачем тогда разрабочики?
Например почитать книжки, базу так сказать, а не плодить базы данных и поддерживать консистентность за счет кода приложения?
Вы таки не ответили на вопрос: в чем противоречия и неконсистентность, когда у вас конкретный сервис отвечает за конкретную задачу?
Не знал что из-за UX иследований может просто зависать приложение, показывать кучу рекламы подряд и еще кучу кучу всего что содержить в себе явно программный характер, а не внешний.
Искренне рад, что теперь вы знаете, что показы рекламы происходят за счет реализации рекламомест по заказу бизнеса, который за счет этой рекламы оплачивает ЗП своим сотрудникам и сервера, на которых крутятся приложения и благодаря которым вы этим сервисом пользуетесь.
Размываете ответственность, плодите зоопарк технологий
Откуда вы это взяли? JS разработчики пишут на JS, бекенд разработчики пишут на своих языках. Каждый занимается своим делом, ответственность четко регламентирована и определена.
либо говорите технически чем монолит хуже, желательно с цифрами, все же должны (кроме меня) понимать очевидное приемущество микросервисов, вот и цифры бы показали его.
А вы обратили внимание на название статьи? И точно ее прочитали полностью или все же остановились на 4-м абзаце? Почитайте, правда. Будет полезно. Я там говорю, что и сейчас используется монолит. Но есть кейсы, когда его использование мешает быстрому развитию и масштабированию продукта.
Подстраиваться под них и закрывать глаза на свои технические знания - ну это торговля задом)
Мне искренне жаль, что у вас так болит эта тема, не знаю какое зло и кто вам причинил. Мы тут про наш кейс вам говорим и ни чем не торговали, никаким менеджерам не угождали, а делали так, чтобы наша команда и сервис могли развиваться дальше. Надеюсь на этом мы поставим точку в неконструктивных обсуждениях вопроса.
возможность закидать деньгами проблему, программисту дал отговорку - вместо внятной базы данных у нас куча баз данных, вместо внятного кода у нас куча сервисов, ответственность раскидана и размыта максимально, можно и работать потихоньку.
Разве только монолит дает чистоту архитектуры? Почем при микросервисной архитектуре мы не можем работать качественно? И что делать при увеличении монолита до масштабов, при которых любая доработка превращается в месяцы? Что делать по-настоящему большим сервисам с миллионами пользователей и петабайтами данных? Как масштабировать базу данных, которая выросла до неподдерживаемых размеров?
На лицо сравнение теплого с мягким.
софт не становится качественно лучше для пользователей
А тут точно проблема в инженерных подходах исключительно или есть ответственность продуктовой проработки и UX-исследований? Разве качество работы софта меряется исключительно наличием у этого софта микросервисной или монолитной архитектуры?
И тогда почему подход, в котором возможно строить что-то по-настоящему большое и масштабируемое, работающее быстро и способное выдержать хайлоад нагрузки не является эволюцией того, что устарело с точки зрения инженерных подходов и не подходит для использования с современном мире?
Вижу здесь переживания по тому, что мир изменился, а вы пока еще нет.
Да я и не претендую на звание "лучшего архитектора систем". Я вообще руководитель клиентской разработки, в первую очередь. Приведенные здесь схемы не претендуют на правильность их проектирования в работе, это картинки из презентации моего доклада, не более того. Статья про общее понимание паттерна BFF фронтенд-разработчиками. Допускаю, что некоторые формулировки здесь упрощены. Буду благодарен, если дополните более развернутыми комментариями и подсветите то, что я не дораскрыл, на ваш взгляд.
И да, и нет. Бывают кейсы, когда через BFF пускают все запросы с клиента и он действительно превращается в api gateway на стероидах. Я придерживаюсь мнения, что BFF нужен только в тех случаях, когда для конкретного элемента интерфейса нам необходимо получить данные из нескольких API бэкенда. Если подобный элемент мы отрисовываем часто и бизнес-логика приложения по агрегации данных начинает пухнуть, потому что нам нужно писать много кода для подготовки данных на клиенте, такой запрос стоит оптимизировать и вынести на уровень BFF. Здесь же мы можем снизить нагрузку на бэкенд, добавив кеширование на уровне BFF слоя. Ну и ходить напрямую от BFF до бекенда внутри закрытой сети дешевле и быстрее, чем ходить через балансер и провайдеров на каждый чих.
API Gateway должен заниматься маршрутизацией запросов и делать это очень быстро. Нагружать его логикой агрегации данных — не лучшее решение.
Я же не советую всем BFF-сервисы клепать, напротив, у меня есть блок, в котором я пишу когда BFF вообще не нужен. Но подходы с монолитами и вправду часто не дают компаниям быстро развиваться. Поэтому и появился этот архитектурный паттерн и его нужно уметь правильно готовить. По идее, статья об этом.
там ниже даже ссылка на мою статью есть про BFF, так что я не скрываюсь.) благодарю, что подсветили
а подписку пробовали подключать? она вроде совсем рекламу отключает
вас никто не затыкает. вам привели много объективных и адекватных примеров того, почему так сделано у нас и как можно сделать по другому, вы упорно доказываете ту точку зрения, которая даже к теме статьи не относится. что мне еще остается вам сказать? я вижу в ваших комментариях лишь попытку доказать свою правоту любыми способами, вы манипулируете фактами и подкидываете разные медиа материалы, которые якобы подтверждают ваши слова, но только они вообще не метчатся с идеей статьи.
что мне остается делать? вероятно, не стоит просто поддерживать ваш энтузиазм своими ответами, в попытке объяснить свою позицию и суть неуместности ваших набросов. чтож, так и поступлю. всего вам доброго!
они посчитали, в их инфраструктуре такое оказалось выгоднее. мы посчитали, в нашей инфре другие цифры и потребности.
Я лишь показал схематично сложность системы. Это архитектура 2024, много легаси наша команда переписала на более чисты архитектурные патерны. Да и в принципе, у сервиса 19-ти летняя история, много технических команд сменилось, наша команда существует 3,5 года и благодаря нашим усилиям, инфраструктура систем и приложений работает безотказно для 18M ежедневных пользователей.
А вам предлагаю все же успокоиться и перестать искать все новый и новые попытки захейтить сервис, к которому испытываете неприязнь. Оставьте свои личные психологические травмы для психотерапевта и не вываливайте их в комментариях на технической площадке. Спасибо!
Можно и так, вопрос конкретной задачи и дальнейшего развития сервисов. У нас получилось много таких кейсов, где приходилось собрать данные из разных апишек или как-то изменять структуры данных для разных клиентов. Мы решили, что отдельный сервис нам поможет с этим, так и получилось.
В свою очередь, бэкенд из большого и тяжелого монолита получил возможность трансформироваться в несколько десятков сервисов, которые теперь отвечали за конкретную задачу, а не за то, чтобы сходить в разные базы данных и учесть потребности каждого из клиентов, которые очень быстро менялись с точки зрения визуализации интерфейса.
Ваш вариант похож скорее на реализацию Public API, который могут использовать как собственные клиенты, так и партнеры. Но это API должен быть достаточно стабилен и клиенты должны подстваиваться под него, а не он под клиентов. Ключевое преимущество BFF в том, что он меняется так же часто, как и перестраивает свой интерфейс клиентское приложение.
И снова спасибо за здравый взгляд на ситуацию. Полностью с вами согласен.
Не отрицаю. Если команда решает внедрять BFF, то она должна понимать, что BFF - это отдельный сервис, который требует поддержки и ресурсов. Если дополнительных ресурсов нет нет, то идти в разработку этого сервиса нет смысла.
Хорошего вам дня!
Почитайте, все же, статью. Пока все комментарии в стиле "слышу звон, да не знаю где он", забуксовали на четвертом абзаце а потом начались додумывания.
Много буков, понимаю, но такой уж тут формат, приходится осиливать, чтобы конструктивно вести диалог.
не будущее, а настоящее
Вы серьезно? Архитектор должен ходить в код разработчиков и помогать разработчикам декомпозировать их код? а зачем тогда разрабочики?
Вы таки не ответили на вопрос: в чем противоречия и неконсистентность, когда у вас конкретный сервис отвечает за конкретную задачу?
Искренне рад, что теперь вы знаете, что показы рекламы происходят за счет реализации рекламомест по заказу бизнеса, который за счет этой рекламы оплачивает ЗП своим сотрудникам и сервера, на которых крутятся приложения и благодаря которым вы этим сервисом пользуетесь.
Откуда вы это взяли? JS разработчики пишут на JS, бекенд разработчики пишут на своих языках. Каждый занимается своим делом, ответственность четко регламентирована и определена.
А вы обратили внимание на название статьи? И точно ее прочитали полностью или все же остановились на 4-м абзаце? Почитайте, правда. Будет полезно. Я там говорю, что и сейчас используется монолит. Но есть кейсы, когда его использование мешает быстрому развитию и масштабированию продукта.
Мне искренне жаль, что у вас так болит эта тема, не знаю какое зло и кто вам причинил. Мы тут про наш кейс вам говорим и ни чем не торговали, никаким менеджерам не угождали, а делали так, чтобы наша команда и сервис могли развиваться дальше. Надеюсь на этом мы поставим точку в неконструктивных обсуждениях вопроса.
Верю, что ваш подход у вас работает, наш подход работает у нас. И не только у нас, почитайте комментарий ниже https://habr.com/ru/companies/habr_rutube/articles/970690/#comment_29180070
Хорошего вам дня!
Очень крутой и развернутый комментарий! Спасибо, что дополнили мой ответ!
Как по мне, тут на лицо смешение проблематик:
Разве только монолит дает чистоту архитектуры? Почем при микросервисной архитектуре мы не можем работать качественно? И что делать при увеличении монолита до масштабов, при которых любая доработка превращается в месяцы? Что делать по-настоящему большим сервисам с миллионами пользователей и петабайтами данных? Как масштабировать базу данных, которая выросла до неподдерживаемых размеров?
На лицо сравнение теплого с мягким.
А тут точно проблема в инженерных подходах исключительно или есть ответственность продуктовой проработки и UX-исследований? Разве качество работы софта меряется исключительно наличием у этого софта микросервисной или монолитной архитектуры?
И тогда почему подход, в котором возможно строить что-то по-настоящему большое и масштабируемое, работающее быстро и способное выдержать хайлоад нагрузки не является эволюцией того, что устарело с точки зрения инженерных подходов и не подходит для использования с современном мире?
Вижу здесь переживания по тому, что мир изменился, а вы пока еще нет.
Да я и не претендую на звание "лучшего архитектора систем". Я вообще руководитель клиентской разработки, в первую очередь. Приведенные здесь схемы не претендуют на правильность их проектирования в работе, это картинки из презентации моего доклада, не более того. Статья про общее понимание паттерна BFF фронтенд-разработчиками. Допускаю, что некоторые формулировки здесь упрощены. Буду благодарен, если дополните более развернутыми комментариями и подсветите то, что я не дораскрыл, на ваш взгляд.
И да, и нет. Бывают кейсы, когда через BFF пускают все запросы с клиента и он действительно превращается в api gateway на стероидах. Я придерживаюсь мнения, что BFF нужен только в тех случаях, когда для конкретного элемента интерфейса нам необходимо получить данные из нескольких API бэкенда. Если подобный элемент мы отрисовываем часто и бизнес-логика приложения по агрегации данных начинает пухнуть, потому что нам нужно писать много кода для подготовки данных на клиенте, такой запрос стоит оптимизировать и вынести на уровень BFF. Здесь же мы можем снизить нагрузку на бэкенд, добавив кеширование на уровне BFF слоя. Ну и ходить напрямую от BFF до бекенда внутри закрытой сети дешевле и быстрее, чем ходить через балансер и провайдеров на каждый чих.
API Gateway должен заниматься маршрутизацией запросов и делать это очень быстро. Нагружать его логикой агрегации данных — не лучшее решение.
Благодарю за комплимент.)
А откуда такое мнение сложилось? Вы точно прочитали статью или остановились на четвертом абзаце?
Я же не советую всем BFF-сервисы клепать, напротив, у меня есть блок, в котором я пишу когда BFF вообще не нужен. Но подходы с монолитами и вправду часто не дают компаниям быстро развиваться. Поэтому и появился этот архитектурный паттерн и его нужно уметь правильно готовить. По идее, статья об этом.