Я считаю, что термин разделение фронтенда и бэкенда получил широкое распространение, и у всех есть какое-то понимание, но у некоторых людей могут быть немного другие взгляды: мы хотим заниматься SPA, всем AJAX, то есть фронтендом и заднее разделение.

Что такое переднее разделение

Давайте поговорим о том, что такое разделение фронтенда и бэкэнда.

Давайте сначала посмотрим на диаграмму модели архитектуры внешнего и внутреннего интерфейса веб-системы.

На рисунке хорошо видно, что границы front-end и back-end разделены по браузерам и серверам. Затем мы часто обнаруживаем некоторые проблемы:

1. Относится ли слой шаблона к интерфейсу или серверу?
2. Шаблоны сильно зависят от внутреннего рендеринга. Нужно ли фронтенд-разработке ждать бэкэнд-разработки?

Обычно слой шаблонов принадлежит фронтэнду, потому что очень сложно позволить бэкэнд-людям прикасаться к стилям и взаимодействию js, в которых они не очень хороши.

Затем, как фронтенд-разработчики, мы столкнемся со следующими проблемами в реальных сценариях разработки:

1. Среда: для локальной разработки требуется внутренняя среда, такая как Tomcat и PHP, что влияет на эффективность разработки.
2. Процесс: Front-end разработка сначала разрабатывает html, а затем переписывает html в указанный синтаксис шаблона (широко известный как набор шаблонов), что влияет на эффективность разработки.
3. интерфейс:
   • В определениях интерфейсов обычно используются текстовые документы, поэтому во время фронтенд-разработки трудно понять поля интерфейса, что влияет на эффективность разработки.
   • Изменения интерфейса необходимо переписывать и отправлять повторно, что влияет на эффективность разработки
   • Документы разбросаны, что мешает обслуживанию интерфейса
4. Совместная отладка:
   • Процесс совместной отладки становится очень сложным, особенно для проектов Java без горячего развертывания, и для изменения представления необходимо перезапустить Tomcat, что влияет на эффективность совместной отладки внешнего интерфейса.
5. выгода:
   • Разработка передней работы фокусируется больше на пользовательском опыте, в то время как только задний конец хочет сосредоточиться на надежных данных. Для того, чтобы реализовать некоторые взаимодействия, такие как отзывчивость и SSR, интерфейс необходимо контролировать определенную возможность ответа на ответ.
   • Если способ внешнего и внутреннего соединения будет изменен на чистый обмен JSON, это будет полезно для повышения эффективности разработки, более четкого распределения обязанностей и повторного использования интерфейса.

Если что-то влияет на эффективность разработки, значит, есть проблема с существующей моделью, очевидно, идея решения проблемы требует от нас переосмысления определения «front-end и back-end». В этот момент возникла концепция разделения фронтенда и бэкэнда, чтобы настроить совместную работу фронтенд и бэкенд разработчиков так, чтобы это было максимально удобно для всех.

Какие есть варианты реализации

SPA

Полное название — «Одностраничное приложение». Оно использует интерфейсную маршрутизацию вместо внутреннего контроллера, использует внешний шаблон вместо внутреннего рендеринга механизма шаблонов и использует Restful API для взаимодействия с внутренними данными.

В этой схеме интерфейсные и внутренние взаимодействия преобразуются в чисто строковые взаимодействия JSON в стиле HTTP.

Преимущества СПА:

1. Среда: Front-end разработчикам не нужна локальная внутренняя среда.
2. Процесс: независимый режим разработки внешнего интерфейса, поскольку задний конец возвращается к чистому JSON, передний конец хочет имитировать ответ на запрос, просто запустите чистый статический сервер, ответьте на HTML в формате JSON.
3. Совместная отладка: четкий метод стыковки, JSON относительно чист для внешнего и внутреннего интерфейса.
4. Преимущество: для пользователей улучшен пользовательский интерфейс

Недостатки СПА

1. Слабое SEO
2. Первый экран загружается медленно, и первый экран может отображаться только после загрузки всех js.
3. Внешний интерфейс должен иметь дело с некоторыми вещами, с которыми не нужно иметь дело на этом уровне, например, с контролем разрешений для внешнего интерфейса.

Подводя итог, можно сказать, что SPA — это эффективное решение, которое может решить проблему разделения передней и задней частей, и вы можете попробовать его для проектов без требований SEO.

Разделение фазы разработки -- Mock && Proxy

Как следует из названия, разделение между интерфейсом и сервером на этапе разработки должно быть реализовано с помощью инструментов, которые обычно называются Mock Server (например, Mock Server, разработанный автором —Foxman).

Mock Server предоставляет функции

основные функции

• Перехват синхронного запроса, получение фиктивных данных в формате JSON, объединение с локальным шаблоном, рендеринг через механизм рендеринга шаблонов и получение страницы ответа
• Перехватывайте асинхронные запросы и получайте ответы с фиктивными данными в формате JSON.

Здесь нам нужно абстрагировать вышеуказанные операции в две функции, что легко понять:

1. SyncView = TemplateEngine(Template, MockData)
2. AsyncView = MockDataTransform(MockData)

Функция оптимизации

• Живая перезагрузка — отслеживайте локальные файлы и уведомляйте браузеры (обычно веб-сокеты) об обновлении ресурсов при возникновении изменений.
• Измените заголовок ответа — на этапе Mock js может изменить ответ.
• Прокси - я упоминал две функции ранее.Обвинение прокси состоит в том, чтобы изменить MockData, первоначально взятые с локального сервера, на данные, полученные с сервера в виде http

Процесс развития

