Один frontend должен работать только со своим backend

ru-RU | создано: 26.04.2019 | опубликовано: 26.04.2019 | обновлено: 26.04.2019 | просмотров за всё время: 213

Преинтереснейшие новости сегодня я услышал в общении с коллегами!

Коллеги, не далее как сегодня услышал интересное, но на мой взгляд, но бессмысленное заявление, что один frontend не может иметь доступ к нескольким backend'ам. Не может или нежелательно, чтобы имел. Якобы это что-то нарушает, но я так и не понял что именно. 

Речь вот о чем. Один frontend, например, reactjs+redux должен общаться только со своим собственным backend, например, на ASP.NET Core.

Как аргумент, прозвучало следующее: ...что якобы, если это не так, то это какая "перегруженность" frontend'a, который не должен знать про другие backend'ы. Говорили мы на тот момент о наборе микросервисов, которые существуют в системе.

Какие будут комментарии по этому поводу?

Комментарии к статье (7)

26.04.2019 19:09:42 void

Ну я не вижу большой проблемы, что у меня в конфигах будут несколько базовых урлов, а не один. А так лепить ещё один прокси ради красоты (одного адреса)? Это и замедление, потому что прокси, и лишняя бессмысленная работа программиста над прокси, и ещё одна точка отказа. Вся наша новая "абстракция" - просто один урл вместо нескольких

27.04.2019 10:26:24 Alexk

Не совсем понятно, в чем именно перегруженность frontend'а.  Cледуя этой логике, получается отходим от набора микросервисов в сторону написания одного большого монолитного сервиса, либо одного большого сервиса, который сам будет дергать другие сервисы. Именно этот сервис и будет перегруженным. По моему лишний слой.

Первый раз слышу о том, что это проблема: дергать различные сервисы. Как раз таки frontend и должен знать, откуда ему получать или где обрабатывать данные. 

27.04.2019 10:29:03 Calabonga
Alexk, согласен, что это лишний слой!
01.05.2019 7:02:18 doter-nsk

Вообще, конечно же, после прочтения возникли вопросы, касаемо аргумента: " ... что якобы, если это не так, то это какая "перегруженность" frontend'a, который не должен знать про другие backend'ы..." 1. Что означает "перегруженность" frontend'a и чему это противоречит/мешает? 2. Почему фронт не должен ничего знать про другие сервисы? Предполагаю, что всё зависит от архитектуры того или иного приложения/сервиса/сайта. Например, если фронт работает с какими-то важными/секретными/конфиденциальными данными, которые ему нельзя передавать другим сторонним сервисам - тогда конечно - фронт должен работать только со своим backend, который, хоть и будет проксировать или содержать дополнительные слои для работы с внешними сервисами, но будет контролировать потоки данных. Хотя такой подход при большом количестве пользователей текущего сервиса и большом количестве внешних сервисов, которые нужно проксировать - повлияет на производительность. И возможно, что есть и другие причины/поводы, по которым архитектура приложения должна быть построена по модели 1 frontend - 1 backend. Жаль, что автор аргумента не озвучил причин. С другой стороны, если опять же, согласно архитектуре приложения/сервиса/сайта требуется обмен данными с различными внешними сервисами и нет причин для проксирования на стороне backend - то такой подход упрощает взаимодействие, увеличивает быстродействие и наверное является более правильным.

06.05.2019 15:40:55 Mikhail

В общем, без объяснения приведённого аргумента я тоже не понял в чём проблема. Тут нужно разбираться, что это за сайт, для кого предназначен и почему заложено такое арх. решение. Как я сейчас представляю, что если сайт показывает данные клиента, то он их берет с одного бэка и если он тут же где-то показывает валютный курс или погоду, то это другие бэки. Может быть это связано с какими-то сложностями на фронте..... что если, например, поменялся адрес у какого-то из бэков (версия обновилась может), то для замены этого адреса, нужно будет поменять конфиг единого бэка и его перезапустить, а сам сайт останется в работе, а не совсем упадет на время переподнятия.

21.05.2019 4:18:32 Alex

Добрый день! Не разглядел в Вашей "интереснейшей новости" обоснования с точки зрения архитектуры системы. Почему может front иметь или не может front иметь отдельный back. Оба архитектурных подхода имеют места быть. Оба они активно практикуются при создании систем. И выбор того или иного подхода обосновывается параметрами системы которых необходимо добиться. Или Вы просто категорически не воспринимаете мнения других людей? Вот когда Вы напишите обоснованную статью с точки зрения планируемой архитектуры, бизнеса, технологий, тогда это возможно будет интересно. Но пока просто сотрясение воздуха.

21.05.2019 4:24:43 Calabonga
Alex, Вот вы не поверите, Alex, но тут вы на самом деле правы, и я не раз высказался в одном из своих видео на канале youtube.com именно эту мысль: "Всё хорошо в меру и к месту". Вы можете убедиться в этом просмотрев видео про микросервисы. Может быть я не ясно выразился в статье, но я могу повторить еще раз. Прокси сервис - это обычный паттерн, который конечно же может быть использован, но не просто потому что "захотелось" или потому что "кто-то использует", а именно при необходимости, основываясть на архитектурных потребностях, для решения конкретных задач.
Как в вам обращаться?
используется для обратной связи (не публикуется)
пример: https://www.calabonga.com
  1. Отправляя комментарий и предоставляя сайту персональные данные, вы соглашаетесь с Политикой конфиденциальности, которая установлена на сайте.
  2. Все комментарии модерируются на предмет наличия идиоматических выражений и нецензурных слов. Теги-ссылки будут удалены из текста сообщения.