How To Dev

Introduction NextJS Proxy and Rewrites are a powerful duo that helps manage and route requests flexibly. NextJS Rewrites act as an internal proxy, essentially mapping one URL path to another. Its biggest advantage is hiding the actual URL of the underlying core server, while transforming requests from Cross-Origin to Same-Origin on the client interface. NextJS Proxy  allows you to execute code before a request is completed. As a result, you can easily intervene to implement features like Authentication, authorization, or centralized Rate Limiting, reducing the load on the core API server and maximizing performance. Previously, this function was called middleware, the name change to Proxy aims to confirm that this is an ultra-lightweight Gateway layer: It should only be used for tasks such as Routing, Rewrite, Redirect and managing Header/Cookie. NextJS encourages moving Granular Authorization logic or complex session management into Server Components or Server Actions to take...

Introduction In the previous article, I provided instructions on using NextJS Proxy to check API rate limits simply. However, that application method has the following scalability flaws: Using lru-cache only stores data in memory, so when scaling to multiple pods, the rate limit check will be incorrect because pods do not share data with each other. In actual deployment, you rarely let the NextJS server receive requests directly like that, but instead use additional CDNs (Cloudfront, Nginx) to take advantage of edge locations and their data caching capabilities. Therefore, in this article, I will provide a more comprehensive implementation from CDN, NextJS and NestJS servers to handle request spamming, including: Blacklist: automatically block IPs marked as attacking the system. Whitelist: add static IPs and only allow these IPs to use important services, such as allowing partner IPs to use services or deploying internal services accessible only via company VPN. Rate Limit: limit the n...