@modern-js/main-doc 0.0.0-nightly-20240909025816 → 0.0.0-nightly-20240910170704

package/docs/zh/guides/advanced-features/bff/sdk.mdx

@@ -1,16 +1,12 @@
----
-sidebar_position: 4
-title: 自定义请求 SDK
----
-# 自定义请求 SDK
+# 扩展一体化调用 SDK
 
-Modern.js 的 BFF 在 CSR 和 SSR 是同构的。在浏览器端依赖了[Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch)，在服务端依赖了 [node-fetch](https://www.npmjs.com/package/node-fetch)。但在很多业务场景下我们需要对请求或响应做一些额外的处理，例如：
+BFF 函数的一体化调用在 CSR 和 SSR 是同构的。Modern.js 封装的请求 SDK，在浏览器端依赖了 [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch)，在服务端依赖了 [node-fetch](https://www.npmjs.com/package/node-fetch)。但在实际业务场景下，有时需要对请求或响应做一些额外的处理，例如：
 
 - 在请求头中写入鉴权信息
 - 对响应的数据或错误进行统一的处理
 - 特定平台无法使用浏览器的原生 fetch 函数，需要使用其他方式发送请求
 
-针对上述的场景，Modern.js 提供了 `configure` 函数，自定义能力从低到高，可以用它配置 ssr 透传请求头，拦截器，请求 SDK。
+针对上述的场景，Modern.js 提供了 `configure` 函数，开放了一系列扩展能力，可以用它配置 ssr 透传请求头，添加拦截器，自定义请求 SDK。
 
 :::caution 注意
 `configure` 函数的调用需要在所有 BFF 请求发送前调用，以确保覆盖默认的请求配置。
@@ -18,42 +14,42 @@ Modern.js 的 BFF 在 CSR 和 SSR 是同构的。在浏览器端依赖了[Fetch
 :::
 
 
-```ts title="App.tsx"
+```tsx title="routes/page.tsx"
 import { configure } from '@modern-js/runtime/bff';
 
-configure({
-  request: customRequest
+configure({ 
+  // ... 
 })
+
+const Index = () => <div>Hello world</div>
+export default Index;
 ```
 
-## 配置 ssr 透传请求头
+## 配置 SSR 透传请求头
 
-在同时使用 Modernjs SSR 和 BFF 的场景下，常常需要将 SSR 页面请求上的一些请求头信息，透传给 BFF 服务。
+在同时使用 Modern.js SSR 和 BFF 的场景下，常常需要将 SSR 页面请求上的一些请求头信息，透传给 BFF 服务。
 
 例如项目有页面地址是 `https://website.com`，该页面是 SSR 的，在组件中会调用 API 接口 `https://website.com/api/info`，该接口需要用户的 cookie 信息做鉴权。页面在请求该 API 接口时，需要将 SSR 页面请求的 `cookie` 传给 BFF。
 
 目前以下请求头在 Modernjs 中是自动透传的：
 
-- cookie
-- x-tt-logid
-- user-agent
-- x-tt-stress
-
-可以通过 `configure` 配置请求头。例如以下例子，Modern.js 会自动将 SSR 页面请求的 cookie 信息透传给 BFF 服务：
+```ts
+['cookie', 'user-agent', 'x-tt-logid', 'x-tt-stress']
+```
 
-```tsx title="App.tsx"
-import { configure } from '@modern-js/runtime/bff';
+可以通过 `configure` 配置请求头。例如以下例子，Modern.js 会自动将 SSR 页面请求的 `x-uid` 信息透传给 BFF 服务：
 
+```tsx
 configure({
   allowedHeaders: ['x-uid']
 })
 ```
 
-## 配置拦截器
+## 添加拦截器
 
-在有些业务场景下需要对请求和响应进行一些统一的处理，这种场景下可以配置拦截器满足需求：
+在有些业务场景下需要对请求和响应进行统一的处理，这种场景下可以通过**配置拦截器**满足需求：
 
-```tsx title="App.tsx"
+```tsx
 configure({
   // 这里的 request 是一体化默认的请求工具，interceptor 函数需返回一个新的 request。
   // 新 request 的出参必须是 parse body 之后的结果
@@ -66,16 +62,11 @@ configure({
 });
 ```
 
-## 配置自定义请求 SDK
-
-如果仅仅通过配置拦截器无法满足需求，需要对请求的 SDK 做进一步的自定义，可以通过 `configure` 函数配置自定义请求 SDK：
-
-:::caution 注意
-在 SSR 和一体化调用的场景下，在 SSR 向 BFF 服务发送请求时，Modern.js 会通过**服务发现**找到 BFF 服务内网 IP，并通过 IP 发送请求，以提高性能。如果使用自定义请求 SDK 会**失去这种优化**。
+## 自定义请求 SDK
 
-:::
+如果仅仅通过配置拦截器无法满足需求，希望自定义请求函数，也可以通过 `configure` 进行配置：
 
-```tsx title="App.tsx"
+```tsx
 import nodeFetch from 'node-fetch';
 
 const customFetch = (input: RequestInfo | URL, init: RequestInit) => {
@@ -92,13 +83,13 @@ configure({
 });
 ```
 
-配置自定义请求 SDK 有以下约定：
+配置自定义请求函数有以下约定：
 
-- 通过 `configure` 函数可以配置一个 `request` 函数，这个函数的入参与浏览器中的 Fetch 或 node-fetch 对齐，所有的一体化 BFF 函数会通过该函数发送请求。
-- `request` 函数出参必须是接口实际返回的数据，不能是 Promise，否则会导致一体化 BFF 函数无法正常返回数据。
-- 如果是 SSR 项目，`request` 必须要同时支持浏览器端和服务器端发送请求。
+- 函数的入参与浏览器中的 Fetch 或 node-fetch 对齐，所有 BFF 函数的一体化调用会通过该函数发送请求。
+- 函数出参必须是接口实际返回的数据，不能是 Promise，否则会导致 BFF 函数无法正常返回数据。
+- 如果是 SSR 项目，函数必须要同时支持浏览器端和服务器端发送请求。
 
-使用 axios 定制自定义请求 SDK 的示例：
+下面是使用 axios 定制自定义请求函数的示例：
 
 ```tsx title="App.tsx"
 import { configure } from '@modern-js/runtime/bff';

package/docs/zh/guides/advanced-features/build-performance.mdx

@@ -9,7 +9,7 @@ Modern.js 默认对构建性能进行了充分优化，但是随着业务场景
 本文档提供了一些可选的提速策略，**开发者可以根据实际场景选取其中的部分策略**，从而进一步提升构建速度。
 
 :::tip 📢 注意
-在[优化产物体积](/guides/advanced-features/optimize-bundle.html)一文中介绍的策略也可以用于提升构建性能，这里不再重复介绍。
+在[优化产物体积](/guides/advanced-features/page-performance/optimize-bundle)一文中介绍的策略也可以用于提升构建性能，这里不再重复介绍。
 :::
 
 ## 通用优化策略
@@ -118,7 +118,7 @@ export default {
 
 ### 调整 Browserslist 范围
 
-这项优化的原理与[「提升 Browserslist 范围」](/guides/advanced-features/optimize-bundle.html#adjust-browserslist)类似，区别在于，我们可以为开发环境和生产环境设置不同的 browserslist，从而减少开发环境下的编译开销。
+这项优化的原理与[「提升 Browserslist 范围」](/guides/advanced-features/page-performance/optimize-bundle#adjust-browserslist)类似，区别在于，我们可以为开发环境和生产环境设置不同的 browserslist，从而减少开发环境下的编译开销。
 
 比如，你可以在 `package.json` 中添加以下配置，表示在开发环境下只兼容最新的浏览器，在生产环境下兼容实际需要的浏览器：
 

package/docs/zh/guides/advanced-features/page-performance/_meta.json

@@ -0,0 +1 @@
+["code-split", "inline-assets", "optimize-bundle"]

package/docs/zh/guides/advanced-features/rsbuild-plugin.mdx

@@ -19,7 +19,7 @@ Rsbuild 是 Modern.js 底层的构建工具，可通过添加 Rsbuild 插件修
 :::tip
 Modern.js 从 `MAJOR_VERSION.46.0` 起开始将底层的构建工具升级为 [Rsbuild](https://rsbuild.dev/)。
 
-如果你当前版本低于 MAJOR_VERSION.46.0, 可通过执行 `npx modern upgrade` 进行升级。
+如果你当前版本低于 MAJOR_VERSION.46.0，可通过执行 `npx modern upgrade` 进行升级。
 :::
 
 ## 官方插件

package/docs/zh/guides/advanced-features/rspack-start.mdx

@@ -39,7 +39,7 @@ export default defineConfig({
 ```
 
 :::tip
-如果你当前版本低于 MAJOR_VERSION.59.0, 可通过执行 `npx modern upgrade` 进行升级。
+如果你当前版本低于 MAJOR_VERSION.59.0，可通过执行 `npx modern upgrade` 进行升级。
 :::
 
 import RspackPrecautions from '@modern-js/builder-doc/docs/zh/shared/rspackPrecautions.md';
@@ -104,7 +104,7 @@ export default defineConfig<'rspack'>({
 
 ![rspack_version_log](https://lf3-static.bytednsdoc.com/obj/eden-cn/6221eh7uhbfvhn/modern/20240110-155444.png)
 
-#### 修改内置 Rspack 版本
+### 修改内置 Rspack 版本
 
 可以使用 pnpm / yarn / npm 等包管理工具自带的依赖升级功能来将 Rspack 强制升级到指定版本。
 

package/docs/zh/guides/basic-features/alias.mdx

@@ -15,9 +15,7 @@ sidebar_position: 4
 
 ## 通过 `tsconfig.json` 的 `paths` 配置
 
-你可以通过 `tsconfig.json` 中的 `paths` 来配置别名，这是我们在 TypeScript 项目中推荐使用的方式，因为它可以解决路径别名的 TS 类型问题。
-
-比如：
+你可以通过 `tsconfig.json` 中的 `paths` 来配置别名，这是我们在 TypeScript 项目中推荐使用的方式，因为它可以解决路径别名的 TS 类型问题。比如：
 
 ```json title="tsconfig.json"
 {
@@ -29,7 +27,7 @@ sidebar_position: 4
 }
 ```
 
-以上配置完成后，如果你在代码中引用 `@common/Foo.tsx`, 则会映射到 `<project>/src/common/Foo.tsx` 路径上。
+以上配置完成后，如果你在代码中引用 `@common/Foo.tsx`，则会映射到 `<project>/src/common/Foo.tsx` 路径上。
 
 :::tip
 你可以阅读 [TypeScript - paths](https://www.typescriptlang.org/tsconfig#paths) 文档来了解更多用法。
@@ -47,9 +45,7 @@ Modern.js 提供了 [source.alias](/configure/app/source/alias) 配置项，对
 
 ### 对象用法
 
-你可以通过对象的方式来配置 `source.alias`，其中的相对路径会被自动补全为绝对路径。
-
-比如：
+你可以通过对象的方式来配置 `source.alias`，其中的相对路径会被自动补全为绝对路径。比如：
 
 ```js
 export default {
@@ -61,13 +57,11 @@ export default {
 };
 ```
 
-以上配置完成后，如果你在代码中引用 `@common/Foo.tsx`, 则会映射到 `<project>/src/common/Foo.tsx` 路径上。
+以上配置完成后，如果你在代码中引用 `@common/Foo.tsx`，则会映射到 `<project>/src/common/Foo.tsx` 路径上。
 
 ### 函数用法
 
-你也可以将 `source.alias` 配置为一个函数，拿到内置的 `alias` 对象，对其进行修改。
-
-比如：
+你也可以将 `source.alias` 配置为一个函数，拿到内置的 `alias` 对象，对其进行修改。比如：
 
 ```js
 export default {

package/docs/zh/guides/basic-features/env-vars.mdx

@@ -61,7 +61,7 @@ function App() {
 }
 ```
 
-这种方式可以针对不同客户端提供不同的产物，保证代码体积最小化；也便于处理不同环境下代码中的一些副作用。
+这种方式可以针对不同客户端提供不同的产物，保证代码体积最小化，也便于处理不同环境下代码中的一些副作用。
 
 :::note 死代码移除
 在生产环境，Terser 和 SWC 等代码压缩工具会分析代码，并将 dead code 移除，从而减少产物体积，这个过程被称为死代码移除（DCE）。

package/docs/zh/guides/basic-features/static-assets.mdx

@@ -72,7 +72,7 @@ console.log(largeImage); // "/static/largeImage.6c12aba3.png"
 console.log(smallImage); // "data:image/png;base64,iVBORw0KGgo..."
 ```
 
-关于资源内联的更详细介绍，请参考 [静态资源内联](/guides/advanced-features/inline-assets) 章节。
+关于资源内联的更详细介绍，请参考 [静态资源内联](/guides/advanced-features/page-performance/inline-assets) 章节。
 
 ## 构建产物
 

package/i18n.json

@@ -71,6 +71,10 @@
     "zh": "使用 BFF",
     "en": "Using BFF"
   },
+  "page-performance": {
+    "zh": "优化页面性能",
+    "en": "Optimize Page Performance"
+  },
   "micro-frontend": {
     "zh": "微前端",
     "en": "Micro Frontend"

package/package.json

@@ -15,17 +15,17 @@
     "modern",
     "modern.js"
   ],
-  "version": "0.0.0-nightly-20240909025816",
+  "version": "0.0.0-nightly-20240910170704",
   "publishConfig": {
     "registry": "https://registry.npmjs.org/",
     "access": "public",
     "provenance": true
   },
   "dependencies": {
-    "@modern-js/sandpack-react": "0.0.0-nightly-20240909025816"
+    "@modern-js/sandpack-react": "0.0.0-nightly-20240910170704"
   },
   "peerDependencies": {
-    "@modern-js/builder-doc": "0.0.0-nightly-20240909025816"
+    "@modern-js/builder-doc": "0.0.0-nightly-20240910170704"
   },
   "devDependencies": {
     "@rspress/shared": "1.28.2",
@@ -39,7 +39,7 @@
     "rspress": "1.28.2",
     "ts-node": "^10.9.1",
     "typescript": "^5",
-    "@modern-js/builder-doc": "0.0.0-nightly-20240909025816"
+    "@modern-js/builder-doc": "0.0.0-nightly-20240910170704"
   },
   "scripts": {
     "dev": "rspress dev",

package/rspress.config.ts

@@ -134,12 +134,10 @@ export default defineConfig({
   ],
   builderConfig: {
     output: {
-      disableTsChecker: true,
-      svgDefaultExport: 'component',
       dataUriLimit: 0,
     },
     dev: {
-      startUrl: false,
+      lazyCompilation: true,
     },
     source: {
       alias: {

package/docs/en/apis/app/hooks/api/api.mdx

@@ -1,80 +0,0 @@
----
-title: '**/*.[tj]s'
-sidebar_position: 1
----
-# **/*.[tj]s
-
-Files that declare API routes in the [BFF Function Mode](/guides/advanced-features/bff/type.html#function-mode). Except for some [convention files](/apis/app/hooks/api/api#allow-list), files in the `api` directory will be registered as the routes.
-
-:::info
-Using the `api` directory requires enabling the BFF feature, and you need to run the `new` command in the project to enable the "BFF" feature.
-
-This file supports using the `js` or `ts` language, but you must use `esm` syntax to export functions.
-
-:::
-
-## Routing File Convention
-
-### Default Routing
-
-The routing system will map files named `index` to the previous directory.
-
-- `api/index.ts` -> `$BASENAME/`
-- `api/user/index.ts` -> `$BASENAME/user`
-
-### Nested Routing
-
-The routing system also supports parsing nested files. If you create a nested folder structure, the files will still automatically resolve routes in the same way.
-
-- `api/hello.ts` -> `$BASENAME/hello`
-- `api/user/list.ts` -> `$BASENAME/user/list`
-
-### Dynamic Routing
-
-The routing system supports generating dynamic routes through file directories named with `[]`.
-
-- `api/user/[username]/info.ts` -> `$BASENAME/user/:username/info`
-- `api/user/[username]/delete.ts` -> `$BASENAME/user/:username/delete`
-- `api/article/[id]/info.ts` -> `$BASENAME/article/:id/info`
-
-The `$BASENAME` can be configured in `modern.config.js`, and the default value is `/api`.
-
-### Allow List
-
-By default, all files in the `api` directory will be parsed as BFF function files, but we also set a white list for these files that are not parsed:
-
-- Files whose names start with `_`. For example: `_utils.ts`.
-- All files in folders whose names start with `_`. For example: `_utils/index.ts`, `_utils/cp.ts`.
-- Test files. For example: `foo.test.ts`.
-- TypeScript type files. For example: `hello.d.ts`.
-- Files under `node_modules`.
-
-## Function Definition
-
-In addition to the routing rules above, there are also conventions for function definitions and exports in the code.
-
-Functions are exported by name, and the name of the exported function is the HTTP method accepted by the corresponding interface, that is:
-
-```ts
-export const get = async () => {
-  return {
-    name: 'Modern.js',
-    desc: 'Modern web Solutions',
-  };
-};
-```
-
-By exporting functions in this way, you will get a `GET` interface.
-
-The application project supports 9 Method definitions, namely: `GET`, `POST`, `PUT`, `DELETE`, `CONNECT`, `TRACE`, `PATCH`, `OPTION`, `HEAD`, that is, these Methods can be used as the names of the exported functions.
-
-The name is case-insensitive, that is, if it is `GET`, it can be written as `get`, `Get`, `GEt`, `GET`, all of which can be accurately recognized. The default export, that is, `export default xxx`, will be mapped to `Get`.
-
-Because `delete` is a keyword in JavaScript, you can use `del` or `DELETE` instead.
-
-Multiple functions with different Methods can be defined in one file, but if multiple functions with the same Method are defined, only the first one will take effect.
-
-:::info
-It should be noted that the defined functions should all be asynchronous, which is related to the type when calling the function.
-
-:::

package/docs/en/apis/app/hooks/api/app.mdx

@@ -1,12 +0,0 @@
----
-title: _app.[tj]s
-sidebar_position: 2
----
-# _app.[tj]s
-
-In the [BFF Function Mode](/guides/advanced-features/bff/type.html#function-mode), this file can add pre-middleware for BFF functions.
-
-:::note
-For specific examples, please refer to [hook](/apis/app/runtime/bff/hook).
-
-:::

package/docs/en/guides/advanced-features/bff/type.mdx

@@ -1,46 +0,0 @@
----
-sidebar_position: 2
-title: BFF Type
----
-# BFF Type
-
-Runtime framework support is also an important part of **BFF**. Modern.js supports extending BFF's runtime framework through plugins, and provides a series of built-in plugins, developers can directly use the conventions and ecology of the framework.
-
-The plugin is compatible with most of the specifications of these frameworks, and each framework needs to provide two types of ways to extend the writing of BFF functions, namely **Function Mode** and **Framework Mode**.
-
-:::note
-Whether the current `api/` directory structure is written as a framework is determined by the corresponding plugin, Modern.js don't care.
-
-:::
-
-## Function Mode
-
-When the plugin considers that it is currently written as a function, it must support writing middleware in the `api/_ app.ts` to extend the BFF function.
-
-Modern.js collects the middleware in the `api/_app.ts` and passes it to the plugin, which injects the middleware into the runtime, for example:
-
-```ts
-import { hook } from '@modern-js/runtime/server';
-
-export default hook(({ addMiddleware }) => {
-  addMiddleware(myMiddleware);
-});
-```
-
-:::note
-The writing of middleware for different plugins is not the same, see [Runtime Framework](/guides/advanced-features/bff/frameworks) for details.
-
-:::
-
-## Framework Mode
-
-Framework writing is a way of using frame structure to extend BFF functions. Compared with function writing, although frame writing can use more frame structure and make the entire BFF Server clearer in complex scenarios, it is also more complex and requires more attention to the content at the framework level.
-
-In the framework writing method, all BFF functions need to be written in the `api/lambda/` directory, and the hook file `_app.[tj]s` cannot be used.
-
-In most cases, the function writing method can cover the customization requirements of most BFF functions. Only when your project server level logic is more complex, the code needs to be layered, or you need to use more elements of the framework, you need to use the framework writing method.
-
-:::note
-The directory structure of different plugin frameworks is not the same, see [Runtime Frameworks](/guides/advanced-features/bff/frameworks) for details.
-
-:::

package/docs/zh/apis/app/hooks/api/api.mdx

@@ -1,81 +0,0 @@
----
-title: '**/*.[tj]s'
-sidebar_position: 1
----
-
-# **/*.[tj]s
-
-在 [BFF 函数写法](/guides/advanced-features/bff/type.html#函数写法)下，声明 API 路由的文件。除了[某些约定文件](/apis/app/hooks/api/api#白名单)外，`api` 目录下的文件会被注册为接口的路由。
-
-:::info
-使用 `api` 目录需要开启 BFF 功能，需要在项目下执行 new 命令启用「BFF」功能。
-
-该文件支持使用 `js` 或 `ts` 语言，但必须使用 `esm` 语法导出函数。
-
-:::
-
-## 该文件约定路由如下：
-
-### 默认路由
-
-路由系统会将以 `index` 命名的文件会被映射到上一层目录。
-
-- `api/index.ts` -> `$BASENAME/`
-- `api/user/index.ts` -> `$BASENAME/user`
-
-### 嵌套路由
-
-路由系统也支持解析嵌套的文件，如果创建嵌套文件夹结构，文件仍会以相同方式自动解析路由。
-
-- `api/hello.ts` -> `$BASENAME/hello`
-- `api/user/list.ts` -> `$BASENAME/user/list`
-
-### 动态路由
-
-路由系统支持通过 `[]` 命名的文件目录生成动态路由。
-
-- `api/user/[username]/info.ts` -> `$BASENAME/user/:username/info`
-- `api/user/[username]/delete.ts` -> `$BASENAME/user/:username/delete`
-- `api/article/[id]/info.ts` -> `$BASENAME/article/:id/info`
-
-其中的 `$BASENAME` 可以在 `modern.config.js` 中进行配置，默认值为 `/api`。
-
-### 白名单
-
-默认 `api` 目录下所有文件都会当作 BFF 函数文件去解析，但同样我们也设置了白名单，这些文件不被被解析：
-
-- 命名以 `_` 开头的文件。例如：`_utils.ts`。
-- 命名以 `_` 开头的文件夹下所有文件。例如：`_utils/index.ts`、`_utils/cp.ts`。
-- 测试文件。例如：`foo.test.ts`。
-- TypeScript 类型文件。例如：`hello.d.ts`。
-- `node_module` 下的文件。
-
-## 函数定义
-
-除了上面的路由规则之外，代码中函数定义与导出也有相应的约定。
-
-函数通过具名导出，导出函数的名字为对应接口接受的 HTTP Method，即：
-
-```ts
-export const get = async () => {
-  return {
-    name: 'Modern.js',
-    desc: '现代 web 工程方案',
-  };
-};
-```
-
-这样导出函数，则会得到一个 `GET` 接口。
-
-Modern.js 工程中支持了 9 个 Method 定义，即：`GET`、`POST`、`PUT`、`DELETE`、`CONNECT`、`TRACE`、`PATCH`、`OPTION`、`HEAD`，即可以用这些 Method 作为函数导出的名字。
-
-名字是大小不敏感的，就是说，如果是 `GET`，写成 `get`、`Get`、`GEt`、`GET`，都可以准确识别。而默认导出，即 `export default xxx` 则会被映射为 `Get`。
-
-因为 `delete` 是 JavaScript 中的关键字，可以使用 `del` 或者 `DELETE` 代替。
-
-可以在一个文件中定义多个不同 Method 的函数，但如果定义多个相同 Method 的函数，则只有第一个会生效。
-
-:::info
-需要注意的是，定义的函数都应该是异步的，这个与函数调用时类型有关。
-
-:::

package/docs/zh/apis/app/hooks/api/app.mdx

@@ -1,12 +0,0 @@
----
-title: _app.[tj]s
-sidebar_position: 2
----
-# _app.[tj]s
-
-在 [BFF 函数写法](/guides/advanced-features/bff/type.html#函数写法)下，该文件可以为 BFF 函数添加前置中间件。
-
-:::note
-具体示例请参考 [hook](/apis/app/runtime/bff/hook)
-
-:::

package/docs/zh/guides/advanced-features/bff/type.mdx

@@ -1,46 +0,0 @@
----
-sidebar_position: 2
-title: 函数写法 & 框架写法
----
-# 函数写法 & 框架写法
-
-运行时框架支持也是 **BFF** 中重要的一环。Modern.js 支持通过插件扩展 BFF 的运行时框架，并提供了一系列内置插件，开发者可以直接使用对应框架的约定和生态。
-
-插件中兼容了这些框架大部分的规范，每一种框架都需要提供两类扩展写法 BFF 函数的方式，分别是**函数写法**和**框架写法**。
-
-:::note
-当前 `api/` 目录结构是否为框架写法由对应的插件决定，Modern.js 并不关心。
-
-:::
-
-## 函数写法
-
-当插件认为当前为函数写法时，必须支持在 `api/_app.ts` 中编写中间件，用来扩展 BFF 函数。
-
-Modern.js 会收集 `api/_app.ts` 中的中间件，并传递给插件，由插件将中间件注入运行时，例如：
-
-```ts
-import { hook } from '@modern-js/runtime/server';
-
-export default hook(({ addMiddleware }) => {
-  addMiddleware(myMiddleware);
-});
-```
-
-:::note
-不同插件的中间件的写法不一定相同，详情可见[运行时框架](/guides/advanced-features/bff/frameworks)。
-
-:::
-
-## 框架写法
-
-框架写法是一种使用框架结构来扩展 BFF 函数的方式。和函数写法相比，框架写法虽然能够利用更多框架的结构，在复杂场景下让整个 BFF Server 更加清晰，但也相的更加复杂，需要关心更多框架层面的内容。
-
-框架写法中，所有的 BFF 函数都需要写在 `api/lambda/` 目录下，并且无法使用钩子文件 `_app.[tj]s`。
-
-多数情况下，函数写法就能覆盖大多数 BFF 函数的定制需求。只有当你的项目服务端逻辑比较复杂，代码需要分层，或者需要使用更多框架的元素时，才需要使用框架写法。
-
-:::note
-不同插件框架写法的目录结构不一定相同，详情可见[运行时框架](/guides/advanced-features/bff/frameworks)。
-
-:::