Background?
В процессе развития бизнеса техническая команда уже не та первоначальная, или все уже сделано, и все специально напали на каждого человека. Затем, как уменьшить сцепление вперед и назад, каждый из которых работает независимо, это проблема, которую мы глубоко заслужили.
Problems
- Среда: для локальной разработки требуется внутренняя среда, такая как Tomcat и PHP, что влияет на эффективность разработки.
- Процесс: Front-end разработка сначала разрабатывает html, а затем переписывает html в указанный синтаксис шаблона (широко известный как набор шаблонов), что влияет на эффективность разработки.
- интерфейс:
- В определениях интерфейса обычно используются текстовые документы, поэтому во время разработки интерфейса трудно понять поля интерфейса, что влияет на эффективность разработки.
- Изменения интерфейса необходимо переписывать и отправлять повторно, что влияет на эффективность разработки
- Документы разбросаны, что мешает обслуживанию интерфейса
- Совместная отладка:
- Процесс совместной отладки становится очень сложным, особенно для проектов Java без горячего развертывания, и для изменения представления необходимо перезапустить Tomcat, что влияет на эффективность совместной отладки внешнего интерфейса.
- выгода:
- Фронтенд-разработка больше фокусируется на пользовательском опыте, а бэк-енд хочет сосредоточиться только на надежных данных.Для достижения некоторых взаимодействий, таких как отзывчивость и ssr, интерфейс должен контролировать определенные возможности ответа на запрос.
- Если способ стыковки внешнего и внутреннего интерфейса будет изменен на чистый обмен JSON, это будет полезно для повышения эффективности разработки, более четкого распределения обязанностей и повторного использования интерфейса.
Если что-то влияет на эффективность разработки, значит, проблема в существующей модели.
Очевидно, что идея решения проблем требует от нас переосмысления определения «внешняя часть и внутренняя часть».
В этот момент возникла концепция разделения фронтенда и бэкэнда, чтобы настроить совместную работу фронтенд и бэкенд разработчиков так, чтобы это было максимально удобно для всех.
Solutions
1. Разделение front-end и back-end этапа разработки на основе создания инструментов
Solution
- Перед разработкой: внешний и внутренний интерфейс согласовывают данные JSON, включая данные рендеринга страницы и некоторые ответы API, а серверная часть отвечает за их сортировку и определение на платформе документа интерфейса;
- В разработке: Front-end разработка использует Dev Server для разработки своих собственных страниц и локально моделирует ранее согласованные данные, в то время как back-end разработка больше фокусируется на данных, предоставленных в front-end соглашении;
- Совместная отладка: Dev Server изменяет данные JSON с локального на серверный хост)
Summary
- Это решение больше похоже на оптимизацию процессов, оно существенно не решает проблему разделения труда между фронтендом и бэкендом, но эффективность разработки действительно значительно повышается.
Problems
- Шаблонная часть по-прежнему зависит от бэкенда, а рендеринг по-прежнему остается черным ящиком, что мешает фронтенд-разработке и проблемам с позиционированием.
Во-вторых, начало эпохи MV *
Solution
Браузер предлагает возможность:
- Частичное обновление: ajax
- Внешняя маршрутизация: хэшрейт/история
Фреймворк и инструментальная поддержка:
- Фреймворк: vue/реагировать
- Фронт-тренажер Vue-маршрутизатор / React-маршрутизатор
- Фронтальное хранилище данных: vuex/redux
Разделение труда на переднем и заднем концах приспособлено для:
| задняя часть | внешний интерфейс |
|---|---|
| предоставить данные | получать данные, возвращать данные |
| обрабатывать бизнес-логику | Логика обработки рендеринга |
Summary
- Улучшение устройства мобильного устройства не является узким местом;
- Большинство страниц запускаются в приложении или требуют входа в систему, а требования к поисковой оптимизации постепенно снижаются;
- Частичное обновление — очень эффективный способ улучшить взаимодействие с пользователем.
Problems
- Вам нужно дождаться прибытия ресурсов, прежде чем продолжить, появится короткий белый экран и мигание
3. Средний уровень Nodejs
Большой убийца — средний уровень node.js
Серверная часть, управляемая Java/PHP, сильно ограничивала наше воображение, поэтому мы решили бунтовать. Фронтенд-разработка, как центр пользовательского опыта, заслуживает шлюза, отвечающего за взаимодействие с пользователями.
Solution 1 - Proxy Server
HTTP-прокси перенаправляет запросы пользователей, слой node.js — это легкий сервер, который не заботится о конкретной бизнес-логике, все запросы будут перенаправляться на бэкэнд.Tomcatилиphp
Уведомление:
- Принесите поля, которые необходимо преобразовать, напримерip
- используя node.js
agentмодуль, включить httpconnection: keep-alive, чтобы установить пул соединений для поддержания длинных соединений и сокращения потерь времени при частом установлении соединений.
Dependencies
- koa - proxy - middleware
Solution 2 - RPC
Вызовите некоторый API, сообщив целевому серверу имя метода и метод для передачи параметров.
Серверная часть принимает режим микросервисов, а node.js используется в качестве шлюза для взаимодействия с пользователем.Для различных сценариев спроса он выполняет комбинированные вызовы некоторых служб на серверной части и, наконец, предоставляет три вызова интерфейса: wap/веб/приложение.
Уведомление:Бэкенд-архитектура для микросервисов.
Dependencies
- Клиент, вызываемый rpc, имеет следующие идеи:
- генерировать
调用方法名а также调用参数Включить данные - encode
- Отправлять данные через сокет и получать ответ от целевого сервера
- decode
- генерировать
- Фреймворк разработки Node.js (спецификация веб-разработки) — eggjs/nestjs/github.com/kappjs/kapp
Node.js server's common dependencies
- журнал
- Ведение журнала — журналы pm2 /log4js
- Многопроцессорность и балансировка нагрузки запросов — pm2
- Многопроцессорность — в полной мере используйте многоядерность, балансировка нагрузки — разумно распределяйте запросы по каждому подпроцессу.
- Монитор и сигнализация
- Ведение журнала мониторинга
- Сбор элементов мониторинга — анализ некоторых данных мониторинга из журналов.
- медицинское обследование
- Проверьте, доступен ли прокси-сервис и доступен ли сервис rpc, чтобы определить, доступен он или нет.Если он недоступен, уведомите nginx, чтобы он прекратил перенаправление трафика на этот сервер.
- Центр распределенной конфигурации
- Единая конфигурация каждого проекта
- Измените конфигурацию для немедленного обновления онлайн
Summary
- Фронтенд-разработка должна быть сосредоточена на некоторых знаниях, возможностях и проблемах на стороне сервера.
- Надежность и стабильность серверных сервисов напрямую определяют эффективность разработки вызовов сервисов nodejs.
- Макет пути к более абстрактному интерфейсу
- Чтобы контролировать шлюз взаимодействия с пользователем, наша цель состоит в том, чтобы улучшить взаимодействие с пользователем и предоставить возможность для последующего внедрения решений для рендеринга на стороне сервера, которые выходят из-под контроля.
The End
Прогрессивная схема разделения фронтенда и бэкенда (личный опыт):
- Используйте разработку Mock Server, не вторгивайте существующие модели;
- Я чувствую, что необходимо управлять сервером, чтобы раскрыть наше воображение, и ввести средний уровень прокси-сервера Node.js, который отвечает только за пересылку запросов. В течение этого периода инфраструктура Node.js постоянно улучшалась;
- Если объем бизнеса огромен и есть спрос на микросервисы, процесс обслуживания внутреннего интерфейса продвигается, и Node.js использует RPC для вызова внутреннего интерфейса; в противном случае объем бизнеса невелик, а задний -end предоставляет некоторые интерфейсы веб-служб Node.js Использовать неблокирующий метод http для вызова сборки.