Опыт реализации разделения фронта и бэкенда

В современной сети разделение передней и задней частей становится все более и более популярным, и все больше и больше компаний/веб-сайтов начинают двигаться в этом направлении. Итак, зачем выбирать разделение между интерфейсом и сервером? Каковы преимущества разделения фронтенда и бэкенда для фактической разработки?

Почему стоит выбрать разделение фронтенда и бэкенда

В предыдущей традиционной разработке веб-сайта внешний интерфейс обычно выполнял только работу по разрезанию карты, просто внедряя карту-прототип, предоставленную дизайнером пользовательского интерфейса, в статическую HTML-страницу и конкретную логику взаимодействия со страницей, например взаимодействие с данными. в фоновой работе и т. д., это может быть реализовано разработчиками в бэкенде, или фронтенд тесно связан с бэкендом. Например, в прошлом веб-сайт Taobao в основном основывался на платформе MVC webx, а архитектура определяла, что внешний интерфейс может полагаться только на серверный. Так что их модель разработки по-прежнему, напишите статичную демку на фронтенде и переведите ее в шаблон ВМ на бэкенде.Проблема этой модели обсуждаться не будет, а на нее уже давно жалуются.
И более вероятно, что бэкенд-персонал будет непосредственно заниматься фронтенд-работой, при реализации интерфейса API, при разработке страницы они переключаются друг на друга, и страницы динамически соединяются в соответствии с на разные URL-адреса, что также значительно увеличивает нагрузку на серверную часть. Неравномерное распределение front-end и back-end работы. Мало того, что эффективность разработки низкая, код сложно поддерживать. Если front-end и back-end разделены, проблема неравномерного разделения труда между front-end и back-end может быть хорошо решена, и на front-end можно назначить больше интерактивной логики для обработки, в то время как серверная часть может сосредоточиться на своей собственной работе, такой как предоставление интерфейсов API и контроль разрешений, и выполнять операции. Front-end разработчики могут использовать nodejs для создания своего собственного локального сервера, разработки непосредственно локально, а затем пересылать запросы API в фоновый режим через некоторые плагины, чтобы можно было полностью смоделировать онлайн-сцену и отделить ее от фона. Фронтенд может самостоятельно завершить весь процесс взаимодействия с пользователем, оба могут быть запущены одновременно без взаимозависимости, эффективность разработки выше, а разделение труда относительно сбалансировано.

Как разделить переднюю и заднюю части

(Следующий контент основан на нашем веб-сайте по продаже билетов в кино для обсуждения) Внешняя техническая структура: ведро семейства vue + nodejs + экспресс (реализация одностраничного (SPA) приложения) Прежде всего сначала различают передний и задний конец работы

Работа с интерфейсом: реализовать всю интерфейсную страницу и логику взаимодействия, а также использовать ajax для взаимодействия с сервером nodejs (средний уровень).
Внутренняя работа: предоставление интерфейса API, использование Redis для управления сеансом, взаимодействие с базой данных.

Вся структура нашего проекта выглядит следующим образом:

Далее перейдем к теме, как реализовать разделение фронта и бекенда

Вообще говоря, чтобы добиться разделения внешнего и внутреннего интерфейса, переднему концу необходимо открыть локальный сервер для запуска собственного внешнего кода, чтобы имитировать реальную онлайн-среду, а также для лучшей разработки. Поскольку вы находитесь в фактической разработке, вы не можете требовать, чтобы каждый интерфейс создавал среду java (php) и разрабатывал в среде java, что слишком дорого для изучения интерфейса. Но если сервер не включен локально, то не только не может имитировать онлайн-среду, но и столкнуться с междоменными проблемами, потому что, если написать статическую html-страницу и открыть ее прямо в директории с файлами, вы не сможете сделать ajax-запрос ( Браузерные междоменные ограничения), следовательно, вам нужно запустить сервер локально, но вы не хотите строить странную и огромную среду Java, что вы можете сделать? nodejs точно решает эту проблему. В нашем проекте мы используем экспресс-инфраструктуру nodejs для запуска локального сервера, а затем используем подключаемый модуль http-proxy-middleware для nodejs для пересылки запроса, отправленного клиентом на nodejs, на реальный сервер, чтобы nodejs действовал как средний слой. Таким образом, передняя часть может быть разработана без хлопот.
Так как фронтенд и бэкенд разделены, то при одновременной разработке фронтенда и бэкенда можно столкнуться с ситуацией, что фронтенд уже разработал страницу, но ждет бэкенд -конечный интерфейс API. Например, A отвечает за внешний интерфейс, а B — за внутренний. A может завершить базовую структуру за неделю и может продолжить разработку после совместной отладки интерфейса API. В это время B еще не реализовал требуемый интерфейс, что делать в таком случае? В нашем проекте мы используем макет для предоставления некоторых поддельных данных.Сначала мы определяем интерфейс API и разрабатываем набор документов API.Затем мы можем использовать макет (mockjs.com) для возврата каких-то поддельных данных, чтобы можно было смоделировать весь процесс от отправки API до получения ответа, поэтому интерфейс не должен зависеть от разработки бэкенда, его можно разрабатывать независимо, и он может быть быстрее после совместной настройки внутреннего API.

Зачем вводить nodejs в качестве среднего уровня

На диаграмме структуры проекта, которую я разместил ранее, показано, что в этом проекте мы используем nodejs в качестве среднего уровня, так почему же мы специально вводим nodejs? Разве вы не можете просто сделать это напрямую с помощью java?

Я думаю, что введение nodejs в основном для иерархической разработки и разделения обязанностей.Как внешний сервер, разработчики переднего плана несут ответственность за nodejs.Разработчикам внешнего интерфейса не нужно знать, как реализован фон Java, ни как интерфейс API реализован.Нам нужно только заботиться о нашей фронтенд-разработке и управлять фронтенд-сервером nodejs, а бэкенд-разработчику не нужно учитывать, как развертывается фронтенд.Ему нужно только делать то, что у него хорошо получается, и предоставлять хороший API-интерфейс;
Сам Nodejs обладает уникальными характеристиками асинхронного и неблокирующего ввода-вывода, а это означает, что он особенно подходит для операций с интенсивным вводом-выводом и обладает сильной способностью обрабатывать запросы с большим количеством параллелизма.Поэтому он используется в качестве внешнего интерфейса Сервер, обслуживающий статические файлы для клиентов и отвечающий на запросы клиентов, я думаю, что это хороший выбор.

Как развертывается сервер переднего плана

Обязанности внешнего сервера nodejs

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

На самом деле развёртывание front-end сервера относительно простое, и есть следующие два момента:

Упакуйте разработанный интерфейсный код в статические сжатые файлы с помощью веб-пакета.
На сервере используйте балансировщик нагрузки pm2, чтобы выполнить следующий код для запуска сервера:

(PS: На самом деле, есть еще способ использовать nginx в качестве обратного прокси, который отвечает за переадресацию запросов, и перенаправляет запрос на разные сервисы в соответствии с URL-адресом, к которому обращается клиент. Например, запросы на доступ к /api /* перенаправляются в фоновый сервис. , для доступа к другим запросам он перенаправляется в сервис nodejs) Выше приведены некоторые из моих взглядов на разделение передней и задней частей, а также некоторые практики.Если у вас есть хорошие идеи, добро пожаловать на обмен. Адрес этого кода проекта:GitHub.com/deposition-more/… Поскольку фоновая служба этого проекта отключена, этот проект не может быть запущен. только для справки

Адрес этой статьи находится по адресу ->Адрес моего блога, добро пожаловать, чтобы начать или подписаться