Средний уровень узла междоменного решения

Node.js

обет

В предыдущей статье «Кроссдоменное решение Vue-cli 3.x + axios наступает на пит-гид на север» было сказано, что прохождениеwebpack配置proxy代理Междоменная реализация является лишь удобством в среде разработки.Когда исходный код упакован как статические ресурсы, при фактическом запуске нет необходимостиdevServerЧтобы помочь вам перенаправить запрос, в конце статьи также устанавливается флажок, говорящий о том, что в следующий раз, когда вы будете говорить об этой междоменной проблеме, попробуйте найти ответ. Во время моей недавней стажировки, благодаря общению с моим наставником и собственному пониманию, я обнаружил, что средний уровень Node является распространенным междоменным решением при текущем режиме разработки с разделением интерфейса и сервера. такой же какproxyпочти, не болееproxyИменно devServer предоставляет арку, а средний уровень Node должен реализовать ее самостоятельно.proxy, конечно, роль промежуточного уровня Node гораздо больше, чем просто пересылка запросов через прокси. В конце статьи я также опишу изменения и возможности, которые средний уровень Node привносит в разработку интерфейса.Большая часть этой статьи объясняет, как использовать средний уровень Node для перенаправления запросов для обеспечения междоменного доступа к ресурсам. .

абстрактное понимание

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

конкретная операция

Само собой разумеется, что некоторое промежуточное программное обеспечение может использоваться для этой переадресации через прокси, но исследований пока нет, и я напишу статью после исследования. В нашей демонстрации на этот раз используется оригинальный API Node (http.get API используется для запросов на получение доступа к реальным адресам ресурсов) + экспресс-промежуточное ПО (для использования сервером), а асинхронные вызовы внешнего интерфейса также придерживаются аксиом из предыдущей статьи.

Предположим, наш внешний интерфейс обращается к адресу асинхронно следующим образом:

    this.axios.get('/api/index').then(res=>{...})

Экспресс-сервис можно записать так:

app.get('/api/index',(req,res)=>{
    //请求远程地址的API
    getHttp().then(data=>{
        console.log(data);
        res.send(data);
    }).catch(err=>{
        res.send(err);
    })
    //返回数据给前端
})

вgetHttp()упакованныйpromise,этоpromiseФункция заключается в пересылке запроса и обратном вызове функции разрешения с данными (запрошенными данными) после успеха. Затем, после успешного запроса, вthenДанные передаются во внешний интерфейс в первом параметре обратного вызова

const getHttp = ()=>{
    return new Promise((resolve,reject)=>{
        http.get('http://localhost:8080/New/Index', (res) => {
            const { statusCode } = res;
            const contentType = res.headers['content-type'];
          
            let error;
            if (statusCode !== 200) {
              error = new Error('请求失败\n' +
                                `状态码: ${statusCode}`);
            } 
            if (error) {
              console.error(error.message);
              // 消费响应数据来释放内存。
              res.resume();
              return;
            }
          
            res.setEncoding('utf8');
            let rawData = '';
            res.on('data', (chunk) => { rawData += chunk; });
            res.on('end', () => {
              try {
                const parsedData = JSON.parse(rawData);
                resolve(parsedData);
                console.log(parsedData);
              } catch (e) {
                console.error(e.message);
              }
            });
          }).on('error', (e) => {
            console.error(`出现错误: ${e.message}`);
          });
          
    })
}

Таким образом реализуется простая междоменная демо-инфраструктура.

Наконец, поговорим о влиянии уровня Node на внешний интерфейс.

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

  • Архитектура BFF (базовая часть для внешнего интерфейса) В архитектуре интерфейса RESTFul есть много внутренних интерфейсов, спецификации неоднородны, и большая часть данных, возвращаемых внутренним API, нуждается в повторной обработке. вторичная обработка данных может быть размещена в слое Node для обработки, а фронтенд сосредоточен на построении UI-логики, мы привыкли называть это BFF.
  • Одна из самых больших проблем с предварительным рендерингом и внешним рендерингом заключается в том, что загрузка первого белого экрана занимает много времени, что влияет на взаимодействие с пользователем. Суть этой проблемы заключается в производительности рендеринга JS на стороне клиента.При столкновении с обработкой JS с большим объемом вычислений это блокирует отрисовку пользовательского интерфейса и вызывает загрузку DOM без выполнения JS.Хорошее решение - предварительно оказывать. Предварительный рендеринг может выполнять рендеринг шаблона на уровне узла (эквивалентно рендерингу сервера на среднем уровне), что может эффективно решить проблему белого экрана. Тогда почему бы не использовать рендеринг на стороне сервера напрямую, потому что он учитывает удобство разделения клиентской и внутренней разработки.
  • Управляйте маршрутизацией и далее разделяйте пользовательский интерфейс и логику. Маршрутизация во внешнем рендеринге контролируется внешним интерфейсом. Введение уровня Node может передать управление маршрутизацией в Node, чтобы внешний интерфейс был больше сосредоточен на пользовательском интерфейсе. , а сложные вещи оставляются на Node, который эффективен и эффективен Разделение задач для улучшения ремонтопригодности.

Надеюсь, мое небольшое исследование может быть вам полезно, что также является первоначальным намерением, которым я делюсь. Спасибо за поддержку!

Категории