Runtime Engagement

[Jake-Nickel05]

Hello Peppermit Community,

For our Software architecture class, our team explored the Peppermint Ticket Manager codebase with runtime architecture in mind. In the course of our review, we noticed that there was no built‑in mechanism to observe real‑world runtimes of your API endpoints, ticket‑count operations were spread across multiple calls, and background tasks (like image resizing and email fetching) run without any concurrency controls—all of which can lead to hidden bottlenecks, wasted round trips, and an overburdened event loop.

To address these concerns, we’ve introduced a new performance logging middleware as a Fastify plugin that measures the execution time of each request via onRequest and onResponse hooks to log precise timings for each endpoint Fastify. This observability layer highlights slow endpoints and provides actionable data to guide further optimizations. We’ve also consolidated multiple ticket count queries into a single batched endpoint to reduce network latency and simplify client‑side logic. On the server side, CPU‑intensive tasks are offloaded into an async.queue with controlled concurrency to prevent event‑loop blocking. Email fetching in the IMAP service now uses p-limit to cap concurrent connections at five, avoiding resource saturation during heavy loads. Finally, we’ve integrated @fastify/rate-limit in main.ts to throttle API clients at 100 requests per 15‑minute window, protecting against abuse and smoothing traffic spikes. These runtime‑oriented refactors will help lower latency, stabilize throughput, and give us better visibility into performance bottlenecks.

We’d love to hear the community’s feedback!

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	May 8, 2025 9:39pm