Docs for aws 3.4

pages/aws/config/overrides/_meta.json

@@ -7,5 +7,6 @@
   "image_loader": "Image Loader",
   "proxy_external_request": "External Request Proxy",
   "origin_resolver": "Origin Resolver",
-  "invoke_function": "Invoke Function for the warmer"
+  "invoke_function": "Invoke Function for the warmer",
+  "automatic_cdn_invalidation": "Automatic CDN Invalidation"
 }

pages/aws/config/overrides/automatic_cdn_invalidation.mdx

@@ -0,0 +1,34 @@
+import {Callout} from 'nextra/components'
+
+Available since `@opennextjs/aws` 3.4.0
+
+This override is used by OpenNext when routes have been On-Demand revalidated and the CDN needs to be updated. It is not called for ISR revalidation.
+It will be called for `revalidatePath`, `revalidateTag` and `res.revalidate()`.
+
+If you want to better understand how to implement your own Automatic CDN Invalidation, the easiest way would be to take a look at the existing [included Automatic CDN Invalidation](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/cdnInvalidation)
+
+## Included Automatic CDN Invalidation
+
+### dummy
+
+The Dummy AutomaticCDNInvalidation is a dummy implementation that will do nothing. It is the default implementation.
+
+### cloudfront
+
+<Callout type='warning'>
+Cloudfront invalidation can be very expensive. Manual CloudFront path invalidation incurs costs. According to the [AWS CloudFront pricing page](https://aws.amazon.com/cloudfront/pricing/):
+
+> No additional charge for the first 1,000 paths requested for invalidation each month. Thereafter, $0.005 per path requested for invalidation.
+
+This implementation will request 2 path invalidation requests for every route that needs to be invalidated (one for the route itself and one for the data route).
+
+Tag cache invalidation could end up triggering thousands of invalidation requests.
+
+Only use this implementation if you are aware of the costs and are willing to pay for it.
+</Callout>
+
+The CloudFront Automatic CDN Invalidation will invalidate the cache of the CloudFront distribution.
+
+##### Requirements
+
+- You need to provide the `CLOUDFRONT_DISTRIBUTION_ID` environment variable to your server.

pages/aws/config/overrides/image_loader.mdx

@@ -2,4 +2,32 @@ This override is used by OpenNext and more specifically by the image server to b
 
 This is used for internal image only (i.e. src without host). External source are already handled by the image server.
 
-If you want to better understand how to implement your own ImageLoader, the easiest way would be to take a look at the existing [included ImageLoader](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/imageLoader).
+If you want to better understand how to implement your own ImageLoader, the easiest way would be to take a look at the existing [included ImageLoader](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/imageLoader).
+
+## Included ImageLoader
+
+### s3
+
+The S3 ImageLoader will load images from an S3 bucket. It is used by default if you don't provide any ImageLoader in your configuration.
+It uses the `@aws-sdk/client-s3` to interact with S3.
+
+##### Requirements
+
+- You need to provide the `BUCKET_KEY_PREFIX`, `BUCKET_NAME` environment variables to your server.
+
+### host
+
+The Host ImageLoader will load images from the host.
+This implementation will directly fetch the image from the host.
+
+##### Requirements
+
+The host should be provided in the headers of the request, either in the `X-Forwarded-Host` or the `Host` header.
+
+### fs-dev
+
+The FsDev ImageLoader is a simple implementation that loads images from the `.open-next/assets` folder and interact with it using the filesystem. It is useful for development purposes only.
+
+### dummy
+
+The Dummy ImageLoader is a dummy implementation that will throw an exception. It should not be used.

pages/aws/config/overrides/incremental_cache.mdx

@@ -1,8 +1,71 @@
+import { Callout } from 'nextra/components';
+
 This override is used by the [`cache` adapter](https://github.com/opennextjs/opennextjs-aws/blob/main/packages/open-next/src/adapters/cache.ts) that is provided by OpenNext to the NextServer. It is also used by OpenNext if `enableCacheInterception` is set to `true` in the configuration.
 
 It is used for retrieving and updating the ISR/SSG cache as well as the fetch cache used by Next.js. It does not handle anything related to cache tags (i.e. `revalidateTag` and `revalidatePath`)
 
 If you want to better understand how to implement your own IncrementalCache, the easiest way would be to take a look at the existing [included IncrementalCache](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/incrementalCache).
 
 One thing to note is that it is not used at build time, only at runtime. This means that you'll have to upload the cache yourself if you want to use the prebuilt routes/pages (And this is mandatory for ISR/SSG routes with `fallback:false`).
-All the cache files are present in the `.open-next/cache` folder. The one under `BUILD_ID` are for the ISR/SSG cache and the one under `__fetch/BUILD_ID` are for the fetch cache.
+All the cache files are present in the `.open-next/cache` folder. The one under `BUILD_ID` are for the ISR/SSG cache and the one under `__fetch/BUILD_ID` are for the fetch cache.
+
+## Included IncrementalCache
+
+### s3
+
+The S3 IncrementalCache will store fetch and ISR/SSG cache in an S3 bucket. It is used by default if you don't provide any IncrementalCache in your configuration.
+It uses the `@aws-sdk/client-s3` to interact with S3.
+
+##### Requirements
+
+- You need to provide the `CACHE_BUCKET_REGION`, `CACHE_BUCKET_KEY_PREFIX`, `CACHE_BUCKET_NAME` environment variables to your server.
+
+### s3-lite
+
+The S3Lite IncrementalCache will store fetch and ISR/SSG cache in an S3 bucket
+This implementation is a lighter version of the `s3` IncrementalCache as it uses `aws4fetch` to interact with S3.
+
+##### Requirements
+
+- You need to provide the `CACHE_BUCKET_REGION`, `CACHE_BUCKET_KEY_PREFIX`, `CACHE_BUCKET_NAME`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_SESSION_TOKEN` environment variables to your server.
+
+### dummy
+
+The Dummy IncrementalCache is a dummy implementation that throws exceptions for every method. It should not be used unless you want to disable the cache.
+
+### fs-dev
+
+The FsDev IncrementalCache is a simple implementation that stores the cache in the `.open-next/cache` folder and interact with it using the filesystem. It is useful for development purposes only.
+
+##### Requirements
+
+It needs to run on the local filesystem, and expect to be run from the OpenNext output.
+
+### multi-tier-ddb-s3
+
+<Callout type='warning'>
+Because of how it works, this implementation is only eventually consistent and errors during update could cause inconsistencies between the local cache in some instances and the S3 cache.
+
+It could also end up being slower (and more expensive) than simpler implementations if used in a low traffic serverless environment.
+</Callout>
+
+The MultiTierDdbS3 IncrementalCache is a more complex implementation. 
+Cache are stored in a local In Memory LRU cache as well as in S3. DynamoDB is used to keep local cache in sync between multiple instances of the server.
+It uses `aws4fetch` to interact with S3 and DynamoDB.
+
+##### How does it work
+
+On get :
+1. When a cache is requested, it first checks the local cache. If the cache is not found, it will fetch it from S3 and store it in the local cache.
+2. If the local cache exist for this key, it will check metadata in DynamoDB to see if the cache is still valid. If it is not, it will fetch the cache from S3 and store it in the local cache.
+3. If the local cache is valid, it will return it.
+
+On update :
+1. When a cache is updated, it will first try to update the cache in S3.
+2. If the update is successful, it will update the metadata in DynamoDB.
+3. Finally, it will update the local cache.
+
+##### Requirements
+
+- You need to provide the `CACHE_BUCKET_REGION`, `CACHE_BUCKET_KEY_PREFIX`, `CACHE_BUCKET_NAME`, `CACHE_DYNAMO_TABLE`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_SESSION_TOKEN`, `OPEN_NEXT_LOCAL_CACHE_TTL_MS` (optional), `OPEN_NEXT_LOCAL_CACHE_SIZE`(optional) environment variables to your server.
+- DynamoDB table should have a primary key `path` of type `String` and a sort key `tag` of type `String`. (It can reuse the same table as the one used by the default `tagCache`)

pages/aws/config/overrides/queue.mdx

@@ -1,8 +1,42 @@
+import {Callout} from 'nextra/components'
+
 This override is used by OpenNext to trigger the revalidation of stale routes.
 Before sending the response to the client, OpenNext will check if the route is stale and if it is, it will call the queue override to revalidate the route.
 
 If you want to better understand how to implement your own Queue, the easiest way would be to take a look at the existing [included Queue](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/queue).
 
 Couple of things to note :
 - The default implementation use an SQS queue. This has the main advantage of being able to control the concurrency of the revalidations as well as avoiding trigerring the revalidation multiple times for the same route.
-- You don't have to use a queue at all. You could trigger the revalidation directly in the Queue override itself. You can see a very simple implementation of this [in the `queue` override](/aws/contribute/local_run#devqueuets).
+- You don't have to use a queue at all. You could trigger the revalidation directly in the Queue override itself. You can see a very simple implementation of this [in the `queue` override](/aws/contribute/local_run#devqueuets).
+
+## Included Queue
+
+### sqs
+
+The SQS Queue will send a message to an SQS queue for each route that needs to be revalidated. It is used by default if you don't provide any Queue in your configuration.
+It uses the `@aws-sdk/client-sqs` to interact with SQS.
+
+#### Requirements
+
+- You need to provide the `QUEUE_URL` environment variable to your server.
+
+### sqs-lite
+
+The SQSLite Queue will send a message to an SQS queue for each route that needs to be revalidated.
+This implementation is a lighter version of the `sqs` Queue as it uses `aws4fetch` to interact with SQS.
+
+#### Requirements
+
+- You need to provide the `QUEUE_URL`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_SESSION_TOKEN` environment variables to your server.
+
+### direct
+
+The Direct Queue will directly trigger the revalidation of the route in the Queue override itself. It is useful for development purposes and when you don't want to use a queue.
+
+<Callout type='warning'>
+Be careful with this implementation as it could lead to multiple revalidations of the same route.
+</Callout>
+
+### dummy
+
+The Dummy Queue is a dummy implementation that will throw an exception. It should not be used unless you want to disable ISR.

pages/aws/config/overrides/tag_cache.mdx

@@ -9,4 +9,34 @@ This also has the drawback of needing to prepopulate the cache with all the tags
 
 We might allow to choose how cache tags are handled in the future depending on the `TagCache` implementation. If you need this feature, feel free to open an issue on the [GitHub repository](https://github.com/opennextjs/opennextjs-aws).
 
-If you want to better understand how to implement your own TagCache, the easiest way would be to take a look at the existing [included TagCache](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/tagCache).
+If you want to better understand how to implement your own TagCache, the easiest way would be to take a look at the existing [included TagCache](https://github.com/opennextjs/opennextjs-aws/tree/main/packages/open-next/src/overrides/tagCache).
+
+## Included TagCache
+
+### dynamodb
+
+The DynamoDB TagCache will store the cache tags in a DynamoDB table. It is used by default if you don't provide any TagCache in your configuration.
+It uses the `@aws-sdk/client-dynamodb` to interact with DynamoDB.
+
+##### Requirements
+
+- You need to provide the `CACHE_DYNAMO_TABLE`, `CACHE_BUCKET_REGION` environment variable to your server.
+- DynamoDB table should have a primary key `path` of type `String` and a sort key `tag` of type `String`. (It can reuse the same table as the one used by the default `tagCache`)
+
+### dynamodb-lite
+
+The DynamoDBLite TagCache will store the cache tags in a DynamoDB table.
+This implementation is a lighter version of the `dynamodb` TagCache as it uses `aws4fetch` to interact with DynamoDB.
+
+##### Requirements
+
+- You need to provide the `CACHE_DYNAMO_TABLE`, `CACHE_BUCKET_REGION`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_SESSION_TOKEN` environment variables to your server.
+- DynamoDB table should have a primary key `path` of type `String` and a sort key `tag` of type `String`. (It can reuse the same table as the one used by the default `tagCache`)
+
+### dummy
+
+The Dummy TagCache is a dummy implementation that will throw an exception. It should not be used unless you want to disable cache tags.
+
+### fs-dev
+
+The FsDev TagCache is a simple implementation that stores the cache tags in a file in the `.open-next/cache` folder and interact with it using the filesystem. It is useful for development purposes only.

pages/aws/config/overrides/wrapper.mdx

@@ -7,3 +7,62 @@ Couple of things to note :
 - If you don't use streaming (like in the default `aws-lambda` wrapper), you may still need to provide a fake `StreamCreator` to the `handler` to avoid a weird issue with Node itself (see [here](https://github.com/opennextjs/opennextjs-aws/blob/f685ddea8f8a5c82591dc02713aff7138f2d9896/packages/open-next/src/overrides/wrappers/aws-lambda.ts#L49-L65) for an example and a more thorough explanation).
 - If you use the `edge` runtime of Next (either for the external middleware or for an `edge` route or page), you don't need the `StreamCreator` at all.
 - If you are in a serverless environment and it supports `waitUntil`, you should define it here(see [here](https://github.com/opennextjs/opennextjs-aws/blob/f685ddea8f8a5c82591dc02713aff7138f2d9896/packages/open-next/src/overrides/wrappers/cloudflare.ts#L29)). This might not be necessary depending on where you run it (for example the `aws-lambda-streaming` or the `node` wrapper doesn't need it.)
+
+
+## Included Wrappers
+
+### aws-lambda
+
+The `aws-lambda` Wrapper is the default wrapper for AWS Lambda. It is used by default if you don't provide any Wrapper in your configuration.
+
+#### Features
+- [ ] Streaming
+- [ ] Proper support for `waitUntil`
+
+### aws-lambda-streaming
+
+The `aws-lambda-streaming` Wrapper is a wrapper that allows you to use streaming in AWS Lambda. Streaming must be enabled for this lambda.
+
+#### Features
+- [x] Streaming
+- [x] Proper support for `waitUntil`
+
+### cloudflare-edge
+
+The `cloudflare-edge` Wrapper is the wrapper for Cloudflare Workers. It should be used for the external middleware and for the `edge` runtime of Next.
+
+#### Features
+- [x] Streaming
+- [x] Proper support for `waitUntil`
+
+### cloudflare-node
+
+The `cloudflare-node` Wrapper is the wrapper for Cloudflare Workers. It should be used only with the `node` runtime of Next and if you use `@opennextjs/cloudflare`.
+
+#### Features
+- [x] Streaming
+- [x] Proper support for `waitUntil`
+
+### node
+
+The `node` Wrapper is the wrapper for classic Node.js Server. This one is a long running server.
+
+#### Features
+- [x] Streaming
+- [x] Proper support for `waitUntil`
+
+### express-dev
+
+The `express-dev` Wrapper is the wrapper for a classic Express server. It is a long running process and should be used for development purposes only.
+
+#### Features
+- [x] Streaming
+- [x] Proper support for `waitUntil`
+
+### dummy
+
+The `dummy` Wrapper is a dummy implementation that will just forward the event and `StreamCreator` to the handler.
+
+#### Features
+- [ ] Streaming
+- [ ] Proper support for `waitUntil`