From 5d2c2d5fec7c4e72bfb23e2349b18222b9402a3c Mon Sep 17 00:00:00 2001 From: Dorseuil Nicolas Date: Thu, 19 Sep 2024 18:33:31 +0200 Subject: [PATCH] fixed dead links --- pages/aws/config.mdx | 6 +++--- pages/aws/config/full_example.mdx | 2 +- pages/aws/config/simple_example.mdx | 4 ++-- pages/aws/contribute.mdx | 4 ++-- pages/aws/index.mdx | 4 ++-- pages/aws/inner_workings.mdx | 2 +- pages/aws/inner_workings/architecture.mdx | 4 ++-- pages/aws/inner_workings/cache_interception.mdx | 2 +- pages/aws/inner_workings/routing.mdx | 4 ++-- pages/aws/migration.mdx | 6 +++--- pages/aws/v2/advanced/architecture.mdx | 2 +- pages/aws/v2/common_issues.mdx | 4 ++-- pages/aws/v2/inner_workings/isr.mdx | 2 +- 13 files changed, 23 insertions(+), 23 deletions(-) diff --git a/pages/aws/config.mdx b/pages/aws/config.mdx index 644e9bc..70ab0e1 100644 --- a/pages/aws/config.mdx +++ b/pages/aws/config.mdx @@ -19,8 +19,8 @@ export default { }; ``` -If you want to take a look at some simple configuration examples, you can check the [simple example](/config/simple_example). +If you want to take a look at some simple configuration examples, you can check the [simple example](/aws/config/simple_example). -For more advanced use cases, you can check [how to implement custom overrides](/config/custom_overrides). +For more advanced use cases, you can check [how to implement custom overrides](/aws/config/custom_overrides). -If you want to look at a full example, you can check [the full example](/config/full_example). +If you want to look at a full example, you can check [the full example](/aws/config/full_example). diff --git a/pages/aws/config/full_example.mdx b/pages/aws/config/full_example.mdx index 9aefa81..e0ace38 100644 --- a/pages/aws/config/full_example.mdx +++ b/pages/aws/config/full_example.mdx @@ -3,7 +3,7 @@ This file need to be at the same place as your `next.config.js` file `server` in here could refer to a lambda function, a docker container, a node server or whatever that can support running nodejs code. (Even cloudflare workers in the future) -For more information about the options here, take a look at the [components section](/components/overview). +For more information about the options here, take a look at the [components section](/aws/components/overview). ```ts import type { OpenNextConfig } from 'open-next/types/open-next' diff --git a/pages/aws/config/simple_example.mdx b/pages/aws/config/simple_example.mdx index 367aa55..5fde1fe 100644 --- a/pages/aws/config/simple_example.mdx +++ b/pages/aws/config/simple_example.mdx @@ -17,7 +17,7 @@ Here you can find the most common `open-next.config.ts` file examples that you c is a workaround for that on OpenNext 3.0.3+, setting environment variable `OPEN_NEXT_FORCE_NON_EMPTY_RESPONSE` to `"true"`. This will ensure that the stream body is not empty.