Мы разделяем разработку проекта на три этапа: определение интерфейса, разработка и совместная отладка. Это просто подходит для наших инструментов «Mock» и «Proxy».
Давайте выразим это внешнее и внутреннее взаимодействие через практический сценарий.

Определение интерфейса

Мы получили запрос на реализацию определенной функции. После того, как мы выясним конкретные функции, мы должны определить интерфейс и вернуться с бэкэндом, в том числе:

1. Какие страницы есть, путь запроса страницы, расположение шаблона и содержимое модели, возвращаемое нам бэкэндом.
2. Что такое интерфейсы Ajax, путь запроса интерфейса Ajax и содержимое JSON, возвращаемое серверной частью

После формулировки интерфейса нам нужно создать Mock файл согласно требованиям Mock Server, заполнить данные JSON, согласованные с бэкендом, и подтвердить с бэкендом.

Очевидно, что в нашей разработке определение интерфейса стало очень специфической вещью, и на этапе разработки можно использовать эти MOCK-данные и делать фиктивные данные, интерфейсный документ.

стадия разработки

После того, как мы закончим определение интерфейса, мы ожидаем, что процесс разработки будет непрерывным и автономным.

Как показано на рисунке выше, front-end разработка на этапе разработки может быть полностью изолирована от back-end разработчиков, и нет необходимости запускать back-end среду локально. требования в соответствии с ранее указанным интерфейсом и локальным Mock-файлом.

В процессе разработки, следуя последовательности разработки html -> css -> js, у Foxman есть очень удобная живая перезагрузка (перезагрузка css при изменении css). Короче говоря, если определение интерфейса разумно, этот шаг будет очень гладкий.

Совместная стадия отладки

После того, как мы разработали страницу, мы ожидаем совместной отладки с бэкендом и проверки наличия дефектов в разработке функции, т.е. фазы согласования.

На этом шаге нам нужно только заменитьSyncView = TemplateEngine(Template, MockData)MockData, который первоначально ответил на запрос из Mock-файла, перенаправляет его на реальный целевой сервер (на этапе совместной отладки это будет хост разработки или тестовая машина).

Агент и форвардинг здесь, автор абстрагировался в другую библиотекуkoa-api-forward, добро пожаловать на обмен и использование.

Преимущества фиктивных и прокси-серверов

1. окружающая обстановка:
   • Фронтенд-разработчикам не нужна локальная серверная среда
2. обработать:
   • Независимый метод разработки интерфейса, сочетание Mock и Proxy, процесс понятен
   • Внешний интерфейс может отлаживать слой представления локально, что значительно повышает эффективность совместной отладки внешнего интерфейса.
3. Совместная отладка:
   • Четкий метод стыковки, реализация JSON относительно чистая с точки зрения внешнего и внутреннего интерфейса.
4. выгода:
   • Удобен для разработки при сохранении невмешательства в онлайн-системы

Недостатки имитации и прокси-сервера

1. На самом деле не понимаете ответ онлайн-интерфейса, все еще полагаетесь на бэкэнд при реализации некоторых требований взаимодействия с интерфейсом (отзывчивый) или не можете этого сделать (например, ssr)

Средний уровень Node.js

Этот шаблон естественно сочетает в себе предыдущий прокси. Всем известно, что сервер Node.js подчеркивает концепцию промежуточного программного обеспечения, которое соответствует шаблону цепочки ответственности шаблона проектирования. То есть занимайтесь только той ситуацией, с которой можете справиться, в противном случае продолжайте проходить дальше, пока с ней не разберутся.

В этой схеме Proxy действует как последний уровень в системе промежуточного программного обеспечения для пересылки запросов, а до этого — обработка ошибок промежуточного программного обеспечения, ответ статических ресурсов, маршрутизаторов и так далее.

Node.js имеет определенные возможности управления интерфейсом, такие как обработка адаптивного рендеринга ПК/мобильных устройств или рендеринг на стороне сервера и так далее.

Преимущества среднего уровня Node.js

1. окружающая обстановка:
   • Фронтенд-разработчикам не нужна локальная серверная среда
2. Совместная отладка:
   • Четкий метод стыковки, реализация JSON относительно чистая с точки зрения внешнего и внутреннего интерфейса.
3. выгода:
   • Он может быть прогрессивным: на начальном этапе все запросы могут перенаправляться на внутренний сервер, а затем слой Node.js можно постепенно использовать как слой прямого обмена данными пользователя.
   • Четкие обязанности, серверная служба, интерфейс обработки уровня Node.js, ответ страницы, связанный с пользователем, и обмен данными
   • Компонуемость, серверная служба, Node.js отвечает за комбинирование и сборку для повторного использования интерфейса.

Недостаток промежуточного слоя Node.js

• Поддержка Mock все еще требуется на этапе разработки.Если метод Mock интегрирован в средний уровень Node.js, ответственность среднего уровня Node.js будет неясной.
• Инкрементальная трансформация существующих систем — длительный процесс

Суммировать

Опять же, все решения для разделения клиентской и серверной части предназначены для того, чтобы настроить совместную работу разработчиков внешнего и внутреннего интерфейса так, чтобы она была максимально удобной для всех.

Тогда хорошей практикой является то, что мы можем комбинировать (Mock && Proxy) с двумя решениями среднего уровня Node.js:

1. Mock && Proxy полагается только на абстрактные инструменты и продолжает использовать их на этапе разработки интерфейса, чтобы избежать нечистых обязанностей среднего уровня Node.js.
2. Существование среднего уровня Node.js может устранить недостатки решения (Mock && Proxy).

Продолжение следует. . .

использованная литература

• Практика разделения фронтенда и бэкэнда Netease.md
• Имеет ли смысл разделять переднюю и заднюю части Интернета?

by Джун Ю