Frontier: Здравствуйте, я Шу Цзян. Сегодняшняя гидрология посвящена битве между интерфейсом и сервером, которая с момента разделения интерфейса и сервера привела к множеству проблем со связью и даже битве. Давайте рассмотрим прошлое и настоящее фронтенд- и бэкэнд-баттлов.
1. Древние времена (web1.0 — архитектура MVC)
Я смутно помню, что когда я закончил колледж, первой установленной на моем компьютере IDE была не Webstorm и не VScode, а IntelliJ IDEA. Потому что для разработки front-end проектов нужно запустить полную JAVA-программу, различные maven-конфигурации, а затем выполнить front-end разработку на основе JSP-файлов, написанных в back-end. Другими словами, это «вторичный развитие". Теперь подумайте о медленной компиляции в то время. Сцена яркая. Другими словами, фронтенд-разработка сильно зависит от окружения.
Ale: Я помню, что тогда я предоставил только HTML-код, а затем использовал Sublime в качестве редактора и, наконец, интегрировал его в JSP.
Это другой режим, внешний интерфейс отвечает за вывод демонстрационного HTML-кода, а затем передает его серверной части для установки шаблона.
Это просто означает, что серверная часть полностью интегрирована, частота ошибок высока, и исправить ошибку очень сложно, что требует совместной работы обеих сторон. В обмен на дополнительные расходы на связь. Поскольку обязанности переднего и заднего плана легко перепутать, связь слишком сильна, и в конечном итоге это может привести к битве.
Суммируйте очки, которые генерируют битву👇:
- 1. Фронтенд-разработка сильно зависит от среды, что приводит к слишком долгому времени компиляции для каждого модифицированного файла, что проверяет терпение фронтенд-разработчиков.
- 2. Когда приложение необходимо обновить, внешний и внутренний интерфейсы нельзя обновить независимо друг от друга. Вместо этого обновите все монолитное приложение целиком.
- 3. После того, как серверная часть встраивает предварительно разработанную html-страницу во внешнем интерфейсе в файл JSP, отклонение фактического эффекта стиля слишком велико.
2. Железный век (архитектура web2.0-MVVM)
Появление front-end архитектуры MVVM способствует разделению front-end разработки и back-end бизнес-логики, и действительно реализует «разделение»: разделение труда и помощи, выполнение собственных обязанностей и отказ от привязки.
В настоящее время необходим «коммуникационный мост»: API, а затем совместная связь между интерфейсом и сервером реализуется через вызовы ajax. Оба также развязаны
Потребитель API (внешний интерфейс): понимание информации об интерфейсе через документацию по интерфейсу, фокус: прием данных, обработка данных и обработка логики рендеринга.
Производитель API (бэкенд): предоставить интерфейс и документацию по интерфейсу Фокус: предоставить данные, предоставить документацию по API
Процесс разработки тоже начал меняться👇:
- Серверная часть пишет и поддерживает документацию по интерфейсу и обновляет документацию по интерфейсу при изменении API.
- Back-end разрабатывает интерфейс в соответствии с интерфейсным документом
- + Макет платформы для разработки интерфейса на основе документации по интерфейсу
- После завершения разработки отправка на согласование теста
А Ле: После того, как фронтенд и бэкэнд разделены, сначала развиваются бэкенд-студенты или фронтенд-студенты?
Из приведенного выше процесса разработки мы видим, что после разделения документ интерфейса является наиболее важным коммуникационным мостом. В соответствии с важным первым принципом, документация становится первичным фактором.Рекомендуется, чтобы документация по интерфейсу была на первом месте, то есть API-First, без документации по интерфейсу практически невозможно запустить интерфейс.
Чувак-одноклассник: Чтобы внешний интерфейс одноклассника мог совместно вызывать отладку почтальона, mock использует Yapi или RAP2 для создания поддельных данных, есть ли лучший инструмент, чтобы сделать это за один шаг?
Раньше у меня в левой руке был почтальон, в правой япи, а посередине код.
Можешь попробоватьApifox
Официальное введение:ApifoxЭто интегрированная платформа для совместной работы с документацией API, отладкой API, макетами API и автоматическим тестированием API.Postman + Swagger + Mock + JMeter
Передние студенты могут использовать Apifox для решения проблемы接口调试+数据Mockспрос
Поделитесь скриншотом фактической страницы ниже
Но новый процесс разработки также раскрывает новые боевые точки.
Суммируйте полученные боевые очки:
-
1. Страница должна запрашивать слишком много интерфейсов. Внешний интерфейс ожидает, что серверная часть выполнит агрегацию интерфейсов, чтобы уменьшить количество запросов. Серверная часть считает, что интерфейс разделен на обязанности в соответствии с микросервисами, и никакой связи не требуется.
-
2. Интерфейс, предоставляемый серверной частью, изменился, но интерфейсные документы не синхронизированы, или интерфейс, предоставляемый серверной частью, отсутствует, а внешний интерфейс не может быть правильно смоделирован и т. д.
-
3. Поля не унифицированы: Например, поля номеров мобильных телефонов, некоторые возвращают mobilePhone, а некоторые возвращают PhoneNumber, поля не унифицированы, что приводит к увеличению затрат на связь
3. Серебряный век (BFF Age)
С преобладанием микросервисов внутренний интерфейс данных был разделен.Предполагая, что интерфейсу нужны некоторые данные, он может зависеть от нескольких микросервисов, и необходимо выполнить агрегацию данных. В то же время, поскольку фронтенд находится ближе всего к пользователю, обращенному к различным мобильным устройствам, каждый клиент имеет разные требования к типу данных, например, данных, требуемых мобильным терминалом, не так много, и требуется дизассемблирование данных.
Будет сгенерирована сцена битвы, похожая на следующую👇:
Студенты Front-end и студенты Back-end имеют свои причины. Есть ли решение, которое может решить эту неловкую сцену, поэтому есть BFF. Полное название BFF — Backends For Frontends (обслуживание front-end backend)
Ниже уровня BFF находятся различные серверные микросервисы, а на верхнем уровне BFF находятся различные интерфейсные приложения (мультитерминальные приложения), которые вызывают вниз серверную часть как услугу, предоставляют интерфейсные услуги клиенту вверх. , а серверная часть обеспечивает внешний интерфейс уровня BFF. Уровень BFF напрямую вызывает интерфейс RPC сервера для получения данных и обрабатывает данные по мере необходимости для завершения замкнутого цикла всего BFF (в основном Node + GraphQL стек технологий)
Появление BFF действительно решило многие расходы на общение после фронтенда, и они стали более дружелюбны друг к другу, и диалог превратился в это
-
Бэкэнд: Эти микросервисы все здесь, смотрите состав, если будут вопросы, заходите ко мне
-
Внешний интерфейс: Хорошо, я смотрю на комбинацию
Детская обувь, интересующаяся BFF, может читать перед елкойВы изучили BFF и Serverless?
Прошлые популярные статьи📖:
- Вы заслуживаете следующих инструментов с открытым исходным узлом (ниже)
- Разработать большой экран визуальных данных от 0 до 1 (включено)
- Разработайте большой экран визуальных данных от 0 до 1 (ниже)
- Построение интерфейсной системы знаний Шуцзяна (часть 1)
- Построение внешней системы знаний Шуцзяна (ниже)
- Расскажите об инструментах ежедневной совместной работы для фронтенд-разработки
- Конфигурацию Babel тупо не могу понять
- Как лучше управлять интерфейсом API
- Что интервьюер спросил вас об узле
- передовой инжиниринг
- Вы изучили BFF и Serverless?
- Развертывание интерфейсной эксплуатации и обслуживания
Привет, я 🌲 Tree Sauce, пожалуйста, выпей 🍵 Запомни три раза подряд~
1. Не забудьте поставить лайк после прочтения, есть 👍 и мотивация
2. Обратите внимание на интересные вещи в интерфейсе официального аккаунта и пообщайтесь с вами об интересных вещах в интерфейсе.
3. Статья попала в Github frontendThings благодаря Star✨