在这里,你可以找到最常见的 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
// 在这种情况下,我们没有提供任何 override,因此它将生成一个普通的 lambda(即没有流式传输)
default: {},
// 你可以在这里定义多个函数,每个函数都有自己的 routes、patterns 和 overrides
functions: {
myFn: {
// Patterns 需要使用 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 与它们交互。这可能会导致冷启动时间增加很多。有一个内置选项可以使用 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 构造来部署它。
请注意,这与默认 lambda 设置使用完全相同的 ISR/SSG 系统。因此它必须拥有所有适当的权限和环境变量才能与 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,
},
},
// 你可以在这里定义多个函数,每个函数都有自己的 routes、patterns 和 overrides
functions: {
// 在这种情况下,api 路由都在 lambda 中,其余都在 node 中
myFn: {
// Patterns 需要使用 glob 模式
patterns: ["api/*"],
routes: ["app/api/test/route", "app/api/test2/route"],
},
},
} satisfies OpenNextConfig;
export default config;Edge runtime 拆分函数
这将生成 2 个服务器函数,默认函数和 edge 函数。edge 函数仍将作为 lambda 函数部署,但它将部署在 edge runtime 中。
Edge runtime 函数具有更少的冷启动时间,但你每个函数只能部署一个路由。它们也没有将 middleware 捆绑在函数中,因此如果你需要在 edge 函数前面使用它,则需要使用外部 middleware。
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;外部 middleware
在某些情况下(edge runtime、带有某些 middleware 重写的函数拆分等),你可能想要使用外部 middleware。 使用默认 middleware 配置时,它是为 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;