Трилогия веб-разработки
Бронзовый век
В начале Интернета веб-страница была просто средством для переноса статической информации, и она могла отображать только какой-то чисто статический текст и изображения. Такая статическая страница не может читать данные в фоновой базе данных, это полностью закрытая экология, назовем ее «бронзовым веком» веб-разработки.
серебряный век
Чтобы сделать Интернет более динамичным, разработчики снова и снова атакуют высокие позиции динамических веб-страниц, основная цель которых состоит в том, чтобы позволить веб-разработчикам быстро писать динамические страницы. На этом этапе одна за другой родились технологии динамических страниц, представленные PHP, JSP и ASP.NET. Перед этими технологиями динамических страниц веб-страницы больше не являются статичными и могут представлять разные результаты данных в зависимости от разных людей, разных регионов и разных периодов времени.С тех пор развитие Интернета вступило в свой «серебряный век».
Золотой век? ? ?
Впоследствии появились различные веб-сайты, и сложность веб-сайтов резко возросла.Программистам становится все труднее рисовать страницы и управлять бизнес-логикой.В настоящее время концепция разделения внешнего и внутреннего интерфейса предложил. Основная концепция: **«Пусть профессионалы делают профессиональные вещи»**. В результате развитие карьеры программистов подошло к точке бифуркации, и вопрос о том, выбрать ли программиста, который специализируется на рисовании страниц, или программиста, который специализируется на управлении бизнес-логикой, стал предметом разногласий до сегодняшнего дня.На этом этапе фронтенду вообще не нужно участвовать в обработке данных в фоновом режиме, ему достаточно использовать согласованный интерфейс для получения соответствующих данных, а затем рендерить страницу. И одно из преимуществ этого заключается в том, что ход разработки не будет заблокирован, а внутренней разработке не нужно ждать завершения внешнего интерфейса, прежде чем продолжить, пока совместная отладка внешнего интерфейса и внутреннего интерфейса выполняется после того, как Mock завершает данные.
Проблема разделения фронтенда и бэкэнда
Является ли этот этап «золотым веком» веб-разработки?
Я так не думаю.
Разделение фронтенда и бэкенда — очень хорошая идея.Прекрасное видение того, чтобы позволить профессионалам заниматься профессиональными делами, натолкнулось на множество проблем в реальном процессе. Например, внешний интерфейс обычно отображает данные логически, иногда для повышения эффективности серверная часть инкапсулирует данные в соответствии со структурой данных, требуемой интерфейсом. Это означает, что задняя часть по-прежнему выполняет работу слоя представления, что противоречит первоначальному намерению разделить переднюю и заднюю части.
Средний уровень архитектуры веб-системы
Для решения вышеуказанных проблем некоторые люди предлагают просто передать работу Контроллера и Представления на фронтенд, а бэкенд отвечает только за обработку данных и лежащую в их основе логику Модели. Поэтому было предложено решение среднего уровня Node.Мы не будем перечислять, хорошо это решение или нет.Давайте сначала поговорим о том, какова функция этого среднего слоя и что из себя представляет архитектура.
Архитектура среднего уровня
На самом деле то, что должен делать средний слой, очень просто.
Получается, что клиент напрямую отправляет запрос на сервер, а серверный уровень получает запрос и возвращает результат в браузер через обработку вычислений. Теперь браузер отправляет запрос на уровень узла, а уровень узла отправляет запрос на уровень сервера после одного раунда обработки. После обработки уровень сервера возвращает результат ответа на уровень узла, а уровень узла, наконец, возвращает данные в браузер. Из-за появления уровня узла уровень сервера может сосредоточиться только на самом бизнесе, не обращая внимания на особые требования внешнего интерфейса к полям.
Более того, благодаря добавлению уровня NodeJS логика отображения интерфейса каждого внешнего интерфейса поддерживается самим уровнем NodeJS. Если продакт-менеджер хочет изменить интерфейс в мидле, фронтенд может поддерживать его самостоятельно, не беспокоясь об этом бэкэнду. Front-end и back-end выполняют свои обязанности, back-end занимается разработкой собственной бизнес-логики, а front-end занимается разработкой эффекта продукта. Это обеспечивает более полное разделение фронтенда и бэкенда.
На первый взгляд, вы думаете, что этот план идеален? Но так ли это на самом деле?
Нет ничего нового под солнцем
Если вы внимательно посмотрите на схемы в статье, то обнаружите, что вся система становится все более и более сложной, а сложность системы повлечет за собой множество проблем, таких как увеличение затрат на коммуникацию с персоналом, снижение общей производительности системы и повышенные риски безопасности. Это все штампы.Пока уровень системы будет повышаться,эти проблемы будут неизбежно.Есть ли другие проблемы?
Давайте сначала подумаем об одном: могут ли эти вещи делать не-узлы?
Очевидно нет. До того, как Node стал промежуточным уровнем, эти задачи изначально выполнялись традиционным бэкендом.Теоретически, пока многоуровневая архитектура разработана на сервисном уровне, эти проблемы будут решаться легко, так почему же некоторые люди до сих пор поддерживают Node? в последние годы?А средний слой?
Кто-то скажет, что Node отлично подходит для SSR (рендеринга на стороне сервера). Это правда, что это преимущество Node, но остается вопрос, является ли это обязательным для Node?
Теперь, используя Node для SSR, вы думаете, что концепция дизайна очень похожа на JSP много лет назад?
Так в чем же причина того, что так много людей изучают этот путь?
Ниже приведена ссылка на мои частные товары.
моя точка зрения
Заранее оговорено, что нижеследующее содержание является сугубо личным мнением.
Сначала рассмотрим абзац:«PHP — лучший язык в мире»
Я думаю, что люди, которые услышат эту фразу, найдут ее очень смешной, хотя это и стало шуткой, но отражает объективную ситуацию - цепь презрения.
Презрение похоже на пищевую цепочку, порочный круг, которого нельзя избежать. В этом порочном кругу все находятся в конце цепи.
Причина, по которой возникает такая цепь презрения, во многом связана со сложностью работы и обращения.
Хорошая система должна бытьВысокая доступность, высокий уровень параллелизма и высокая производительностьДа, и эти три обычно относятся к бэкенд-программистам, а фронтенд-программисты могут играть ограниченную роль. Работа, которую вы делаете, не важна, лечение, естественно, не может быть упомянуто, и также возникла цепочка презрения.
Поэтому, чтобы дать отпор, NodeJS, который имеет низкую стоимость обучения и может быть быстро использован, возлагает большие надежды на программистов переднего плана и начал брать на себя некоторые второстепенные задачи (преобразование формата данных, проверка в полевых условиях), которые назад конечные программисты не хотят делать Функция, за которую отвечает интерфейс, больше не является основной вещью рисования страниц, и важность постепенно станет заметной.
В конечном счете, это связано с тем, что интерфейсу необходимо увеличить свою долю в бизнесе, тем самым повысив свой статус. Что касается того, обладает ли NodeJS боевой мощью по сравнению с традиционными серверными языками, это кажется менее важным. Возможно, в будущем, после разработки среднего уровня Node, его можно будет отделить и разделить.
Таким образом, вы обнаружите, что студенты фронтенда в компании часто подталкивают персонал бэкенда к добавлению промежуточного уровня Node во всю конструкцию системы на основании архитектурного дизайна, чтобы они могли показать свою силу. Конечный персонал готов поставить эти края Сомнительно, что основная работа выполняется персоналом уровня Node (в конце концов, есть много решений для серверной части, чтобы справиться с этим требованием к данным, например, GraphQL — одно из них).
Перефразируя предложение из Tomb Raiders Notes
«Самое сложное — это не программная система, а человеческое сердце».