Simple Example - OpenNext 中文文档

在这里您可以找到最常见的 open-next.config.ts 文件示例，这些示例可以作为您自己配置的起点。

使用 Lambda 实现流式传输

ℹ️

如果您遇到流式传输问题，请在 discord (opens in a new tab) 发送消息并联系 AWS 支持告知该问题。

import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
const config = {
  default: {
    override: {
      wrapper: "aws-lambda-streaming", // 这是启用 lambda 流式传输的必要配置
    },
  },
} satisfies OpenNextConfig;
 
export default config;

请注意，过去曾出现过 AWS 突然中断流式传输的问题。目前这个问题似乎已经解决。讨论1 (opens in a new tab) 讨论2 (opens in a new tab)

拆分服务器

import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
const config = {
  // 这是默认服务器，类似于 open-next v2 中的 server-function
  // 这里我们没有提供任何覆盖配置，因此会生成一个普通的 lambda（即没有流式传输）
  default: {},
  // 您可以在这里定义多个函数，每个函数都有自己的路由、匹配模式和覆盖配置
  functions: {
    myFn: {
      // 匹配模式需要使用 glob 模式
      patterns: ["route1", "route2", "route3"],
      // 对于 app 目录，您需要包含 route|page，不需要包含 layout 或 loading
      // 需要根据使用的目录前缀为 app/ 或 pages/
      routes: ["app/route1/page", "app/route2/page", "pages/route3"],
      override: {
        wrapper: "aws-lambda-streaming",
      },
    },
  },
} satisfies OpenNextConfig;
 
export default config;

使用 aws4fetch 替代 AWS SDK

ℹ️

默认情况下，我们使用 S3、DynamoDB 和 SQS 来处理 ISR/SSG 和 fetch 缓存。我们通过 AWS SDK v3 与这些服务交互，这可能会显著增加冷启动时间。OpenNext 内置了一个选项，可以使用 aws4fetch (opens in a new tab) 替代 AWS SDK，最多可减少 300ms 的冷启动时间。需要 OpenNext v3.0.3+ 版本。启用方式如下：

import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
const config = {
  default: {
    override: {
      tagCache: "dynamodb-lite",
      incrementalCache: "s3-lite",
      queue: "sqs-lite",
    },
  },
} satisfies OpenNextConfig;
 
export default config;

在 Lambda@Edge 中运行

import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
const config = {
  default: {
    placement: "global",
    override: {
      converter: "aws-cloudfront",
    },
  },
} satisfies OpenNextConfig;
 
export default config;

为经典 Node 服务器打包（带函数拆分功能）

当前 SST 尚未实现此功能。你需要使用自己的 IAC 构造来部署此配置。

请注意，该系统使用的 ISR/SSG 机制与默认的 Lambda 设置完全相同。因此它需要具备与 S3、DynamoDB 和 SQS（或你覆盖的其他服务）交互的所有权限和环境变量。更多细节可查看此处

import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
const config = {
  // 这种情况下，默认服务器将作为经典 Node 服务器运行
  // 要执行服务器，你需要在 `.open-next/server-functions/default` 目录下运行 `node index.mjs`
  default: {
    override: {
      wrapper: "node",
      converter: "node",
      // 这是生成简单 dockerfile 所必需的，也让生成的输出知道需要通过 docker 部署
      // 你也可以在这里提供一个字符串（即 Dockerfile 的内容）用于创建 dockerfile
      // 如果你不打算使用 docker，或者打算使用自定义的 dockerfile，则无需提供此项
      generateDockerfile: true,
    },
  },
  // 你可以在这里定义多个函数，每个函数都有自己的路由、匹配模式和覆盖配置
  functions: {
    // 这个例子中 API 路由在 lambda 中运行，其余部分在 node 中运行
    myFn: {
      // 匹配模式需要使用 glob 语法
      patterns: ["api/*"],
      routes: ["app/api/test/route", "app/api/test2/route"],
    },
  },
} satisfies OpenNextConfig;
 
export default config;

Edge runtime 分割函数

这将生成两个服务器函数：默认函数和 edge 函数。edge 函数仍会作为 Lambda 函数部署，但会在 edge runtime 中运行。

Edge runtime 函数的冷启动时间更短，但每个函数只能部署一个路由。它们也不会在函数中打包中间件，因此如果需要在 edge 函数前使用中间件，必须使用外部中间件。

import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
const config = {
  default: {},
  functions: {
    edge: {
      runtime: "edge",
      //placement: "global", 如果您希望函数全局部署（即 lambda@edge），请取消此行注释。否则函数将部署在栈中指定的区域
      routes: ["app/api/test/route"],
      patterns: ["api/test"],
    },
  },
} satisfies OpenNextConfig;
 
export default config;

外部中间件

在某些情况下（如 edge runtime、带有中间件重写的函数分割等），您可能需要使用外部中间件。默认的中间件配置会为 lambda@edge 部署打包中间件。以下是配置方法：

import type { OpenNextConfig } from "@opennextjs/aws/types/open-next.js";
const config = {
  default: {},
  functions: {
    myFn: {
      patterns: ["route1", "route2", "route3"],
      routes: ["app/route1/page", "app/route2/page", "pages/route3"],
      override: {
        wrapper: "aws-lambda-streaming",
      },
    },
  },
  middleware: {
    external: true,
  },
} satisfies OpenNextConfig;
 
export default config;