You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 28, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: packages/serverless-nextjs-component/README.md
+17Lines changed: 17 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,7 @@ A zero configuration Nextjs 9.0 [serverless component](https://github.com/server
16
16
-[Getting started](#getting-started)
17
17
-[Custom domain name](#custom-domain-name)
18
18
-[Architecture](#architecture)
19
+
-[FAQ](#faq)
19
20
20
21
### Motivation
21
22
@@ -84,3 +85,19 @@ myNextApplication:
84
85
The application architecture deployed by the component is the following with minor variations:
85
86
86
87

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