Один frontend должен работать только со своим backend
Просто о NET | создано: 26.04.2019 | опубликовано: 27.04.2019 | обновлено: 13.01.2024 | просмотров: 2331 | всего комментариев: 7
Преинтереснейшие новости сегодня я услышал в общении с коллегами!
Коллеги, не далее как сегодня услышал интересное, но на мой взгляд, но бессмысленное заявление, что один frontend не может иметь доступ к нескольким backend'ам. Не может или нежелательно, чтобы имел. Якобы это что-то нарушает, но я так и не понял что именно.
Речь вот о чем. Один frontend, например, reactjs+redux должен общаться только со своим собственным backend, например, на ASP.NET Core.
Как аргумент, прозвучало следующее: ...что якобы, если это не так, то это какая "перегруженность" frontend'a, который не должен знать про другие backend'ы. Говорили мы на тот момент о наборе микросервисов, которые существуют в системе.
Какие будут комментарии по этому поводу?
Комментарии к статье (7)
Ну я не вижу большой проблемы, что у меня в конфигах будут несколько базовых урлов, а не один. А так лепить ещё один прокси ради красоты (одного адреса)? Это и замедление, потому что прокси, и лишняя бессмысленная работа программиста над прокси, и ещё одна точка отказа. Вся наша новая "абстракция" - просто один урл вместо нескольких
Не совсем понятно, в чем именно перегруженность frontend'а. Cледуя этой логике, получается отходим от набора микросервисов в сторону написания одного большого монолитного сервиса, либо одного большого сервиса, который сам будет дергать другие сервисы. Именно этот сервис и будет перегруженным. По моему лишний слой.
Первый раз слышу о том, что это проблема: дергать различные сервисы. Как раз таки frontend и должен знать, откуда ему получать или где обрабатывать данные.
Вообще, конечно же, после прочтения возникли вопросы, касаемо аргумента: " ... что якобы, если это не так, то это какая "перегруженность" frontend'a, который не должен знать про другие backend'ы..." 1. Что означает "перегруженность" frontend'a и чему это противоречит/мешает? 2. Почему фронт не должен ничего знать про другие сервисы? Предполагаю, что всё зависит от архитектуры того или иного приложения/сервиса/сайта. Например, если фронт работает с какими-то важными/секретными/конфиденциальными данными, которые ему нельзя передавать другим сторонним сервисам - тогда конечно - фронт должен работать только со своим backend, который, хоть и будет проксировать или содержать дополнительные слои для работы с внешними сервисами, но будет контролировать потоки данных. Хотя такой подход при большом количестве пользователей текущего сервиса и большом количестве внешних сервисов, которые нужно проксировать - повлияет на производительность. И возможно, что есть и другие причины/поводы, по которым архитектура приложения должна быть построена по модели 1 frontend - 1 backend. Жаль, что автор аргумента не озвучил причин. С другой стороны, если опять же, согласно архитектуре приложения/сервиса/сайта требуется обмен данными с различными внешними сервисами и нет причин для проксирования на стороне backend - то такой подход упрощает взаимодействие, увеличивает быстродействие и наверное является более правильным.
В общем, без объяснения приведённого аргумента я тоже не понял в чём проблема. Тут нужно разбираться, что это за сайт, для кого предназначен и почему заложено такое арх. решение. Как я сейчас представляю, что если сайт показывает данные клиента, то он их берет с одного бэка и если он тут же где-то показывает валютный курс или погоду, то это другие бэки. Может быть это связано с какими-то сложностями на фронте..... что если, например, поменялся адрес у какого-то из бэков (версия обновилась может), то для замены этого адреса, нужно будет поменять конфиг единого бэка и его перезапустить, а сам сайт останется в работе, а не совсем упадет на время переподнятия.
Добрый день! Не разглядел в Вашей "интереснейшей новости" обоснования с точки зрения архитектуры системы. Почему может front иметь или не может front иметь отдельный back. Оба архитектурных подхода имеют места быть. Оба они активно практикуются при создании систем. И выбор того или иного подхода обосновывается параметрами системы которых необходимо добиться. Или Вы просто категорически не воспринимаете мнения других людей? Вот когда Вы напишите обоснованную статью с точки зрения планируемой архитектуры, бизнеса, технологий, тогда это возможно будет интересно. Но пока просто сотрясение воздуха.