30 分でフロントエンドのコンテナ化を始めましょう

1 はじめに

フロントエンドコンテナ化は、フロントエンドアプリケーションをコンテナにパッケージ化して、さまざまな環境に迅速かつ効率的にデプロイして実行できるようにするテクノロジーです。

2.背景

フロントエンドとバックエンドを分離する傾向が具体化しています。フロントエンドエンジニアリングの複雑さは増大しています。新しいプロジェクトと古いプロジェクトのデプロイメントが依存する環境と Node.js のバージョンには違いが生じます。難読化されたスクリプトの構築運用環境の静的リソースファイルは、環境展開サービスに依存します。アクセス、フロントエンドエンジニアリングでは、「単一のアーティファクト」展開を形成できず、コンテナの出現により、展開プロセスが大幅に簡素化されました。

フロントエンドのコンテナ化により、フロントエンド環境変数の挿入と実行環境 (プロジェクトごとに異なるノード環境に依存しており、ノードのバージョンの互換性が大きな問題となる) を簡単に管理し、サーバーコストを節約し、より高速で便利なバージョンのロールバック、およびマルチアーキテクチャのデプロイメントを行うことができます。 . CI/CD 自動統合デプロイメント、DevOps など、そのメリットは想像以上です (ここで手動で笑います)。

この記事は、フロントエンドでのコンテナーテクノロジーの導入によってもたらされる変化を共有するために、Docker と組み合わせた React プロジェクトに基づいています。

3. github でのコンテナ化の適用

Github は、コンテナ化された ci/cd を行うために github-action を起動しました。github-action を使用して npm 自動パッケージ配信を行う例を以下に示します。

プロジェクトのルートディレクトリに新しい .github/workflows/ci.yml ファイルを作成します。
npm公式サイトにアクセスしてトークンを申請します（具体的な申請方法は自分で調べて解決してください）
このコードを ci.yml ファイルに貼り付けます。
コードを master ブランチにプッシュすると、デプロイメントに ci/cd が自動的に使用されます。

name: CI
on:
  push:
    branches:
      - master
jobs:
  build:
    # 指定操作系统
    runs-on: ubuntu-latest
    steps:
      # 将代码拉到虚拟机
      - name: Checkout repository
        uses: actions/checkout@v2
      # 指定node版本
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16.x'
          registry-url: 'https://registry.npmjs.org'
      # 依赖缓存策略
      - name: Cache
        id: cache-dependencies
        uses: actions/cache@v3
        with:
          path: |
            **/node_modules
          key: ${
    
    {runner.OS}}-${
    
    {hashFiles('**/pnpm-lock.yaml')}}
      - name: Install pnpm
        run: npm install -g [email protected]
      # 依赖下载
      - name: Installing Dependencies
        if: steps.cache-dependencies.outputs.cache-hit != 'true'
        run: pnpm install
      # 打包
      - name: Running Build
        run: pnpm run build
      # 测试
      - name: Running Test
        run: pnpm run test-unit
      # 发布
      - name: Running Publish
        run: npm publish
        env:
          # NPM_TOKEN is access token
         NODE_AUTH_TOKEN: ${
    
    { secrets.NPM_TOKEN }}

4. Docker に基づいてフロントエンドイメージを構築する

フロントエンドプロジェクト ci/cd を構築する方法を学ぶ前に、まずフロントエンドイメージを構築する方法を学びましょう。

4.1 ドッカーのインストール

ここをクリックするとdocker
のインストールに飛びますインストール完了後、以下のコマンドを実行して docker のバージョンを確認し、buildx のバージョンを持ってくるようにしてください。

docker -v
Docker version 24.0.2, build cb74dfc

4.2 Dockerfileの作成

ここでは、まずフロントエンドエンジニアリングの知識を広める必要があります。npm に基づくプロジェクトには package.json ファイルが必要であることは誰もが知っています。その後、npm run install を実行してパッケージをダウンロードし、npm run build を実行してパッケージ化します。パッケージ化されたファイルは使用できません。ノードサービスを起動して実行するため、ノードとnginxに基づいて最も基本的なイメージを作成します。例は次のとおりです。

次の内容を含む nginx.conf という名前の nginx 構成ファイルをプロジェクトのルートディレクトリに追加します。

worker_processes  1;
 
