Предисловие
При отделении передней и задней части заканчивается, первая проблема, на которую я обращаю внимание, - это рендеринг, то есть работать на уровне просмотра.
В традиционной модели разработки браузер и сервер разрабатываются двумя командами, как передние, так и задние концы, но шаблон находится в расплывчатой области между ними. Следовательно, на шаблоне всегда есть все более и более сложная логика, которые в конечном итоге трудно поддерживать.
И мы выбрали Nodejs в качестве среднего слоя передней и задней части концов. Попробуйте использовать Nodejs, чтобы очистить работу на уровне просмотра.
Это делает разделение труда между передним и задним концом более четким, делает проект лучше поддерживать и достигает лучшего пользовательского опыта.
Эта статья
Работа по рендеринге представляет собой очень большую часть ежедневной работы фронт-разработчиков, а также самая легкая часть, которую нужно путать с концом развития.
Оглядываясь назад на последние несколько лет разработки технологий фронта, работа на уровне просмотра претерпела много изменений, таких как:
Форма отправить полную страницу обновление => ajax local refresh
Продолжение на стороне сервера + mvc => рендеринг на стороне клиента + MVC
Традиционное изменение страницы jump => приложение для одной страницы
Можно заметить, что в последние годы каждый, как правило, перемещал эту штуку с конца сервера на конец браузера.
Серверная сторона фокусируется на обслуживании и предоставляет интерфейсы данных.
Преимущества рендеринга браузера
Мы все знаем преимущества рендеринга на стороне браузера, как
1. Избавьтесь от связи и путаницы между бизнес -логикой и логикой презентации в шаблоне Java.
2. Для многопользованных приложений легче интерфейс. Пара разных шаблонов на стороне браузера, чтобы представить различные приложения.
3. Рендеринг страниц-это не только HTML, но рендеринг на передней части может легко предоставлять функции в компонентизированной форме (HTML + JS + CSS), так что компоненты фронта не должны полагаться на структуру HTML, созданную сервером.
4. Избавьтесь от зависимости от процессов развития и распределения направленности.
5. Удобная корректировка соединения.
Недостатки, вызванные рендерингом браузера
Но, наслаждаясь преимуществами, мы также сталкиваемся с недостатками рендеринга на стороне браузера, например:
1. Шаблон разделен в разных библиотеках. Некоторые шаблоны размещаются на стороне сервера (Java), в то время как другие размещаются на стороне браузера (JS). Передние и задние языки шаблона не связаны.
2. Вам нужно ждать, пока все шаблоны и компоненты будут загружены в браузер, прежде чем рендеринг сможет начать, и вы не можете прочитать его немедленно.
3. Будет белый экран, ожидающий рендеринга в первый раз, что не способствует пользовательскому опыту
4. При разработке приложения на одну страницу маршрут фронтального интерфейса не соответствует маршруту на стороне сервера, который очень хлопотно для обработки.
5. Все важное содержание собирается на передней части, что не способствует SEO
Размышлять о определении передних и задних концов
Фактически, когда мы перейдем к рендеринге со стороны сервера (Java) на сторону браузера (JS), наша цель состоит в том, чтобы явно разделить переднюю и заднюю обязанность, и нет необходимости отображать браузер.
Это просто потому, что в традиционной модели разработки выпущен сервер, а браузер достигается, поэтому рабочее содержимое на переднем крае может быть ограничено только стороной браузера.
Поэтому многие люди определили, что Backend = Server Frontend = Browser Site, как и рисунок ниже.
В проекте Midway Midway в настоящее время в настоящее время Taobao Ued, создав средний слой Nodejs в середине браузера Java, мы пытаемся снова дифференцировать линию переднего и заднего деления для рабочих обязанностей, а не для оборудования (сервер и браузер).
Поэтому у нас есть возможность поделиться шаблонами и маршрутами, что также является наиболее идеальным состоянием в переднем и внутреннем разделе труда.
Таобао на полпути
В проекте Midway мы перенесли линию, которая разграничивает переднюю и заднюю часть от браузера на сторону сервера.
С слоем Nodejs, который легко контролируется передним и общим для браузера, разделение передней части может быть завершено более четко.
Также возможно позволить передовым разработке определять наиболее подходящее решение для различных ситуаций. Вместо всего обрабатываются на стороне браузера.
Делящие обязанности
Midway-это не тот проект, который фронт-конечности пытается устроиться на первую работу. Цель состоит в том, чтобы четко сократить расплывчатую область шаблона и получить более четкое разделение обязанностей.
Бэкэнд (Java), сосредоточенная на
1. Сервисный слой
2. Формат данных и стабильность данных
3. Бизнес -логика
Фронт, сосредоточьтесь на
1. UI слой
2. ЛОГИКА управления, логика рендеринга
3. Взаимодействие, пользовательский опыт
И больше не придерживаться различий между сервером или стороной браузера.
Разделение шаблонов
В традиционной модели разработки браузер и сервер разрабатываются двумя командами, как передние, так и задние концы, но шаблон находится в расплывчатой области между ними. Следовательно, на шаблоне всегда есть все более и более сложная логика, которые в конечном итоге трудно поддерживать.
С Nodejs студенты -бэкэнд могут сосредоточиться на разработке бизнес -логики и данных на уровне Java. Студенты фронта сосредоточены на разработке логики управления и рендеринга. И вы можете выбрать эти шаблоны самостоятельно для рендеринга на стороне сервера (Nodejs) или на стороне браузера.
Используя тот же шаблонный язык xtemplate и тот же двигатель рендеринга JavaScript
Предоставить один и тот же результат в различных средах рендеринга (серверная сторона, браузер ПК, мобильный браузер, представление и т. Д.).
Маршрутизация обмена
Кроме того, из -за слоя Nodejs вы можете более тщательно контролировать маршрутизацию.
Если вам нужно выполнить маршрутизацию на стороне браузера на переднем конце, вы можете настроить маршрутизацию на стороне сервера одновременно, чтобы она могла изменить страницы на стороне браузера или страницы на стороне сервера, и вы можете получить постоянный эффект рендеринга.
В то же время, проблема SEO также была решена.
Практика обмена шаблонами
Обычно, когда мы отображаем шаблон в браузере, процесс - не что иное, как
Введите шаблонный двигатель в браузере (XTMPleate, соковыжималка, Handlerbar и т. Д.)
Архив шаблонов нагрузки на стороне браузера, метод может быть
Печать на странице с помощью <script type = "js/tpl"> ... </script>
Используйте инструмент загрузки модуля для загрузки архивов шаблонов (Kissy, Assejs и т. Д.)
другой
Получите данные и используйте механизм шаблона для генерации HTML
Вставьте HTML в указанное место.
Приведенный выше процесс можно увидеть, что если вы хотите достичь перекрестного обмена шаблонами, на самом деле основное внимание уделяется последовательному выбору модуля.
На рынке есть много популярных стандартов модулей, таких как KMD, AMD и CommonJS. Пока архив шаблона Nodejs может быть выведен в конечные характеристики Nodejs с помощью согласованных спецификаций модуля, можно сделать базовый обмен шаблонами.
Последующая серия статей будет дополнительно обсуждать прокси и обмен модели.
Обсуждение дела
Из -за промежуточного слоя острова Мидуэй есть лучшие ответы на некоторые прошлые вопросы, такие как
Случай 1 Сложные интерактивные приложения (такие как корзина для покупок, страница заказа)
Статус: Все HTML отображается на передней части, а сервер предоставляет только интерфейсы.
Проблема: При входе на страницу будет короткий белый экран.
отвечать:
Введите на страницу впервые, отобразите полную страницу на стороне Nodejs и загрузите связанные шаблоны в фоновом режиме.
Последующие взаимодействия, полное частичное обновление на стороне браузера
Использование того же шаблона дает тот же результат
Случай 2 приложение для одной страницы
Статус: Используйте платформу MVC на стороне клиента для изменения страниц в браузере.
Проблема: рендеринг и замена страницы завершаются на стороне браузера. Когда вы вводите URL -адрес непосредственно или обновляете F5, тот же контент не может быть представлен напрямую.
отвечать:
Поделиться теми же настройками маршрута на стороне браузера и Nodejs
При изменении страниц на стороне браузера измените маршрут и отображайте содержимое страницы на стороне браузера.
При непосредственном вводе того же URL -адреса используйте рендеринг содержимого содержимого страницы страницы на стороне Nodejs
Независимо от того, меняете страницы в браузере или непосредственно вводите один и тот же URL, контент, который вы видите, одинаково.
В дополнение к растущему опыту и уменьшению логической сложности. Это также решило проблему SEO
Случай третий чистый просмотр страницы
Статус: страница содержит только информацию, меньше или нет взаимодействия
Проблема: HTML генерируется на стороне сервера, CSS и JS помещаются в другое место, и они имеют зависимости друг друга.
отвечать:
Через Nodejs объединенное управление HTML + CSS + JS
Если вам необходимо расширить сложные приложения или одностраничные приложения в будущем, вы также можете легко перенести их.
Страница терминала с четырьмя крестами
Статус: одно и то же приложение должно представлять разные интерфейсы и взаимодействия в разных конечных точках
Проблема: управление HTML нелегко, а на стороне сервера часто будет генерироваться разные HTML, а на стороне браузера будет выполнена различная обработка.
отвечать:
Перекрестные страницы представляют проблемы и обрабатываются фронт-конце.
Через слой Nodejs и сервис Backend, лучшие решения могут быть разработаны для этого типа сложных приложений.
Суммировать
Появление таких технологий, как Ajax, клиентская сторона MVC, SPA, двустороннее связывание данных в прошлом, все было попытками решить узкие места, встречающиеся в то время в переднем конце.
Появление промежуточного слоя Nodejs также является попыткой решить ограничение того, что передний конец в настоящее время ограничен браузером.
Эта статья посвящена обмену шаблонами фронт-энда и на заднем плане и надеется привлечь внимание. Давайте обсудим с вами, как улучшить наш рабочий процесс и сотрудничать с бэк-конце, чтобы сделать лучшую работу на переднем конце под архитектурой среднего уровня Nodejs.