Используйте svrx для реализации более элегантного интерфейса Mock

внешний интерфейс koa
Используйте svrx для реализации более элегантного интерфейса Mock

предисловие

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

В зависимости от схемы макета интерфейса существуют различные, но обычно не более чем «жесткое кодирование», «перехват внешнего интерфейса» и «перехват внутреннего интерфейса». В этой статье мы попытаемся кратко проанализировать преимущества и недостатки этих трех распространенных решений, а затем перейти к основным вопросам: на основеsvrxМакет интерфейса.

жестко запрограммированная схема

Жесткое кодирование — это запись фиктивных данных непосредственно во внешнем коде, например:

function getUser(id) {
  return { username: 'mock username', id: 100 }; //接口mock
  return ajax('/user', { id });
}

Просто удалите или закомментируйте при отправке:

function getUser(id) {
  // return {username: 'mock username', id: 100}
  return ajax(`/user/${id}`);
}

То же самое относится и к жестко закодированному фиктивному методу бэкенда, но его навязчивость остается в логике бэкенда, а бизнес-код внешнего интерфейса можно поддерживать в чистоте:

router.get('/user/:id', async ctx => {
  ctx.body = { username: 'mock username', id: 100 };
  // ctx.body = await userService.get(ctx.params.id);
});

Примечание. Приведенный выше пример основан на платформе Koa.

Преимущества жесткого кодирования

  • Простой и гибкий, он не требует поддержки каких-либо инструментов и фреймворков и может использоваться на месте.
  • Если это жестко закодировано на внешнем интерфейсе, модификация поддержки вступает в силу, и нет необходимости перезапускать сервер.

Недостатки жесткого кодирования

  • Связывание макета интерфейса и бизнес-кода,Копать яму круто, наполнить крематорий.

Подсчитано, что многие люди проделали такую ​​неряшливую операцию, когда были молоды, и они забыли удалить сцену автомобильной аварии, которая привела к уносу личных вещей онлайн. Независимо от того, используете ли вы какую-либо профессиональную мокационную структуру (например,mock.js), этот способ связи в бизнес-логике, очевидно, является последним средством, и ваше имя может часто появляться в онлайн-отчетах об авариях.

Слегка придирчивые учащиеся могут сотрудничать с инструментами конструирования (такими как веб-пакет), чтобы добиться изоляции локального фиктивного кода и бизнес-кода, но эта взаимосвязь по существу не решена.По мере повторения проекта проект также станет трудным для поддерживать. .

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

Этот аспект делится на внешний перехват и внутренний перехват.Как показано на следующем рисунке, ответ данных перехватывается напрямую и возвращается в соответствующем аспекте:

Фронтальный перехват

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

Настройка контейнера веб-просмотра

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

сетевой перехват

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

public WebResourceResponse shouldInterceptRequest(final WebView view, final String urlstr)

Этот контент не является основной темой данной статьи и не будет развиваться дальше.

внедрение скрипта

И Android, и iOS имеют возможность внедрять логику JS непосредственно в Webview, что также реализует уровень связи Bridge в гибридных приложениях.

Если вы волшебным образом измените нативные объекты, такие как fetch или XMLHttpRequest, в скрипте внедрения, вы сможете перехватить и переписать ответ.

Примеры ключевых API iOS

[self.webView stringByEvaluatingJavaScriptFromString:injectjs];

Фрагмент кода ключа Android

webView.loadUrl("javascript:" + injectjs);

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

плагин для браузера

По сравнению с пользовательскими контейнерами Webview плагины для браузера, очевидно, являются более дешевым внешним решением для захвата контейнеров. кcode-mancers/interceptorПример этого проекта:

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

Анализ внешнего перехвата

Есть интерфейс для перехвата двух естественных преимуществ:

  • Доступен интерфейс конфигурации: поскольку он перехватывается на стороне браузера, вы можете использовать API DOM, чтобы предоставить, например.Плагин перехватчиканастраиваемый интерфейс.
  • на месте: Нет необходимости перезапускать службу после модификации.

Но будь то плагин для браузера или пользовательский контейнер Webview, мы на самом деле игнорируем важный факт:Браузерная среда на самом деле весьма разнообразна. Это приводит к типичной уязвимости во фронтальном перехвате:Недоступно в разных браузерах, как в примере вышеПлагин перехватчикаЕго нельзя использовать в браузере WeChat.