events {
    
      
    worker_connections  1024;  
} 
http {
    
      
    sendfile         on;  
    tcp_nodelay       on;  
    keepalive_timeout  30; 
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    server {
    
    
        listen 80;
        server_name localhost;
        root /usr/share/nginx/front/dist;
        autoindex on;   
        autoindex_exact_size off;   
        autoindex_localtime on;
        location / {
    
    
            try_files $uri $uri/ =404;
            index index.html index.htm;
            gzip_static on;
            expires max;
            add_header Cache-Control public;
            if ($request_filename ~* ^.*?\.(eot)|(ttf)|(woff)|(svg)|(otf)$) {
    
    
                add_header Access-Control-Allow-Origin *;
            }
        }
    }
}

次の内容を含む Dockerfile という名前の Docker 構成ファイルをプロジェクトのルートディレクトリに追加します。

FROM node:17-buster as builder

WORKDIR /src
COPY ./ /src

RUN npm install -g pnpm \
    && pnpm install \
    && pnpm build

FROM nginx:alpine-slim

RUN mkdir /usr/share/nginx/front \
    && mkdir /usr/share/nginx/front/dist \
    && rm -rf /etc/nginx/nginx.conf
 
COPY --from=builder /src/nginx.conf /etc/nginx/nginx.conf

COPY --from=builder /src/dist /usr/share/nginx/front/dist

EXPOSE 80

次に、docker build を使用してイメージをパッケージ化し (デスクトップツールがある場合は、パッケージ化が成功した後に docker デスクトップツールのイメージ列に表示されます)、docker run でイメージを実行します (デスクトップがある場合)ツールを使用すると、実行が成功した後に docker デスクトップツールのコンテナー列で確認できます)。 docker run が正常に実行された後、ブラウザを開いて http://localhost と入力して表示できます。

docker buildx build -t webapp-demo:v1 .

docker run -d -p 80:80 webapp-demo:v1

4.3 Dockerfile に基づいて pnpm キャッシュを行う方法

ここで一節を引用します:
マルチステージビルドを使用すると、ビルドされたイメージにはターゲットフォルダー dist のみが含まれますが、まだいくつかの問題があります。package.json ファイルが変更されると、RUN npm i && rm -rf ~/.npm レイヤーが再実行され、複数の変更が行われた後、多数の中間層イメージが生成されます。

この問題を解決するには、さらにデータボリュームに似た機能を想定し、イメージをビルドするときに、node_modules フォルダーをマウントします。ビルドが完了すると、node_modules フォルダーは自動的にアンインストールされます。実際のイメージには、node_modules は含まれません。フォルダーを使用すると、毎回依存関係を取得する時間が節約され、イメージ構築の効率が大幅に向上し、大量の中間イメージの生成も回避されます。

クラス代表はここで次のように要約しています。中間層イメージの可能性を最小限に抑え、Docker イメージのサイズとビルド時間を最小限に抑えることです。

私は npm パッケージ管理に pnpm を使用しているため、この最適化に関する公式の pnpm ドキュメントを次のように調べました。

FROM node:20-slim AS base

ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable

COPY . /app
WORKDIR /app

FROM base AS prod-deps
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --prod --frozen-lockfile

FROM base AS build
RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --frozen-lockfile
RUN pnpm run build

FROM base
COPY --from=prod-deps /app/node_modules /app/node_modules
COPY --from=build /app/dist /app/dist
EXPOSE 8000
CMD [ "pnpm", "start" ]

そこで、ひょうたんをコピーして運用環境の nginx 構成を使用するという精神で、同僚が書いた nginx パッケージングイメージを見つけました。また、docker build と docker run を実行して検証することもできます。変更したコードは次のとおりです。

FROM node:17-buster AS builder

ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable

WORKDIR /src
COPY ./ /src

RUN --mount=type=cache,target=/src/node_modules,id=myapp_pnpm_module,sharing=locked \
    --mount=type=cache,target=/pnpm/store,id=pnpm_cache \
        pnpm install

RUN --mount=type=cache,target=/src/node_modules,id=myapp_pnpm_module,sharing=locked \
        pnpm run build

FROM ghcr.io/zboyco/webrunner:0.0.7

COPY --from=builder /src/dist /app

4.4 buildx を使用してマルチアーキテクチャイメージを作成する方法

docker buildx ツールは、率直に言って、この機能を提供します。ホストが x86 64 アーキテクチャで、ARM64 アーキテクチャでイメージをビルドしたい場合は、このツールが必要です。クロスコンパイルに似た感じです。など: go build のクロスコンパイル、win10 での実行可能プログラムのコンパイル、特定の Linux プラットフォームで使用可能

