Ce este FivePanel?

Majoritatea proprietarilor de servere care vor un panou web ajung să aleagă între trei opțiuni imperfecte. Prima este să îndrepte o interfață directă către baza de date, precum phpMyAdmin sau MongoDB Compass, spre baza de date de producție: astfel datele apar rapid pe ecran, dar oferă oricui deține credențialele acces nerestricționat de citire și scriere la toate tabelele, fără nicio evidență (audit trail) a ceea ce a fost vizualizat, modificat sau șters, și în general necesită expunerea portului bazei de date la internet sau tunelarea în jurul problemei. A doua este un panou construit manual, de obicei o colecție de exporturi Lua combinată cu un backend mic în PHP sau Node: poate fi adaptat exact nevoilor unui singur server, dar este și fragil — orice actualizare a framework-ului, redenumire de coloană sau schimbare a semnăturii unui export îl poate strica pe nesimțite, iar efortul de întreținere cade integral pe umerii celui care l-a scris.

A treia opțiune este un constructor low-code generic, precum Retool sau Appsmith, conectat direct la baza de date. Aceste instrumente sunt mai capabile decât un script improvizat, dar presupun că operatorul cunoaște deja schema și este confortabil să scrie SQL, nu au nicio noțiune despre convențiile specifice FiveM sau RedM, precum coloanele cu metadate serializate în JSON sau array-urile de identificatori, și — la fel ca prima opțiune — necesită în continuare ca baza de date să fie accesibilă de oriunde rulează constructorul.

FivePanel este construit în jurul unui set diferit de constrângeri. În loc să expună baza de date, un agent mic rulează pe aceeași mașină (sau rețea) ca baza de date și inițiază o singură conexiune criptată, de tip outbound, către gateway-ul FivePanel; niciun port de intrare nu este vreodată deschis pe baza de date. Agentul raportează o imagine eșantionată a schemei, pe care FivePanel o folosește pentru a deduce tabele, câmpuri și tipuri probabile de date — inclusiv despachetarea coloanelor JSON folosite frecvent de framework-uri pentru metadatele personajelor — fără ca cineva să fie nevoit să scrie vreo linie de SQL. De aici, panourile sunt asamblate prin plasarea widget-urilor predefinite pe o grilă și legarea lor la câmpurile deduse, în loc de a scrie interogări sau cod frontend.

FivePanel suportă nativ atât MySQL/MariaDB, cât și MongoDB ca ținte de conectare pentru agent. În ambele cazuri, conexiunea se configurează o singură dată, ca un singur șir de conexiune oferit agentului (un DSN MySQL sau un URI MongoDB), iar agentul se ocupă de restul comunicării cu gateway-ul FivePanel.

Esențial este că agentul nu are niciun cod specific unui framework. Nu codifică fix denumiri de tabele, denumiri de coloane sau forme de colecții pentru vreun framework FiveM sau RedM anume. În schimb, eșantionează date live din orice bază de date spre care este îndreptat și deduce structura — tabele, câmpuri, tipuri probabile și forme JSON imbricate — direct din acele date. În practică, asta înseamnă că agentul funcționează la fel de bine cu QBCore, ESX, vRP, OxCore sau o schemă complet personalizată, pentru că din punctul de vedere al agentului sunt toate, pur și simplu, date. Exemplele din tabelul de mai jos sunt configurații reale, comune, pe care le vei vedea documentate în aceste ghiduri, nu o listă fixă de „framework-uri suportate" — dacă schema ta nu se potrivește cu niciuna dintre ele, același proces de deducție se aplică în continuare.