Этого можно избежать, если он будет перехвачен сервером.

Схема перехвата сервера

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

полосатый сервер разработки

Для удобства сKoaНапример, чередование сервера разработки:

const proxy = require('koa-proxy');
const Koa = require('koa');

const app = new Koa();
app.use((ctx, next) => {
  switch (ctx.path) {
    case '/api/blog':
      ctx.body = { type: 'blog' };
      break;
    case '/api/user':
      ctx.body = { type: 'user' };
      break;
    default:
      return next();
  }
});
app.use(
  proxy({
    host: 'http://api.yoursite.com'
  })
);

app.listen(8000, () => {
  console.log(`server start at http://localhost:8000`);
});

Как видно из приведенного выше примера, по умолчанию интерфейс будет проксироваться наapi.yoursite.com(ваш целевой API или внутренний сервер друга). Фиктивные данные имеют приоритет над реальными прокси-интерфейсами, например, когда мы обращаемся кhttps://localhost:8000/api/user, который возвращает наши фиктивные данные. Если вам нужно добавить фиктивные интерфейсы позже, вам нужно продолжать добавлять ветки case.

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

Профессиональный сервер разработки

Из-за очевидных болевых точек чередования серверов некоторые решения, ориентированные на серверную область разработки, стали популярными, например, знакомыйwebpack-dev-server.

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

module.exports = {
  //...
  devServer: {
    port: 9000,
    headers: {
      'X-Custom-Foo': 'bar'
    },
    proxy: {
      '/api': 'http://localhost:3000'
    },
    before(app) {
      // 配置mock逻辑
      app.get('/api/blog', function(req, res) {
        res.json({ custom: 'response' });
      });
    }
  }
};

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

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

  • Горячая перезагрузка не поддерживается: Каждый раз, когда вы изменяете фиктивные правила, вам необходимо перезапустить сервер.
  • Не интуитивный: фиктивные правила смешиваются с другими конфигурациями серверов, и для игроков, не являющихся узлами, требуется высокая стоимость обучения.
  • Поддержка интерфейса недоступна, по сравнению с внешним перехватом, он не может предоставить возможности настройки графического интерфейса.

Эффективная имитация интерфейса с помощью svrx

Из вышеприведенного анализа можно сделать вывод, что существуют некоторые существенные дефекты в перехвате переднего плана и перехвате заднего конца. Есть ли способ одновременно использовать преимущества внешнего и внутреннего интерфейсов? ответsvrx.

Рекламное предупреждение о высокой энергии, увидев этот шаг, я считаю, что вы уже являетесь потенциальным клиентом svrx.

Введение в svrx

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

  • Передний модуль впрыска: svrx перехватывает все html-ответы и внедряет начальные сценарии, которые интегрируют и управляют зарегистрированными интерфейсными ресурсами (JS, CSS).
  • Бэкенд-модуль внедрения: svrx имеет встроенный модуль регистрации мидлвара с приоритетом.
  • Внешние и внутренние коммуникационные модули: метод связи внешнего и внутреннего внедрения унифицирован (на основе веб-сокета), а обмен событиями или сообщениями может выполняться изоморфным способом.

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

svrx также извлекает общие функции dev-сервера и интегрирует их как встроенный плагин (включая livereload, прокси, https и т. д.), а также функции в других проприетарных областях (таких как уценка, qrcode и т. д.). предоставляется в виде внешних плагинов для максимального достижения баланса удобства и гибкости.

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

Установить

npm install @svrx/cli -g

Примечание. Все последующие возможности подключаемых модулей не требуют явной установки.

использовать

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

svrx

svrx Routing DSL реализует макет интерфейса

В зависимости от требований макета интерфейса мы можем напрямую использовать встроенныйФункция динамической маршрутизации:

touch route.js
svrx --route route.js

Выше показан интерфейс успешного запуска, вroute.jsДобавьте следующий код:

get('/api/user/:id').to.json({ name: 'svrx' });

браузер открыт/api/user/1, вы можете увидеть соответствующий ответ JSON. все вroute.jsизменения поддерживаютсяhot reloadДа, нам не нужно перезагружать сервер.

БолееДля получения руководства по использованию svrx Routing DSL щелкните здесь.

Если вы используете маршрут svrx для замены других вышеперечисленных dev-серверов, в дополнение к более интуитивному и эффективному написанию маршрута, он также имеет эффект более тонкого управления приоритетом маршрута, например, приоритетом макет и прокси:

get('/api/user/:id').to.json({ name: 'svrx' });
post('/api/blog(.*)').to.proxy('http://path.to.api.com');
get('/(.*)').to.send('404 PAGE IS NOT FOUND');

Примечание. Чем более продвинутое правило маршрутизации, тем выше приоритет.

Используйте плагин mock, чтобы быстро имитировать интерфейсы.

Прямое использование маршрута svrx напрямую может решить функциональную проблему макета, но не может решить проблему эффективности макета.

Исходя из этого, svrx официально предоставляетsvrx-plugin-mock, Имеет встроенные полезныеmock.js, что помогает нам реализовать быстрое моделирование данных:

svrx --mock --route route.js

Использовать напрямую-p mockили сокращенно--mockдля активации плагина.

Как показано в красной рамке выше, подключаемая система svrx имеетОсобенности первой установки, установленный плагин автоматически войдет в глобальное управление svrx,Последующая активация плагина не требует повторных загрузок,важнеене будет загрязнять ваш рабочий каталог(включатьnode_modules).

существуетroute.jsДобавьте следующий код в:

get('/api/user/:id').to.mock({
  name: '@name',
  email: '@email'
});

Мок-плагин регистрируетДействие маршрутизации, который можно использовать в DSL маршрутизации

посетить снова/api/user/1, вы получите следующие случайные ответы, соответствующие определенному шаблону, например:

{
  "user": "Linda Thomas",
  "email": "g.ykyiexto@toaloso.cc"
}

Кроме того, фиктивный плагин также может быстро имитировать некоторую логику цикла списка, например:

get('/api/user/:id').to.mock({
  name: '@name',
  email: '@email',
  'region|1-3': ['@region']
});

соответствующий ответregionбудет массивом областей длиной от 1 до 3, например:

{
  "name": "Nancy Allen",
  "email": "aopao@qpo.scm",
  "region": ["西北", "华中"]
}

можно увидеть с помощьюmockПлагины могут значительно повысить эффективность наших макетов и при этом оставаться интуитивно понятными.

Используйте json-сервер для создания пакетного интерфейса на основе определенных правил.

Плагин svrx mock плюс встроенная динамическая маршрутизация могут в основном эффективно обрабатывать 90% локальных фиктивных требований.

Но если ваша служба основана наjson-serverканонический, вы также можете использоватьsvrx-plugin-json-serverЧтобы быстро реализовать массивные интерфейсы, давайте попробуем вместе.

Сначала создайте следующее в текущем каталогеdb.jsonдокумент:

{
  "posts": [{ "id": 1, "title": "json-server", "author": "typicode" }],
  "comments": [{ "id": 1, "body": "some comment", "postId": 1 }]
}

запустите svrx и активируйтеjson-serverПлагин:

svrx -p json-server --route route.js

Подобно mock, плагин json-server регистрируетjsonServerизДействие маршрутизации.

существуетroute.jsДобавьте следующую конфигурацию:

route('/(.*)').to.jsonServer();

Приведенный выше оператор будет проксировать все запросы непосредственно во внутренний модуль json-server.

доступ/posts, вы увидите такой ответ:

[
  {
    id: 1,
    title: 'json-server',
    author: 'typicode'
  }
];

Стоит отметить, что на самом деле в json-сервере есть все встроенные crud-операции дляpostsНапример:

POST /posts        => Create 即创建操作
UPDATE /posts/:id  => UPDATE 即更新操作
GET /posts/:id     => READ 即读操作
GET /posts         => READ LIST 即列表读操作
DELETE /posts/:id  => DELETE 即删除操作

Например, когда вы инициируетеСоздайтеЗапрос (в качестве примера возьмем выборку из внешнего интерфейса):

fetch('/posts', {
  method: 'POST',
  body: JSON.stringify({ title: 'svrx', author: 'x-orpheus' }),
  headers: {
    'content-type': 'application/json'
  }
});

вы посетите снова/postsсписок, вы найдете еще одну запись,И эта запись будет сохраняться синхронно сdb.json:

[
  {
    id: 1,
    title: 'json-server',
    author: 'typicode'
  },
  {
    title: 'svrx',
    author: 'x-orpheus',
    id: 2
  }
];

Просьба переписать

Конкатенируя директиву перезаписи маршрута, мы можем направить только часть трафика на сервис json-server, например:

route('/api/(.*)')
  .rewrite('/{0}')
  .to.jsonServer(); // /api/posts => /posts

так что только/apiПервый запрос будет проксирован на json-сервер, а остальные запросы могут пройти через другую фиктивную логику.

Используйте интерфейс для управления платформой

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

Фактически, более крупные команды должны иметь платформу управления интерфейсом API для единообразного управления определением интерфейса.В Netease мы используемNEI: Платформа управления интерфейсомдля управления API (поддерживается командой облачного музыкального интерфейса, бесплатная пробная версия приветствуется). Как правило, на таких платформах есть функции имитации интерфейсов, и, проксируя на такие платформы, мы можем легко реализовать стандартизированную имитацию интерфейсов:

С помощью этой платформы управления интерфейсом команда облачной музыки также инкапсулировала svrx-plugin-nei (с открытым исходным кодом), чтобы реализовать моделирование данных агента для платформы NEI, как показано на следующем рисунке:

Моделирование интерфейса на основе платформы управления интерфейсом соответствует спецификации реального интерфейса, поэтомуВнешние и внутренние спецификации будут более согласованными, и его свойство платформы такжеРазработчикам удобно делиться конфигурацией. Но у этого метода есть и огромный недостаток, т.Гораздо менее гибкий, чем эмуляция собственного интерфейса.

Стоит упомянуть, чтоЭтот плагин использует возможности внешнего внедрения svrx для реализации внешнего интерфейса конфигурации кросс-браузера., svrx автоматически внедряет исходные сценарии для ресурсов, ответ которых имеет тип html, через внутренний модуль инжектора.Исходный сценарий интегрирует содержимое сценария, зарегистрированное всеми плагинами, таким образом реализуя внедрение логики внешнего интерфейса на стороне dev-сервера.

Разобрать основное значение svrx через mock

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

Итак, то, что приносит нам svrx, на самом деле неsvrx-plugin-mock,svrx-plugin-json-serverилиsvrx-plugin-neiи так далее по этим изолированным единичным функциям, Но на основе платформы svrx мы можем легко обернуть их вокругdev-serverФункция поля начинается сУнифицированный способ интеграции и использования, позволяющий избежать дублирования работ по установке и настройке.

Возьмите каштан 🌰, когда разработчики хотят, чтобы вывод формата ответа JSON выглядел лучше, они могут напрямую использовать-p json-viewerЧтобы активировать соответствующий плагин:

svrx --route router.js \
  -p json-viewer \
  -p json-server \
  -p mock

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

Плавно переключитесь на интуитивно понятное следующее изображение:

Еще один каштан 🌰, когда мы хотим выставить наш локальный сервис во внешнюю сеть, мы можем использовать-p localtunnelактивацияlocaltunnelСлужба шлюза обратного туннеля.

svrx --route route.js \
  -p json-viewer \
  -p json-server \
  -p mock \
  -p "localtunnel?host=https://tunnel.svrx.io"
  • Может использоваться, когда параметр слишком длинныйфайл конфигурации svrxсередина
  • Tunnel.svrx.io является социальным объектом и не гарантирует стабильность. Пожалуйста, используйте его медленно, чтобы сервис не был недоступен по разным причинам.

Похоже на картинку вышеfast-dragon-86.tunnel.svrx.ioСлучайный адрес можно использовать в качестве доменного имени для доступа к внешней сети.Такого рода мгновенные возможности не могут быть предоставлены вам различными платформами фрагментированных серверов разработки.

Что еще более важно, макет интерфейса на самом деле является лишь частью нашей повседневной разработки.svrx позиционируется как универсальный сервер разработки, который имеет встроенный интегрированныйserve,proxy,livereload,routeИ так далее по основным функциям в ежедневной фронтенд-разработке, и через сообществоРастущий пул плагиновДля использования свободной комбинации мы должны были видеть из описания приведенного выше сценария макета интерфейса.

Вполне можно сказать, чтоЧем больше объектов вокруг dev-сервера, тем ценнее svrx.

напиши в конце

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

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

Links

Эта статья была опубликована сКоманда внешнего интерфейса NetEase Cloud Music, Любое несанкционированное воспроизведение статьи запрещено. Мы всегда нанимаем, если вы готовы сменить работу и вам нравится облачная музыка, тоПрисоединяйтесь к нам!

Категории