Buildx は基本的に buildkit API を呼び出し、ビルドは buildkit 環境で実行されます。複数のアーキテクチャをサポートするかどうかは、ビルドキットの環境に依存します。ビルドキットが複数のアーキテクチャをサポートする必要がある場合は、ホストマシン上で実行する必要があります (もちろん、これは必須ではありません。ビルドの要件に従って制御されます)。 Docker デスクトップバージョンではこの設定を行う必要はありません):

docker run --privileged --rm tonistiigi/binfmt --install all

ここでは、複数のアーキテクチャをサポートするために上記の Dockerfile コードを変更します。プラットフォームは実験的なものであるため、最初に docker pull docker/dockerfile を実行してイメージをプルする必要があります。

# syntax = docker/dockerfile:experimental
# --platform, 会让 builder 只会有一份，且 arch 与宿主机一致
FROM --platform=${BUILDPLATFORM:-linux/amd64} node:17-buster AS builder

ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable

WORKDIR /src
COPY ./ /src

RUN --mount=type=cache,target=/src/node_modules,id=myapp_pnpm_module,sharing=locked \
    --mount=type=cache,target=/pnpm/store,id=pnpm_cache \
        pnpm install

RUN --mount=type=cache,target=/src/node_modules,id=myapp_pnpm_module,sharing=locked \
        pnpm run build

FROM ghcr.io/zboyco/webrunner:0.0.7

COPY --from=builder /src/dist /app

パッケージイメージコマンドを実行する前に、まずマシンのデフォルトのビルダーインスタンスを確認します。

docker buildx ls

NAME/NODE       DRIVER/ENDPOINT STATUS  BUILDKIT                              PLATFORMS
default         docker
  default       default         running v0.11.7-0.20230525183624-798ad6b0ce9f linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
desktop-linux * docker
  desktop-linux desktop-linux   running v0.11.7-0.20230525183624-798ad6b0ce9f linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6

buildx を使用して上記のスクリプトを実行してイメージをパッケージ化すると、次のエラーが報告されます。

docker buildx build --platform linux/arm,linux/arm64,linux/amd64 -t webapp-official-website:v1 .

ERROR: Multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")

Docker のデフォルトのビルダーインスタンスは同時に複数の --platform を指定することをサポートしていないため、最初に新しいビルダーインスタンスを作成する必要があります。同時に、中国ではイメージのプルが遅いため、イメージアクセラレーションアドレスが設定された dockerpracticesig/buildkit:master イメージを使用して、公式イメージを置き換えることができます。

プライベートイメージアクセラレータをお持ちの場合は、https://github.com/docker-practice/buildx に基づいて独自のビルドキットイメージを構築して使用できます。

# 适用于国内环境
$ docker buildx create --use --name=mybuilder-cn --driver docker-container --driver-opt image=dockerpracticesig/buildkit:master

# 适用于腾讯云环境(腾讯云主机、coding.net 持续集成)
$ docker buildx create --use --name=mybuilder-cn --driver docker-container --driver-opt image=dockerpracticesig/buildkit:master-tencent

# $ docker buildx create --name mybuilder --driver docker-container

$ docker buildx use mybuilder

国内環境に適したコマンドを選択してソリューションを作成すると、mybuilder-cn という名前のインスタンスがさらに増えていることがわかります。

docker buildx create --use --name=mybuilder-cn --driver docker-container --driver-opt image=dockerpracticesig/buildkit:master

docker buildx ls
NAME/NODE       DRIVER/ENDPOINT  STATUS   BUILDKIT                              PLATFORMS
mybuilder-cn *  docker-container
  mybuilder-cn0 desktop-linux    inactive
default         docker
  default       default          running  v0.11.7-0.20230525183624-798ad6b0ce9f linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
desktop-linux   docker
  desktop-linux desktop-linux    running  v0.11.7-0.20230525183624-798ad6b0ce9f linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6

$ docker buildx build --platform linux/arm,linux/arm64,linux/amd64 -t myusername/hello . --push

# 查看镜像信息
$ docker buildx imagetools inspect myusername/hello

さまざまなアーキテクチャでイメージを実行して、アーキテクチャに関する情報を取得します。

$ docker run -it --rm myusername/hello

5. フロントエンド環境変数挿入にコンテナ化を使用する方法

