Введение: Эта статья анализирует проблему, которую передний и задний конец не может быть разрабатывается синхронно из-за взаимодействия интерфейса в разделе «Разделенный режим разработки передней и задней части» и предлагает всеобъемлющее решение для оптимизации процесса взаимодействия интерфейса и улучшения Эффективность развития.
В настоящее время, благодаря широкому применению фреймворка MVVM, модель разработки передней и задней частей становится лучше и более предпочтительной для большинства разработчиков. Внешняя и задняя части разделены, то есть внутренний персонал отвечает за написание фоновой бизнес-логики.Внешний персонал использует пакетный инструмент, такой как WebPack, и две внешние страницы обмениваются. Страница обрабатывается внешним интерфейсом в соответствии с данными интерфейса, а не бэкендом.
Этот режим разработки позволяет параллельно разрабатывать интерфейс и сервер и выполнять свои собственные обязанности, что не только повышает общую эффективность разработки проекта, но также позволяет различным ролям играть свои собственные функции.
В чем проблемы взаимодействия front-end и back-end через интерфейсы?
Проблема 1: Полагаясь на внутренний интерфейс, внешний интерфейс нельзя разработать независимо
После разделения наиболее важной частью взаимодействия между интерфейсом и сервером является интерфейсное взаимодействие. Предположим, требуется разработать страницу, отображающую информацию о пользователе. До того, как back-end предоставит интерфейс, front-end не знает, в каком формате данные вернет back-end интерфейс, и какое поле использовать для получения требуемых данных, поэтому front-end не может разработать логику страница, особенно текущая структура MVVM, которая состоит из данных. Для управления страницей, при отсутствии данных, ход работы внешнего интерфейса будет зависеть от хода интерфейса, предоставляемого серверной частью, что противоречит видение раздельной разработки между фронтендом и бэкендом.
Вопрос 2: Серверная часть предоставляет интерфейсные документы, а передняя часть должна записывать смоделированные данные
После того, как серверная часть предоставляет документ интерфейса, предполагается, что документ определяет интерфейс для получения информации о пользователе следующим образом:
// 接口路径： /getUserInfo
// 接口参数：
{
id: 123;
}
// 返回数据
{
"name":"张三",
"id":123,
"role":"admin"
}
После получения вышеуказанных документов, поскольку серверная часть в настоящее время не разработала соответствующий интерфейс, интерфейсная часть не может подключиться к внутреннему серверу для получения данных. В настоящее время для написания логики внешний интерфейс может создавать только смоделированные данные в соответствии с документом интерфейса, поскольку интерфейс нельзя настроить. На этапе совместной отладки необходимо удалить построенные данные моделирования, которые полностью бесполезны после перехода в онлайн, что является пустой тратой рабочей нагрузки.
Вопрос 3: Для тестирования интерфейса на бэкенде вам нужно полагаться на такие инструменты тестирования, как postman.
Когда серверная часть разработана и интерфейс завершен, необходимо выполнить тестирование интерфейса. Если страница не была завершена в это время, серверная часть может только построить смоделированные данные о почтальоне в соответствии с документом интерфейса, а затем вызвать свой собственный интерфейс через почтальона для просмотра возвращенных данных. Сравнивая возвращенные данные с возвращенными данными, определенными в документе интерфейса, вы можете узнать, вернул ли ваш сервер данные в соответствии с документом. В этом процессе определение смоделированных данных о почтальоне является рабочей нагрузкой, и сравнение данных с человеческими глазами также является рабочей нагрузкой, и эффективность разработки значительно снижается.
Вопрос 4: Доработан ли интерфейс, есть ли проблема с интерфейсом, и требуется ли частая связь между фронтом и бэкендом
Поскольку документация по интерфейсу не обновляется вовремя, и нельзя гарантировать, что документация по интерфейсу, находящаяся в руках каждого члена команды, является самой последней версией, или даже интерфейс изменился в процессе фактического процесса разработки, но документация не обновляется, только вербальное общение приведет к ошибкам общения членов команды, что приведет к проблемам с переработкой или даже к конфликтам в команде:Почему изменение интерфейса не уведомляет меня?
решение
Рождение платформы управления интерфейсом
Чтобы решить проблему, связанную с невозможностью обновления документов интерфейса в режиме реального времени, можно разработать платформу управления интерфейсом для определения тела запроса и тела ответа для каждого интерфейса на платформе.Когда интерфейс необходимо изменить, его можно изменить. прямо на платформе. При этом платформа записывает журнал изменений каждого интерфейса, что удобно для отката и просмотра того, что было изменено.
Если на предприятии есть коммуникационный инструмент, вы можете наследовать внутренний инструмент связи. Когда интерфейс изменен, он автоматически отправит уведомление членам команды для информирования измененного контента. Таким образом, все документы в команде могут Будьте гарантированно быть в курсе.
При этом платформа должна поддерживать функцию экспорта интерфейсных документов, ведь многим командам нужны электронные документы для резервного копирования. Однако это просто несущественная функция. Эта платформа должна преследовать цель: завершить весь жизненный цикл управления интерфейсом на другой платформе.
Управление жизненным циклом интерфейса
С онлайн-управлением интерфейсом можно осуществлять управление жизненным циклом интерфейса, например, можно отметить, находится ли интерфейс на определенной стадии, на стадии совместной отладки или на завершенной стадии. Статус интерфейса ясен с первого взгляда.
Эта платформа имеет все данные интерфейса и может возвращать смоделированные данные в соответствии с определением интерфейса. Таким образом, все интерфейсы развернуты на этой платформе, сгенерирован смоделированный базовый URL-адрес, и обратный прокси-сервер внешнего интерфейса запрашивает все интерфейсы по этому адресу, можно получить смоделированные данные и разработать соответствующую логику. На этом этапе интерфейс может завершить работу по разработке, не полагаясь на серверную часть.
Для серверной части, если вам нужно протестировать собственный интерфейс, вы можете нажать кнопку тестирования на странице, браузер отправляет запрос, а платформа отображает данные ответа. В то же время, поскольку платформа интерфейса уже имеет определение возвращаемых данных, после получения фактических данных интерфейса платформа управления интерфейсом может сравнить структуру и дать подсказку, чтобы студенты, работающие на внутреннем уровне, могли легко узнать, являются ли их интерфейс правильный или нет.
Решение междоменных проблем
Существует проблема с запросом моделирования интерфейса, предложенным выше.Когда пользователь нажимает тест на платформе управления интерфейсом, если страница напрямую запрашивает сервер пользователя, возникает междоменная проблема.
Одно из решений состоит в том, что страница отправляет данные запроса на внутренний сервер платформы управления интерфейсом, а внутренний сервер отправляет запрос от своего имени, а затем возвращает полученные данные на страницу.В восприятии пользователя страница напрямую отправляет запрос.
Однако, хотя приведенное выше решение позволяет избежать междоменной проблемы, оно не может получить файл cookie целевого сервера, что может вызвать проблемы для веб-программ, использующих файлы cookie.
Это приведет к другой программе: плагин Chrome.
Применение плагина для хрома
Как было сказано выше, когда пользователь отправляет запрос на странице системы А, cookie в системе Б не может быть прочитан, что может привести к некорректной работе системы.
Есть ли решение для получения всех системных файлов cookie? Ответ - да, то есть использовать плагин Chrome.
Плагин для хрома — это расширение функций браузера, позволяющее пользователям писать свои собственные плагины для расширения функций хрома, при этом плагин для хрома не имеет междоменных проблем и может читать любые информация на любой странице. Что касается разработки плагинов для Chrome, я не буду здесь вдаваться в подробности.
Поэтому мы можем разработать плагин для Chrome. Когда пользователь нажимает кнопку тестирования, плагин отправляет запрос от своего имени. После того, как плагин получит данные ответа, он возвращает данные на страницу для отображения.
На данный момент последняя оставшаяся проблема: интерфейс FBI.
Например, мы управляем интерфейсом A на платформе управления интерфейсом, и его информация выглядит следующим образом:
// 接口路径： /getUserInfo
// 接口参数：
// 反向代理地址： http://xx.com（该地址为接口管理平台生成的地址）
// 后端服务器地址： http://back.com（该地址为后端同学的服务器地址）
{
id: 123;
}
// 返回数据
{
"name":"张三",
"id":123,
"role":"admin"
}
Рабочий процесс выглядит следующим образом:
-
Обратный прокси-сервер Front-end дляxx.com
-
Внешний интерфейс запроса: /getUserInfo и отправка данных {id:123}
-
Платформа управления интерфейсом получает запрос интерфейсного проекта, сопоставляет соответствующий интерфейс и запрашивает статус интерфейса.
-
Если статус интерфейса должен быть разработан, запросите определенные данные моделирования и верните данные. То есть возвращаются следующие данные:
{ "name":"张三", "id":123, "role":"admin" } -
Если статус интерфейса завершен, платформа управления интерфейсом перенаправляет запрос на http://back.com (адрес бэкенд-одноклассника).После получения данных платформа управления интерфейсом возвращает данные на фронт- завершение проекта, включая заголовок запроса, отдел и другую информацию.
Пока весь процесс пройден.
статус-кво
В настоящее время многие компании запустили свои собственные инструменты управления интерфейсом, но продукты каждой компании более или менее несовершенны, в связи с этим я провел небольшое исследование для вашей справки: