Привет Это канал Listen it и сегодня мы слушаем статью паттерна Gateway и бэкенд во фронтент от авторе Игорь коровченко который написал эту статью на сайте doca.guide Спасибо автору за статью ссылочка на статью будет конечно в описании к этому видео Давайте с места в карьер Gateway это единое окно для разных API Бэкон форфронтенд то есть бэкенд для фронтендо использует гейтвей для обработки запросов и подготовки ответов предназначенных для фронтендо гейтвей и бэкен for frontent или сокращенно BF это паттерны проектирование для разработки веб-приложений оба паттерна используются для обеспечения доступа к разным IP с помощью одного контракта а контракт
это все то что позволяет общаться двум сетевым узлам между собой архитектура построения сетевого соединения набор сетевых протоколов набор адресов и портов для доступа к данным правила формирования запросов со стороны клиентов механизм подготовки и отправки ответов со стороны сервера начали насколько резко Так что давайте немножко приземлимся и поймем что это все означает И зачем оно нужно современно веб-приложение состоит из интерфейса с которым работает пользователь и бэкэнда который пользователь не видит бэкенд может быть устроен по разному все зависит от задачи Бэкон крупных веб-приложений обычно довольно сложно устроен как правило бэккент это совокупность разных программ разных сервисов То
есть это микросервисы или одна большая программа то есть Монолит современным вебе все чаще используется микросервисный подход о котором вы можете послушать в нашей статье которая может читали про микросервисы про соло и про событийно-ориентированную архитектуру проблема такого сложного бэкана состоит в том что каждый микросервис представляет собой уникальный программный интерфейс А фронтенд уже Приходится работать с каждым микросервисом отдельно и помнить API каждого это неудобно и создает жесткую связь между фронтендом и бэкэндом и требует много знаний о внутреннем устройстве бэкенда решение этой проблемы состоит в том чтобы сделать один унифицированный интерфейс который в свою очередь превращаться ко всем
микросервисам одним из первых таких решений был Gateway который является как правило прокси-сервером и предоставляет единое окно для доступа к данным по определенному программному интерфейсу он же API и он присылает данные от frontendo к нужному микросервису и обратно внешний вид приложения пользователя меняется бизнес логика меняется клиентское приложение меняется может меняться и контракт но на остальные API это никак не влияет гейтвой пересылает запросы со стороны клиентов на другие апишки учитывая разницу в контрактах и этим Он позволяет снизить связанность бэкенды и фронтендо в приложении как правило на стороне Gateway часто и запросы могут кэшироваться и может быть реализована
простая бизнес логика которая обеспечивает контроль над набором перед слаймых данных между клиентом и внешним API Но что это за BF Что за бэконд фронтенд бэкен фолфренд который является развитием идеи единого окна похожа на гейтвей В задачах обеспечения единого контракта под контроля над набором данных bff обязательно включает в себя Gateway которому предъявляется следующие требования общие шаблоны на клиенте и сервере например GSX высокая скорость ответ под нагрузкой и Единый язык на клиенте и промежуточном сервере bff общие шаблоны очень важны поскольку это существенно ускоряет разработку и облегчивает поддержку как клиентской части приложения так и серверного приложения BF учитывая
что и язык должен быть единым Это позволяет переиспользовать код на клиенте и сервере высокая скорость ответа достигается не только применением кэширования частых запросов но и средствами предварительной подготовки данных для запросов от клиента можно кстати использовать BF не только для доступа к различным API но например паттерн BF прекрасно ложится на архитектуру построение веб-приложения в котором на стороне сервера работают микросервисы Теперь давайте на практике с чего же начать если мы хотим построить такую архитектуру если в качестве языка разработки используется JavaScript то очевидно что необходимо обеспечить исполнение кода Скорее всего вы будете использовать note.gs но есть альтернатива Дина
или гральвем но Джес прекрасно подходит для большого количества операций ввода и вывода но не в случае вычислений для BF Это отличный выбор следующий шаг это выбор архитектуры этот этап очень важен потому что выбор архитектуры определяет дальнейшую поддержку и развитие приложения для BF прекрасно подходит концепция слоев в этой концепции происходит разделение пользовательского интерфейса в нашем случае это опишка которая обращается Клиент от бизнес логики и данных серверное приложение обычно построено на слоях и связях между ними есть несколько подходов для реализации слоев во-первых всем нам известно трехуровневая то есть трехзвенная архитектура исторически это один из первых подходов который
построен на совместной работе трех слоев слоя клиента слой бизнес логики и слоя данных нижний слой это слой данных он взаимодействует бизнес логике который в свою очередь взаимодействует с клиентским слоем в трехуровневой архитектуре клиентский слой изолирован от слоя данных проблема такого подхода очевидна все приложение построено в привязке К данным например структура в базе данных будет полностью определять все верхние слои что в корне неправильно Это не позволяет обеспечить должный уровень абстракции начнутся проблемы если изменятся какой-то внешний API или способ получения данных от микросервиса развивать И поддерживать такое приложение будет крайне сложно второй подход это domain griving Design
это более современный подход когда приложение разбивается на четыре слоя пользовательский интерфейс клиент бизнес логика домен инфраструктура в этом подходе нижним слоем является слой инфраструктуры над которым располагается доменный слой он определяет все сущности необходимые для работы слоя бизнес-логики в рамках доменной области такой подход неплох но он слишком тяжелый для bff часто требования к продукту таковы что определение домена и основ бизнес логике должно лежать на бэкэнде задача bff быть удобной и легкой прослойкой между фронтендом и бэкэндом важно отметить что инфраструктура иногда должна быть видна из уровня бизнес-логики Что приводит к проблеме которая называется протечка абстракции или текущей
абстракцией проблема связана с тем что для правильной с точки зрения будущей поддержки и развития кода архитектуры нужно изолировать слои только верхний и нижний слой могут что-то знать о текущем но они остальные есть еще подход чистой архитектуры это еще более современный подход в котором используются все те же 4 слоя что и в ddd но иначе слой инфраструктуры поднимается до уровня пользовательского интерфейса Это позволяет избегать протечки абстракции домен становится центром приложения в современных BF приложениях используются именно чистые архитектура в качестве фреймворка часто выбирают Экспресс в связке с GS безусловно проектирование конкретного приложения зависит уже от бизнес-задачи и
домен Ной области веб-приложения Ну а на этом все спасибо что послушали эту статью надеюсь вам как им не было интересно если понравилось видео то поставь ему лайк Ну и подпишись на канал Мне будет очень приятно А чтобы поддержать канал ты можешь даже скинуть денежку на юмани или подписаться на бусте Но это конечно если очень хочется а так подписывайся на нашу телегу Там есть много разных статей которых нет на Ютюбе всякими масса на тему it и всегда раньше всех ребята там узнают Какое следующее видео выйдет на канале Ну все пока