フロントエンドには多くの環境変数は必要ありませんが、基本的な API の BaseURL、appName、env は必要です。
マイクロフロントエンドシナリオの場合、他の Web サイトの必要な URL は環境変数であり、その数は非常に多くなります。
私がこの業界に入りたての頃は、テスト環境はフロントエンドで区別し、オンライン環境はドメイン名で直接判断し、例えば inlcudes(url, “.com”)? で isProd を取得していたのをなんとなく覚えています。プロジェクト内で構成されているさまざまな環境の変数を取得しますが、これは非常に低いと思われます
vueやreactなどのフレームワークは後から出てきましたが、npm run dev時に–prodを指定し、プロセスを通じてisProdを取得することで対応する設定を取得することができます。
コンテナ化を通じて環境変数を直接注入し、nginx を使用してコンテナ内の環境変数をフロントエンドプロジェクト HTML のメタタグコンテンツに注入し、メタタグから変数を取得できるようになりました。
モノリポジトリプロジェクトの場合、npm がビルドを実行するときに、Dockerfile はコンテナ内の環境変数を使用して、パッケージ化するプロジェクトを取得する必要もあります。
テスト環境は ts ファイルを通じて環境変数を構成し、プロジェクトの開始時にこれらの環境変数情報を組み合わせて構成のデフォルト.yml を生成します。ci/cd の場合、k8s はデフォルト.yml で構成された環境変数をコンテナに自動的に書き込みます。
オンライン環境は、環境変数を設定するための UI ページを直接提供し、API を呼び出します。バックエンド API は、k8s を通じて変数をコンテナーに書き込みます。
k8s を通じて設定された環境変数を読み取り、それらをコンテナーに書き込み、次回分解をリッスンする方法

以下は、運用シナリオの Dockerfile サンプルコードです (会社はおそらく私を殺さないでしょう!) ここでは、k8s が環境変数をコンテナに挿入する方法を省略し、コンテナから環境変数を読み取る方法のみを考慮します (環境が変数はコンテナに挿入されています))

FROM --platform=${BUILDPLATFORM} hub-dev.rockontrol.com/rk-infrav2/docker.io/library/node:17-bullseye as builder

WORKDIR /src
COPY ./ ./

ARG APP
ARG ENV

ARG PROJECT_GROUP
ARG PROJECT_NAME
ARG PROJECT_VERSION

ARG YARN_NPM_REGISTRY_SERVER

RUN npm install -g --registry=${YARN_NPM_REGISTRY_SERVER} pnpm
RUN pnpm --registry=${YARN_NPM_REGISTRY_SERVER} install


RUN PROJECT_GROUP=${PROJECT_GROUP} PROJECT_VERSION=${PROJECT_VERSION} \
    npx devkit build --prod ${APP} ${ENV}

FROM hub-dev.rockontrol.com/rk-infrav2/ghcr.io/zboyco/webrunner:0.0.7

ARG PROJECT_NAME
COPY --from=builder /src/public/${PROJECT_NAME} /app

以下は、nginx が環境変数を結合し、nginx 設定を使用して HTML の mate タグに書き込む方法を示すコードです。

#!/bin/sh

# This script is used to start the application

# 初始化一个字符串，用于存储拼接后的值
app_config="${APP_CONFIG}"
ext_config=""

# 遍历所有环境变量
for var in $(env | cut -d= -f1); do
    # 检查变量是否以 "APP_CONFIG__" 开头
    if [ "$(echo "$var" | grep '^APP_CONFIG__')" ]; then
        # 去除变量名前缀 "APP_CONFIG__"
        trimmed_var=$(echo "$var" | sed 's/^APP_CONFIG__//')
        # 使用 eval 来获取变量值并拼接到字符串中
        value=$(eval echo "\$$var")
        app_config="${app_config},${trimmed_var}=${value}"
    fi
done

# 去掉起始的逗号
export app_config=$(echo "$app_config" | sed 's/^,//')

# 解析app_config变量
# 以,分割 app_config
IFS=","
set -- $app_config
# 遍历数组
for config in "$@"; do
    # 以等号分剥数组
    IFS="="
    set -- $config
    # 将单个环境变量单独注入
    ext_config="${ext_config}        sub_filter '__$1__' '$2';\n"
    echo "$1: $2"
done

