Если говорить про «бутылочное горлышко», то BFF сам по себе им не является. И он не обязательно сводится к одному эндпоинту — это вопрос архитектуры и удобства.
Про Zod согласен — он не самый быстрый, но именно он позволяет реализовать безопасный обмен данными с соблюдением типов. Если критична производительность, то BFF легко горизонтально масштабируется. Я понимаю, что при десятках и сотнях тысяч RPS каждый оверхед критичен, но сомневаюсь, что Zod окажется узким местом. Наоборот, чем масштабнее и сложнее система, тем критичнее становится управляемость API.
Кстати, можно реализовать механизм пропуска валидации для части запросов на горячих эндпоинтах при высокой нагрузке, по аналогии с circuit breaker.
Спасибо за ваш комментарий. Отвечу по каждому пункту
Любая архитектура начинается с анализа нагрузок, количеста пользователей и т.д. Часто, на решение о архитектуре оказывает и команда, которая имеется в наличии.
Согласен, эти факторы существенно влияют на принятие архитектурных решений. В статье я делюсь личным опытом и рассказываю о том, как различные методы рендеринга применялись в моих проектах на разных этапах карьеры.
Также я постарался обратить внимание на эти аспекты, указывая их в разделах об ограничениях, проблемах и трудностях. Например, в разделе "Анализ потребностей проекта" сказано про важность учета команды и сроков, а также про ограничения инфраструктуры при выборе метода рендеринга.
В целом много лет не встречал реализаций, которые можно отнести либо к серверному либо к рендерингу на стороне клиента. Т.е. чаще всего это продуманная гибридная архитектура.
Я согласен с вами в том, что большинство современных веб-приложений создаются с использованием гибридных подходов. Однако, ряд проектов просто не может быть реализован иначе (или просто не целисообразно делать иначе) — в них используется только клиентская часть с получением данных по API. В статье я в том числе привожу примеры таких проектов.
И, возможно я ошибаюсь, но поисковые системы давно нормально работают с js.
И да и нет. С одной стороны поисковые системы вроде google могут рендерить js и индексировать CSR сайты. С другой стороны есть целый ряд нюансов.
В статье я просто указал "динамический контент индексируется не всеми поисковыми системами и не без особенностей.", но забыл упомянуть в статье, что можно использовать Prerender как частичное решение проблемы. Ещё пара слов про индексацию
Яндекс кмк является основным источником трафика для ru сайтов и у него недавно появилась фича индексации сайтов с JS, но она всё ещё в BETA. это не "нормально рабатают"
Google учитывает показатели Web Vitals при ранжировании (про Яндекс не знаю), а это значит, что CSR решения будут заметно проигрывать из-за FCP/LCP
При использовании CSR нет гарантии что важный контент окажется доступен для индексации — нет контроля над содержимым, которое будет использовать бот
Если говорить про «бутылочное горлышко», то BFF сам по себе им не является. И он не обязательно сводится к одному эндпоинту — это вопрос архитектуры и удобства.
Про Zod согласен — он не самый быстрый, но именно он позволяет реализовать безопасный обмен данными с соблюдением типов. Если критична производительность, то BFF легко горизонтально масштабируется. Я понимаю, что при десятках и сотнях тысяч RPS каждый оверхед критичен, но сомневаюсь, что Zod окажется узким местом. Наоборот, чем масштабнее и сложнее система, тем критичнее становится управляемость API.
Кстати, можно реализовать механизм пропуска валидации для части запросов на горячих эндпоинтах при высокой нагрузке, по аналогии с circuit breaker.
Спасибо за ваш комментарий. Отвечу по каждому пункту
Согласен, эти факторы существенно влияют на принятие архитектурных решений. В статье я делюсь личным опытом и рассказываю о том, как различные методы рендеринга применялись в моих проектах на разных этапах карьеры.
Также я постарался обратить внимание на эти аспекты, указывая их в разделах об ограничениях, проблемах и трудностях. Например, в разделе "Анализ потребностей проекта" сказано про важность учета команды и сроков, а также про ограничения инфраструктуры при выборе метода рендеринга.
Я согласен с вами в том, что большинство современных веб-приложений создаются с использованием гибридных подходов. Однако, ряд проектов просто не может быть реализован иначе (или просто не целисообразно делать иначе) — в них используется только клиентская часть с получением данных по API. В статье я в том числе привожу примеры таких проектов.
И да и нет. С одной стороны поисковые системы вроде google могут рендерить js и индексировать CSR сайты. С другой стороны есть целый ряд нюансов.
В статье я просто указал "динамический контент индексируется не всеми поисковыми системами и не без особенностей.", но забыл упомянуть в статье, что можно использовать Prerender как частичное решение проблемы. Ещё пара слов про индексацию
Яндекс кмк является основным источником трафика для ru сайтов и у него недавно появилась фича индексации сайтов с JS, но она всё ещё в BETA. это не "нормально рабатают"
Google учитывает показатели Web Vitals при ранжировании (про Яндекс не знаю), а это значит, что CSR решения будут заметно проигрывать из-за FCP/LCP
При использовании CSR нет гарантии что важный контент окажется доступен для индексации — нет контроля над содержимым, которое будет использовать бот