Design patterns

Recash folosește cinci șabloane de proiectare, fiecare ales pentru o problemă concretă din aplicație:

• Singleton — o singură conexiune la baza de date și la Redis, refolosită peste tot
• Publish/Subscribe — evenimentele live circulă prin canale Redis, fără legături directe între servicii
• Cache-aside — citirile costisitoare trec întâi prin cache
• Middleware — verificarea accesului, într-un singur loc, la marginea aplicației
• Observer — mai multe componente ascultă aceleași evenimente și se actualizează singure când acestea sosesc

Singleton

Clientul Prisma și clientul Redis se creează o singură dată și se refolosesc în toată aplicația. Contează mai ales în dezvoltare: Next.js reîncarcă codul la fiecare salvare de fișier, iar fără acest tipar, fiecare reîncărcare ar deschide o conexiune nouă către baza de date, până la epuizarea celor disponibile.

Publish/Subscribe

Când ceva trebuie livrat instant — o notificare, un mesaj de chat — aplicația Next.js nu trimite nimic direct către client. Publică un eveniment pe un canal Redis, iar serverul WebSocket, care ascultă acel canal, se ocupă de livrare. Cele două servicii rămân independente: niciunul nu depinde de detaliile celuilalt. Detalii complete în Comunicare în timp real.

Cache-aside

Când cineva cere date costisitoare — clasamentul, un profil public — aplicația verifică întâi dacă rezultatul există deja în Redis. Dacă există, îl returnează direct, fără să atingă baza de date. Dacă nu, îl calculează, îl salvează în Redis cu un termen de expirare și abia apoi îl returnează — următoarele cereri îl vor găsi gata pregătit prin Redis.

Middleware

Fiecare cerere trece printr-un punct unic de control înainte să ajungă la orice pagină sau rută API. Se verifică dacă utilizatorul este autentificat și dacă are voie în zona cerută: paginile personale cer cont, iar cererile fără drept de acces sunt oprite pe loc. Regulile de acces stau într-un singur fișier, nu repetate în fiecare pagină.

Observer

Interfața are o singură conexiune WebSocket, dar mai multe zone care depind de ea: clopoțelul de notificări, chat-ul unei postări, indicatorul de status din header. Fiecare dintre acestea se abonează la evenimentele care o interesează, iar când un eveniment sosește, toate componentele abonate își actualizează conținutul în același moment. Niciuna nu gestionează conexiunea și niciuna nu știe de celelalte — doar reacționează la evenimentele primite.