AWS
简单示例

在这里,你可以找到最常见的 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 服务器打包(带有函数拆分)

i

这在 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;