# Install envsubst
echo "Installing envsubst"
# 将扩展变量替换到 conf.template 中
sed "s@__EXTENT_CONFIG__@${ext_config}@g" /etc/nginx/conf.d/conf-base.template > /etc/nginx/conf.d/conf.template 

envsubst '${PROJECT_VERSION} ${ENV} ${app_config}' < /etc/nginx/conf.d/conf.template > /etc/nginx/conf.d/default.conf

# Start nginx
echo "Starting nginx"
nginx -g 'daemon off;'

nginx 設定コードでは、mate タグのプレースホルダーが実際の環境変数に置き換えられます。コード内の sub_filter を参照してください。

server {
    
    
    listen 80;
    listen  [::]:80;
    server_name  localhost;
    root /app;

    #开启gzip
    gzip on;  
    #低于1kb的资源不压缩 
    gzip_min_length 1k;
    #压缩级别1-9，越大压缩率越高，同时消耗cpu资源也越多，建议设置在5左右。 
    gzip_comp_level 6; 
    #需要压缩哪些响应类型的资源，多个空格隔开。不建议压缩图片.
    gzip_types text/plain application/javascript application/x-javascript text/javascript text/xml text/css;

    location ~ ^/(static|__built__)/ {
    
    
        root /app;
        expires max;
        proxy_cache static_memory_cache;  # 使用内存缓存
        proxy_cache_valid 200 1d;
        proxy_cache_lock on;
    }

    location / {
    
    
        expires -1;
        try_files $uri /index.html;

        add_header X-Frame-Options sameorigin;
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1;mode=block" always;

        sub_filter '__PROJECT_VERSION__' '$PROJECT_VERSION';
        sub_filter '__ENV__' '$ENV';
        sub_filter '__APP_CONFIG__' '$app_config';

        # 需要将以下字符串替换为注入的扩展环境变量
__EXTENT_CONFIG__

        sub_filter_once on;
    }
}

以下は、フロントエンドが HTML メタタグから環境変数を読み取る方法に関するセクションです。

import appConfig from "../../config";

interface IConfig {
    
    
  appName: string;
  baseURL: string;
  version?: string;
  env?: string;
}

export function getConfig(): IConfig {
    
    
  const defaultAppConfig = {
    
    
    appName: "",
    version: "",
    env: "",
    baseURL: "",
  };
  console.log("metaEnv", import.meta.env);

  if (import.meta.env.DEV) {
    
    
    return appConfig;
  } else {
    
    
    const appConfigStr = getMeta("app_config");

    if (!appConfigStr) return defaultAppConfig;

    return parseEnvVar(appConfigStr);
  }
}

function getMeta(metaName: string) {
    
    
  const metas = document.getElementsByTagName("meta");

  for (let i = 0; i < metas.length; i++) {
    
    
    if (metas[i].getAttribute("name") === metaName) {
    
    
      return metas[i].getAttribute("content");
    }
  }

  return "";
}

function parseEnvVar(envVarURL: string) {
    
    
  const arrs = envVarURL.split(",");

  return arrs.reduce((pre, item) => {
    
    
    const keyValues = item.split("=");

    return {
    
    
      ...pre,
      [keyValues[0]]: keyValues[1],
    };
  }, {
    
    } as IConfig);
}

const BASE_URL = getConfig().baseURL;

const instance = axios.create({
    
    
  baseURL: BASE_URL,
  headers: {
    
    
    "Content-Type": "application/json",
  },
  timeout: 60000, // 超时时间60秒
});

ようやく Dockerfile が投稿されたので、実際のシナリオで ci ファイルのソースコードを投稿してみましょう。！！

stages:
  - ship
  - deploy

ship:
  stage: ship
  image: hub-dev.rockontrol.com/rk-infrav2/gitlab-runner-buildx:0.0.0-b0450fe
  # variables:
  #   MULTI_ARCH_BUILDER: 1
  before_script:
    - echo "${DOCKER_PASSWORD}" | docker login "${DOCKER_REGISTRY}" -u="${DOCKER_USERNAME}" --password-stdin
    - BUILDKIT_NAME=node-buildkit hx buildx ci-setup
  script:
    - export PLATFORM=linux/amd64,linux/arm64
    - |
      if [[ -f ./.platform ]]; then
        source ./.platform
      else
        echo "WARNING, there is no .platform in project, USE default PLATFORM=${PLATFORM} "
      fi
    - hx buildx --with-builder --push --platform=${PLATFORM}
  tags:
    - webapp

deploy:
  stage: deploy
  script:
    - hx config
    - hx deploy
  dependencies:
    - ship
  tags:
    - webapp

6.フロントエンドアプリケーションのKubernetesデプロイメント

Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化できるオープンソースのコンテナオーケストレーションプラットフォームです。フロントエンドアプリケーションを Kubernetes クラスターにデプロイする手順は次のとおりです。

6.1 デプロイメントの作成

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend-app
  template:
    metadata:
      labels:
        app: frontend-app
    spec:
      containers:
        - name: frontend-app
          image: my-frontend-app:latest
          ports:
            - containerPort: 3000

6.2 サービスの作成

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: LoadBalancer

6.3 Kubernetes クラスターへのデプロイ

kubectl コマンドを使用して、アプリケーションを Kubernetes クラスターにデプロイします。

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

これで、フロントエンドアプリケーションが Kubernetes クラスター内で実行され、LoadBalancer タイプのサービスを介して外部からアクセスできるようになりました。

7. フロントエンド React プロジェクトのアーキテクチャについて

7.1 コア技術

パッケージ化とコンパイル
パッケージ管理 - pnpm
プログラミング言語 - typescript
フロントエンドフレームワーク -反応
ルーティング-反応ルーター
UI コンポーネントライブラリ - antd
cssinjs (パフォーマンスのオーバーヘッドを考慮せず) -感情
グローバルデータ共有 - zustand
APIを自動生成する - openapi
ネットワークリクエスト - axios
データリクエストツール -反応クエリ
一般的なフック (オプション) - ahooks
エラー境界 -反応エラー境界
フロントエンドログ (まだ統合されていません) - Sentry-JavaScript
ハック -バベル
コードインスペクション - eslint
ts コード検査プラグイン-typescript-eslint
コードの美化 -より美しく
gitフック -ハスキー
コミットのフォーマット - commitlint

7.2 openapiに基づくAPIリクエスト関数の自動取得

// src/core/openapi/index.ts

// 示例代码
generateService({
    
    
  // openapi地址
  schemaPath: `${
     
     appConfig.baseURL}/${
     
     urlPath}`,
  // 文件生成目录
  serversPath: "./src",
  // 自定义网络请求函数路径
  requestImportStatement: `/// <reference types="./typings.d.ts" />\nimport request from "@request"`,
  // 代码组织命名空间, 例如：Api
  namespace: "Api",
});

7.3 呼び出しインターフェイス (react-query)、自動読み込みとインターフェイスリクエストのリンクをサポート

// HelloGet是一个基于axios的promise请求
export async function HelloGet(
  // 叠加生成的Param类型 (非body参数swagger默认没有生成对象)
  params: Api.HelloGetParams,
  options?: {
    
     [key: string]: any },
) {
    
    
  return request<Api.HelloResp>('/gin-demo-server/api/v1/hello', {
    
    
    method: 'GET',
    params: {
    
    
      ...params,
    },
    ...(options || {
    
    }),
  });
}

// 自动调用接口获取数据
const {
    
     data, isLoading } = useQuery({
    
    
  queryKey: ["hello", name],
  queryFn: () => {
    
    
    return HelloGet({
    
     name: name });
  },
});

export async function HelloPost(body: Api.HelloPostParam, options?: {
    
     [key: string]: any }) {
    
    
  return request<Api.HelloResp>('/gin-demo-server/api/v1/hello', {
    
    
    method: 'POST',
    headers: {
    
    
      'Content-Type': 'application/json',
    },
    data: body,
    ...(options || {
    
    }),
  });
}

// 提交编辑数据
const {
    
     mutate, isLoading } = useMutation({
    
    
  mutationFn: HelloPost,
  onSuccess(data) {
    
    
    setName(data?.data || "");
  },
  onError() {
    
    
    // 清除queryKey为hello的接口数据缓存，自动重新获取接口数据
    queryClient.invalidateQueries({
    
     queryKey: ['hello'] });
  }
})

mutate({
    
     name: "lisi" });

8.フロントエンド React コード CLI

9. 結論

フロントエンド npm フィールドに gitlab-action の基本構成を導入しました。
フロントエンド Dockerfile ファイルの作成、Docker での pnpm の最適化計画、および buildx を使用してフロントエンドマルチアーキテクチャイメージを生成する方法を紹介します。
運用シナリオでのフロントエンド環境変数の使用を導入します。
フロントエンド React プロジェクトの技術アーキテクチャ計画の紹介