1. File size is a commonly highlighted metric for JS frameworks because of network transfer cost on the client side. For node/bun/deno frameworks, it isn't very relevant, especially the gzipped size.
2. In the benchmark, the number for all frameworks is quite low - I get closer to 80-100k req/s with Bun on my 3-year old machine. Might be worth using a standard VM size in a cloud provider to make it more meaningful.
3. "Cron" scheduling doesn't seem to belong in the library. This won't be very useful for real-world use cases, as soon as you have >1 node running a server you'll need some form of coordination. More size reduction :)
- JWT needs to be validated, as it is, your implementation[1] happily accepts anything, you can impersonate anyone you want. I'd argue that it's a bad default choice too [2]
- baking-in resend.com as email provider is unlikely to be useful for most people
- x-forwarded-for [3] is only added by proxy servers, and will often not be present. This means you'll be applying a shared rate limit to most of your users
- the 'ai' helper is missing from the code. If this is vibe-coded, having tests for the examples will help keep it cohesive
1. File size is a commonly highlighted metric for JS frameworks because of network transfer cost on the client side. For node/bun/deno frameworks, it isn't very relevant, especially the gzipped size.
2. In the benchmark, the number for all frameworks is quite low - I get closer to 80-100k req/s with Bun on my 3-year old machine. Might be worth using a standard VM size in a cloud provider to make it more meaningful.
3. "Cron" scheduling doesn't seem to belong in the library. This won't be very useful for real-world use cases, as soon as you have >1 node running a server you'll need some form of coordination. More size reduction :)