Skip to content
This repository was archived by the owner on Jan 28, 2025. It is now read-only.

Commit 9ed16be

Browse files
add FAQ
1 parent 3d74563 commit 9ed16be

File tree

1 file changed

+17
-0
lines changed
  • packages/serverless-nextjs-component

1 file changed

+17
-0
lines changed

packages/serverless-nextjs-component/README.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,7 @@ A zero configuration Nextjs 9.0 [serverless component](https://github.com/server
1616
- [Getting started](#getting-started)
1717
- [Custom domain name](#custom-domain-name)
1818
- [Architecture](#architecture)
19+
- [FAQ](#faq)
1920

2021
### Motivation
2122

@@ -84,3 +85,19 @@ myNextApplication:
8485
The application architecture deployed by the component is the following with minor variations:
8586
8687
![architecture](./arch.png)
88+
89+
### FAQ
90+
91+
_Is it one monolith Lambda or one Lambda per serverless page?_
92+
93+
Only one Lambda is provisioned. There are a few reasons why:
94+
95+
- Simplicity. One lambda responsible for server side rendering or serving the API requests is very easy to manage. On the other hand, one lambda per page is a large surface area for a web app. For example a next application with 40+ pages would have resulted in 40+ lambda functions to maintain.
96+
97+
- Deployment speed. Is much faster building and deploying one lambda function.
98+
99+
Of course there are tradeoffs ... An architecture using one lambda per page in theory results in lower boot times. However, the implementation of this component is designed to ensure a minimum amount of compute happens at the Lambda@Edge.
100+
101+
_How do I interact with other AWS Services within my app_?
102+
103+
See `examples/dynamodb-crud` for an example Todo application that interacts with DynamoDB.

0 commit comments

Comments
 (0)