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
Copy file name to clipboardExpand all lines: README.md
+47-4Lines changed: 47 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,8 @@
1
1
# Overview
2
2
3
-
Partial, as of 2022-05-25, implementation of a DynamoDB-based session store for [express-session](https://www.npmjs.com/package/express-session), using the [AWS SDK for JS v3](https://github.com/aws/aws-sdk-js-v3).
3
+
[DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)-based session store for [express-session](https://www.npmjs.com/package/express-session), using the [AWS SDK for JS v3](https://github.com/aws/aws-sdk-js-v3), offering configurability for cost, performance, and reliability not found in other DynamoDB session stores.
4
+
5
+
DynamoDB is an excellent choice for session stores because it is a fully managed service that is highly available, durable, and can scale automatically (to nearly unlimited levels) to meet demand. DynamoDB reads will typically return in 1-3 ms if capacity is set correctly and the caller is located in the same region as the `Table`.
4
6
5
7
# Features
6
8
@@ -10,13 +12,56 @@ Partial, as of 2022-05-25, implementation of a DynamoDB-based session store for
10
12
- This should only be used during PoCs, else tables will be created in any accounts that developers point at using credentials that have permissions to create tables
11
13
- Cost reduction through reducing the TTL write on every read via `.touch()` calls from `express-session`
12
14
-[This PR](https://github.com/expressjs/session/pull/892) for `express-session` would have made that a configurable option for every session store, but alas, it was rejected in favor of implementing the same thing 15+ times
13
-
- These TTL writes consumed WCUs based on the size of the entire session, not just hte`expires` field
15
+
- These TTL writes consumed WCUs based on the size of the entire session, not just the`expires` field
14
16
- These writes were 10x more expensive than reads for under 1 KB session with ConsistentReads turned off
15
17
- These writes were 40x more expensive than reads for 3-4 KB session with consistent reads turned off
16
18
- Cost of 1 WCU is 5x that of 1 RCU
17
19
- Eventually Consistent Read of 4 KB takes 0.5 RCU
18
20
- Write of 1 KB takes 1 WCU, write of 4 KB takes 4 WCU
19
21
22
+
# Configuration Tips
23
+
24
+
- Use a Table per-region if you are deployed in multiple regions
25
+
- Use a Table per-environment if you are deployed in multiple environments (e.g. dev/qa/prod)
26
+
- Use a Table unique to the session store - do not try to overload other data into this Table as the scaling and expiration needs will not overlap well
27
+
- For applications attached to a VPC (including Lambda's attached to a VPC), use a VPC Endpoint for DynamoDB to avoid the cost, latency, and additional reliability exposure of crossing NAT Gateway to reach DynamoDB
28
+
- Use Provisioned Capacity with auto-scaling to avoid throttling and to achieve the lowest cost - On Demand seems nice but it is costly
29
+
30
+
# Example of Pricing
31
+
32
+
Disclaimer: perform your own pricing calculation, monitor your costs during and after initial launch, and setup cost alerts to avoid unexpected charges.
0 commit comments