- If you have an issue with streaming send a message on [discord](https://sst.dev/discord) + If you have an issue with streaming send a message on [discord](https://discord.com/channels/1283128968140161065/1286094576788177059) and contact AWS support to let them know of the issue. @@ -107,7 +107,7 @@ export default config; This is not implemented in sst yet. You'll have to use your own IAC construct to deploy this. -Be aware that this uses the exact same system for ISR/SSG as the default lambda setup. So it will have to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/inner_workings/components/server/node#special-overrides) for more details +Be aware that this uses the exact same system for ISR/SSG as the default lambda setup. So it will have to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/aws/inner_workings/components/server/node#special-overrides) for more details ```ts diff --git a/pages/aws/contribute.mdx b/pages/aws/contribute.mdx index 3454c61..21ba89e 100644 --- a/pages/aws/contribute.mdx +++ b/pages/aws/contribute.mdx @@ -1,6 +1,6 @@ To run `OpenNext` locally: -1. Clone [this repository](https://github.com/sst/open-next). +1. Clone [this repository](https://github.com/opennextjs/aws). 2. Build `open-next`: ```bash cd open-next @@ -16,4 +16,4 @@ To run `OpenNext` locally: path/to/open-next/packages/open-next/dist/index.js build ``` -It can be a bit cumbersome to need to deploy every time you want to test changes. If your change is not dependent on the wrapper or the converter, then you can create a custom `open-next.config.ts` file, you can take a look [here](/contribute/local_run) for more information. \ No newline at end of file +It can be a bit cumbersome to need to deploy every time you want to test changes. If your change is not dependent on the wrapper or the converter, then you can create a custom `open-next.config.ts` file, you can take a look [here](/aws/contribute/local_run) for more information. \ No newline at end of file diff --git a/pages/aws/index.mdx b/pages/aws/index.mdx index b6fdb6a..4822790 100644 --- a/pages/aws/index.mdx +++ b/pages/aws/index.mdx @@ -2,9 +2,9 @@ import { SITE } from '../../config'; import { Callout } from 'nextra/components'; -This docs is for the V3 of OpenNext. If you are looking for the V2 docs, you can find them [here](/v2). +This docs is for the V3 of OpenNext. If you are looking for the V2 docs, you can find them [here](/aws/v2). -If you're migrating from V2 to V3, you can find the migration guide [here](/migration#from-opennext-v2). +If you're migrating from V2 to V3, you can find the migration guide [here](/aws/migration#from-opennext-v2). diff --git a/pages/aws/inner_workings.mdx b/pages/aws/inner_workings.mdx index 175f5e6..013fc0f 100644 --- a/pages/aws/inner_workings.mdx +++ b/pages/aws/inner_workings.mdx @@ -2,7 +2,7 @@ When calling `open-next build`, OpenNext **runs `next build`** to build the Next #### Building the Next.js app -OpenNext runs the `build` script in your `package.json` file. Depending on the lock file found in the app, the corresponding packager manager will be used. Either `npm run build`, `yarn build`, or `pnpm build` will be run. For more on customizing the build command, see [overriding the build command](/advanced/options#custom-build-command). +OpenNext runs the `build` script in your `package.json` file. Depending on the lock file found in the app, the corresponding packager manager will be used. Either `npm run build`, `yarn build`, or `pnpm build` will be run. For more on customizing the build command, see [overriding the build command](/aws/advanced/options#custom-build-command). #### Transforming the build output diff --git a/pages/aws/inner_workings/architecture.mdx b/pages/aws/inner_workings/architecture.mdx index 6891699..5b8fc3b 100644 --- a/pages/aws/inner_workings/architecture.mdx +++ b/pages/aws/inner_workings/architecture.mdx @@ -48,7 +48,7 @@ This backend handles image optimization requests when the Next.js `` comp Note that the image optimization backend responds with the `Cache-Control` header, so the image will be cached both at the CDN level and at the browser level. -See [Image Optimization](/features/image-optimization) for more details. +See [Image Optimization](components/image_optimization) for more details. #### Servers Lambda backend @@ -105,7 +105,7 @@ This backend is supposed to handle revalidation requests from the revalidation q OpenNext will create a `.open-next/warmer-function` folder containing the warmer backend. -Read more on [how warming works](/v2/inner_workings/warming). +Read more on [how warming works](/aws/v2/inner_workings/warming). #### Tag Provider backend diff --git a/pages/aws/inner_workings/cache_interception.mdx b/pages/aws/inner_workings/cache_interception.mdx index 8bd13d9..d0fbb1e 100644 --- a/pages/aws/inner_workings/cache_interception.mdx +++ b/pages/aws/inner_workings/cache_interception.mdx @@ -4,7 +4,7 @@ This is great but it still has go through `NextServer` which by default will loa Since OpenNext 3.1, we have added a new feature that we call Cache Interception that allows you to intercept the cache system directly inside OpenNext routing layer and serve the page directly from the cache without going through `NextServer`. If the cache interception fail, the request will be forwarded to the `NextServer` as usual. -Enabling this alongside external middleware means that the external middleware will need to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/inner_workings/components/server/node#special-overrides) for more details. +Enabling this alongside external middleware means that the external middleware will need to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/aws/inner_workings/components/server/node#special-overrides) for more details. This has the following benefits: - Faster cold start (No need to load the js associated with the page if the page is cached) diff --git a/pages/aws/inner_workings/routing.mdx b/pages/aws/inner_workings/routing.mdx index 7be0183..93b0785 100644 --- a/pages/aws/inner_workings/routing.mdx +++ b/pages/aws/inner_workings/routing.mdx @@ -13,10 +13,10 @@ Here is a list of features that OpenNext routing system handle: - basePath - i18n - [Middleware](#next-middleware) -- [Optional Cache Interception](/inner_workings/cache_interception) (i.e. serve ISR/SSG directly from the routing layer) +- [Optional Cache Interception](/aws/inner_workings/cache_interception) (i.e. serve ISR/SSG directly from the routing layer) - Handle 404 in some cases (i.e. when the page does not correspond to any of the regex routes) #### Next Middleware -The Next middleware in OpenNext is not running in the same way as in Next.js. In Next.js, the middleware is running inside the `NextServer` inside a fake edge runtime. In OpenNext, we modify the middleware and run it fully inside the routing layer. So if you run the routing layer in Node, you can use Node api inside the middleware (it's a bit tricky because it won't work with `next dev` and involves some workaround because Next will remove Node api during bundling. Some example [here](/config/custom_overrides#define-a-global-to-use-node-in-the-middleware)). \ No newline at end of file +The Next middleware in OpenNext is not running in the same way as in Next.js. In Next.js, the middleware is running inside the `NextServer` inside a fake edge runtime. In OpenNext, we modify the middleware and run it fully inside the routing layer. So if you run the routing layer in Node, you can use Node api inside the middleware (it's a bit tricky because it won't work with `next dev` and involves some workaround because Next will remove Node api during bundling. Some example [here](/aws/config/custom_overrides#define-a-global-to-use-node-in-the-middleware)). \ No newline at end of file diff --git a/pages/aws/migration.mdx b/pages/aws/migration.mdx index 80fe833..634bbbe 100644 --- a/pages/aws/migration.mdx +++ b/pages/aws/migration.mdx @@ -4,7 +4,7 @@ If your Next.js app is already deployed to another platform or using another ope If you used all the default configurations, you should be able to deploy your app without any changes. -OpenNext V3 replaced all the build args with a [custom config file](/config#configuration-file). +OpenNext V3 replaced all the build args with a [custom config file](/aws/config#configuration-file). Here are the old build args and their new equivalent: @@ -13,7 +13,7 @@ Here are the old build args and their new equivalent: - `--build-output-path`: `buildOutputPath` inside the config file. - `--package-json-path`: `packageJsonPath` inside the config file. - `--minify`: `minify` options inside each function property. This is enabled on a per function basis now. -- `--streaming`: This is dependent on the wrapper you're using on a per function basis. To enable streaming in aws lambda, you can set `wrapper: 'aws-lambda-streaming'` in the override property of the function. Please note that AWS lambda streaming still suffer from buffering issue from the runtime itself. See [here](/inner_workings/components/overview#aws-lambda-streaming) for more info. +- `--streaming`: This is dependent on the wrapper you're using on a per function basis. To enable streaming in aws lambda, you can set `wrapper: 'aws-lambda-streaming'` in the override property of the function. Please note that AWS lambda streaming still suffer from buffering issue from the runtime itself. See [here](/aws/inner_workings/components/overview#aws-lambda-streaming) for more info. - `--dangerously-disable-dynamodb-cache`: `dangerous.disableTagCache` inside the config file. - `--dangerously-disable-incremental-cache`: `dangerous.disableIncrementalCache` inside the config file. @@ -21,7 +21,7 @@ Here are the old build args and their new equivalent: Everything should already be set up for you. But there are a few things you should know: -- Streaming by default is disabled in open-next (for now). It is very **experimental** right now see [here](/inner_workings/streaming) for more info. +- Streaming by default is disabled in open-next (for now). It is very **experimental** right now see [here](/aws/inner_workings/streaming) for more info. - Middleware is not run for static file and for image requests with open-next. #### AWS Amplify diff --git a/pages/aws/v2/advanced/architecture.mdx b/pages/aws/v2/advanced/architecture.mdx index 09cbc63..651abf7 100644 --- a/pages/aws/v2/advanced/architecture.mdx +++ b/pages/aws/v2/advanced/architecture.mdx @@ -165,7 +165,7 @@ Create a Lambda function using the code in the `.open-next/warmer-function` fold Also, create an EventBridge scheduled rule to invoke the warmer function every 5 minutes. -Read more on [how warming works](/inner_workings/warming). +Read more on [how warming works](/aws/v2/inner_workings/warming). #### Dynamo Provider Function diff --git a/pages/aws/v2/common_issues.mdx b/pages/aws/v2/common_issues.mdx index 74e94d7..307fa54 100644 --- a/pages/aws/v2/common_issues.mdx +++ b/pages/aws/v2/common_issues.mdx @@ -14,10 +14,10 @@ If you are using sentry, API routes returns empty body. You could try configurin #### My ISR page has this cache-control header `s-maxage=2, stale-while-revalidate=2592000` -Given how ISR works, while waiting for the revalidation to happen, the page will be served using this cache control header. This prevent your server from being overloaded by a lot of requests while the revalidation is done. You can read more about it [here](/inner_workings/isr). +Given how ISR works, while waiting for the revalidation to happen, the page will be served using this cache control header. This prevent your server from being overloaded by a lot of requests while the revalidation is done. You can read more about it [here](/aws/v2/inner_workings/isr). #### Unzipped size must be smaller than 262144000 bytes AWS Lambda has an unzipped size limit of 250MB. If your app is over this limit, then it is most likely using a node_module library that is too large for serverless or there is a large dev dependency getting bundled. -For example, `pdfjs` has `canvas` optional dependency which takes up 180MB. For more details, [read me](/common_issues/bundle_size). +For example, `pdfjs` has `canvas` optional dependency which takes up 180MB. For more details, [read me](/aws/v2/common_issues/bundle_size). Note: a large bundle size will increase cold start significantly. \ No newline at end of file diff --git a/pages/aws/v2/inner_workings/isr.mdx b/pages/aws/v2/inner_workings/isr.mdx index 2a32b36..d1444a1 100644 --- a/pages/aws/v2/inner_workings/isr.mdx +++ b/pages/aws/v2/inner_workings/isr.mdx @@ -36,7 +36,7 @@ When we check if a page is stale, we check the `revalidatedAt` value for each re #### Cost - Be aware that fetch cache is using S3. `fetch` by default in next is cached, and even for SSR requests, it will be written to S3. This can lead to a lot of S3 requests and can be expensive. You can disable fetch cache by setting `cache` to `no-store` in the `fetch` options. Also see [this workaround](/common_issues/isr#patch-fetch-behaviour-for-isr-only-for-next1351) + Be aware that fetch cache is using S3. `fetch` by default in next is cached, and even for SSR requests, it will be written to S3. This can lead to a lot of S3 requests and can be expensive. You can disable fetch cache by setting `cache` to `no-store` in the `fetch` options. Also see [this workaround](/aws/v2/common_issues/isr#patch-fetch-behaviour-for-isr-only-for-next1351) `get` will be called on every request to ISR and SSG that are not cached in Cloudfront, and `set` will be called on every revalidation.