Next.js 16 și Redis: cum am făcut cache și am devenit eroul open source

Ați văzut vreodată un issue cu tag-ul "Help needed" și v-ați gândit: "Cineva o să se ocupe"? Un curajos n-a așteptat și a lansat un handler de cache Redis pentru Next.js 16. Acum cache-ul în Next.js e mai rapid decât dimineața de luni după cofeină.

Dezvoltatorul cu numele a9b502091e5f4cba28f13 (da, nici noi nu-l pronunțăm) a observat că Next.js 16 nu poate face cache în Redis din cutie. Și în loc să scrie un thread furios pe Twitter, pur și simplu a făcut-o. Soluția s-a dovedit surprinzător de elegantă: un handler care se conectează la API-ul standard Next.js și trimite cache-ul în Redis. Fără cârje, doar cod curat și câteva porții sănătoase de pragmatism.

De ce e important? Pentru că fără Redis, Next.js-ul tău se poate transforma într-o țestoasă pe antidepresive când crește încărcarea. Cu acest handler, totul zboară. Chiar dacă stiva ta arată ca o plăcintă cu mai multe straturi de microservicii, codul ăsta va funcționa ca un ceas elvețian.

Desigur, ai fi putut aștepta soluția oficială de la Vercel, dar cine așteaptă când poți repara singur? Mai ales că open source-ul e ca și cum ai face renovare în apartamentul altcuiva: nimeni nu ți-a cerut, dar dacă iese bine, toată lumea e fericită.

Comentariul studioului METABYTE: Adorăm astfel de povești — când dezvoltatorii nu așteaptă milă de la framework-uri, ci își fac singuri soluții. Dacă proiectul tău Next.js merge încet, iar Redis stă degeaba, acest handler e exact ce ți-a prescris doctorul. Sau inginerul DevOps.