In sviluppo CyberHabbo Versione 0.01 [Node.JS - CSS3 - HTML5 - Glassmorphism]

[#Egzon14]

Bella a tutti.

Vado dritto al punto: mi sono stufato di vedere i retro-server fermi al 2010. Sempre i soliti CMS in PHP pesanti, buggati e graficamente tutti uguali. Ho deciso di resettare tutto e di mettermi a scrivere un Mainframe proprietario in Node.js. Qui non si parla di modificare quattro righe di un file .php, ma di architettura seria.

️ Perché questo CMS è un'altra cosa​

Ho scelto di usare tecnologie moderne per avere prestazioni atomiche:

• Engine: Tutto gira su Node.js. È veloce, asincrono e gestisce migliaia di connessioni senza battere ciglio. Il PHP a confronto sembra un reperto archeologico.
• Database Cloud: Mi sono staccato dal locale. Gestisco tutto su cluster Aiven. Dati criptati, backup istantanei e una stabilità che vi sognate con i soliti database buttati lì sul server.
• Interfaccia: Ho puntato sul Glassmorphism. Niente colori piatti o layout amatoriali. Trasparenze, sfocature ed effetti neon. È un portale che sembra un terminale operativo, pulito e futuristico.

Feature del Mainframe​

Il sito deve essere il vero centro dell'hotel, non solo una pagina di login:

• Betting Engine Integrato: Questa è la vera bomba. Un modulo scommesse dove puoi puntare i tuoi crediti sui risultati reali (Serie A, Champions, ecc.). Quote calcolate dal sistema e pagamenti automatici. Se ne capisci di calcio, fai i soldi seri.
• The Vault (Staking): Gestione finanziaria. Puoi vincolare i tuoi risparmi per ottenere interessi in diamanti. Una vera banca interna per chi vuole giocare con l'economia.
• Marketplace Real-Time: Compri e vendi rari direttamente dal web. Tutto sincronizzato, con grafici dei prezzi per fare trading come si deve.
• Sicurezza Totale: Ogni accesso passa per un ticket SSO (Single Sign-On) unico. Niente falle banali e niente attacchi stupidi al database.

Il progetto è in fase di sviluppo, sto finendo di blindare il cuore del sistema.

-N33rvo

 

[Cosimo Celeste]

Il progetto di per se è bello ed interessante, ma nel 2026 il CMS è diventato superfluo
Potresti levarlo, far accedere direttamente al client e nessuno noterebbe la differenza tra CMS si/no

Come dicevo, tuttavia, il progetto è bello ed interessante:
Io in primis lavoro con il cloud e avere il DB in cloud è buono, ma punterei su un connection pool, un po' come faresti con SQL Server su Azure che ti da più libertà di manovra sulle connessioni al server stesso

Per l'engine, NodeJS penso sia molto buono e moderno, ma lavorando come back-end developer su ASP NET, per preferenza personale sceglierei di gran lunga quello, essendo anche molto flessibile e permette configurazioni a basso livello come faresti con NGINX su un server linux

Infatti, io avevo iniziato un progetto il cui obiettivo era Nitro SSR, con web server stesso ASP NET Blazor WebAssembly, che funge anche da emulatore tramite SignalR + un API per levare di mezzo il socket che oggi è in giro con l'RCON (o MUS, a seconda dei tempi e dal server usato), mentre uso Entity Framework che come ORM per c# è ormai ampiamente il più utilizzato

Accodato a questo, avevo una libreria di codice comune C# che ho sviluppato e sfruttato, il quale mi ha semplificato molta della gestione base di un CMS o Emulatore

Il tutto, protetto da YARP che funge da gateway di protezione per attacchi L7, proxy e access point sulle reti interne in cui sono caricati i due progetti

Il punto è anche un altro: nel 2026, in Italia, persone che possono capire e/o apprezzare questo tipo di progetto sono ormai estinte e defunte, tant'è che il mio lo sto portando avanti come know-how personale più che come intenzionato ad usarlo davvero

 

[#Egzon14]

Il progetto di per se è bello ed interessante, ma nel 2026 il CMS è diventato superfluo
Potresti levarlo, far accedere direttamente al client e nessuno noterebbe la differenza tra CMS si/no

Come dicevo, tuttavia, il progetto è bello ed interessante:
Io in primis lavoro con il cloud e avere il DB in cloud è buono, ma punterei su un connection pool, un po' come faresti con SQL Server su Azure che ti da più libertà di manovra sulle connessioni al server stesso

Per l'engine, NodeJS penso sia molto buono e moderno, ma lavorando come back-end developer su ASP NET, per preferenza personale sceglierei di gran lunga quello, essendo anche molto flessibile e permette configurazioni a basso livello come faresti con NGINX su un server linux

Infatti, io avevo iniziato un progetto il cui obiettivo era Nitro SSR, con web server stesso ASP NET Blazor WebAssembly, che funge anche da emulatore tramite SignalR + un API per levare di mezzo il socket che oggi è in giro con l'RCON (o MUS, a seconda dei tempi e dal server usato), mentre uso Entity Framework che come ORM per c# è ormai ampiamente il più utilizzato

Accodato a questo, avevo una libreria di codice comune C# che ho sviluppato e sfruttato, il quale mi ha semplificato molta della gestione base di un CMS o Emulatore

Il tutto, protetto da YARP che funge da gateway di protezione per attacchi L7, proxy e access point sulle reti interne in cui sono caricati i due progetti

Il punto è anche un altro: nel 2026, in Italia, persone che possono capire e/o apprezzare questo tipo di progetto sono ormai estinte e defunte, tant'è che il mio lo sto portando avanti come know-how personale più che come intenzionato ad usarlo davvero

Analisi ineccepibile, si vede che mastichi .NET ad alti livelli.

L'idea di Blazor WebAssembly con SignalR per bypassare i vecchi socket è affascinante, praticamente rendi il client "dumb" e sposti tutto su API/Gateway. Sicuramente YARP offre una sicurezza che un semplice TCP socket si sogna.

Però il mio obiettivo attuale è didattico ma orientato alla "Speed of Delivery". Ho scelto lo stack Node.js (Full Stack JS) proprio per avere un unico contesto linguistico tra Backend, Frontend e gestione DB, senza il context-switch di dover gestire l'ecosistema Microsoft per un progetto solo.

Sul discorso CMS: l'idea è proprio quella. Sto costruendo un monolite in Node che gestisce auth e sessione, per poi iniettare direttamente l'utente nel client (Nitro) riducendo al minimo la "navigazione web" classica.

Lo faccio per know-how personale come te, ma se esce qualcosa di carino, magari qualche nostalgico che apprezza la fluidità rispetto ai vecchi retro PHP lo trovo ancora!

 

[Cosimo Celeste]

Il progetto di per se è bello ed interessante, ma nel 2026 il CMS è diventato superfluo
Potresti levarlo, far accedere direttamente al client e nessuno noterebbe la differenza tra CMS si/no

Come dicevo, tuttavia, il progetto è bello ed interessante:
Io in primis lavoro con il cloud e avere il DB in cloud è buono, ma punterei su un connection pool, un po' come faresti con SQL Server su Azure che ti da più libertà di manovra sulle connessioni al server stesso

Per l'engine, NodeJS penso sia molto buono e moderno, ma lavorando come back-end developer su ASP NET, per preferenza personale sceglierei di gran lunga quello, essendo anche molto flessibile e permette configurazioni a basso livello come faresti con NGINX su un server linux

Infatti, io avevo iniziato un progetto il cui obiettivo era Nitro SSR, con web server stesso ASP NET Blazor WebAssembly, che funge anche da emulatore tramite SignalR + un API per levare di mezzo il socket che oggi è in giro con l'RCON (o MUS, a seconda dei tempi e dal server usato), mentre uso Entity Framework che come ORM per c# è ormai ampiamente il più utilizzato

Accodato a questo, avevo una libreria di codice comune C# che ho sviluppato e sfruttato, il quale mi ha semplificato molta della gestione base di un CMS o Emulatore

Il tutto, protetto da YARP che funge da gateway di protezione per attacchi L7, proxy e access point sulle reti interne in cui sono caricati i due progetti

Il punto è anche un altro: nel 2026, in Italia, persone che possono capire e/o apprezzare questo tipo di progetto sono ormai estinte e defunte, tant'è che il mio lo sto portando avanti come know-how personale più che come intenzionato ad usarlo davvero

Analisi ineccepibile, si vede che mastichi .NET ad alti livelli.

L'idea di Blazor WebAssembly con SignalR per bypassare i vecchi socket è affascinante, praticamente rendi il client "dumb" e sposti tutto su API/Gateway. Sicuramente YARP offre una sicurezza che un semplice TCP socket si sogna.

Però il mio obiettivo attuale è didattico ma orientato alla "Speed of Delivery". Ho scelto lo stack Node.js (Full Stack JS) proprio per avere un unico contesto linguistico tra Backend, Frontend e gestione DB, senza il context-switch di dover gestire l'ecosistema Microsoft per un progetto solo.

Sul discorso CMS: l'idea è proprio quella. Sto costruendo un monolite in Node che gestisce auth e sessione, per poi iniettare direttamente l'utente nel client (Nitro) riducendo al minimo la "navigazione web" classica.

Lo faccio per know-how personale come te, ma se esce qualcosa di carino, magari qualche nostalgico che apprezza la fluidità rispetto ai vecchi retro PHP lo trovo ancora!

Ok si, quindi diciamo l'idea è farlo come overlay su nitro o sidebar, ma diciamo che l'utente esegue azioni sul cms stando nel client stesso?
Per quanto la scelta di NodeJS per avere unico contesto, tanta roba, ma avrebbe davvero senso se rendi nitro stesso come modulo stesso del progetto, o altrimenti avrai comunque contesti e build separati tra nitro e cms in sè
Ecco anche perché ho scelto L'SRR su ASP NET: Compilo nitro e me lo richiamo in asp net (non è SSR reale, poiché il client JS rimane, solo il serve non lo fa più chrome tramite lettura dei JS, ma direttamente il webserver)
In ogni caso, sarei curioso di vedere qualche snippets in futuro. Ho anche visto qualche video credo di CyberHabbo a questo punto tramite #Retaccid , che sto aiutando sul suo progetto internazionale HSmile
Se vuoi scambio di opinioni, se hai discord, ti mando il mio contatto in DM

 

[.Danilo]

Buonasera, mi intrometto nel discorso:

secondo me state dicendo la stessa cosa da due livelli diversi.
Egzon vuole un sistema veloce da evolvere, con un solo stack, poco attrito e tanto focus sulle feature. In questo senso Node + full JS + cloud DB + SSO + moduli economici è una scelta coerente. Non è un “CMS”, è più un control layer che governa il mondo di gioco, e questo cambia completamente il discorso.
Cosimo invece sta ragionando da enterprise architect: gateway, SSR integrato, SignalR, YARP, EF, librerie condivise, domini centralizzati. È una visione molto più “strutturale”, pensata per durare, scalare e sopravvivere nel tempo anche con team grandi e requisiti di sicurezza elevati.

Il punto non è quindi Node vs .NET o CMS sì / no, ma:
velocità e sperimentazione vs solidità e governance a lungo termine

Egzon punta sulla speed of delivery e sull’unificazione dello stack, Cosimo sulla robustezza architetturale e sull’integrazione totale tra web, client ed emulatore.
Entrambi gli approcci hanno senso, ma per obiettivi diversi:

• se lo scopo è innovare, testare idee e rompere i limiti dei vecchi retro, la strada di Egzon è più adatta;
• se lo scopo è costruire una piattaforma “definitiva”, con security, gateway, dominio centralizzato e controllo totale, allora la visione di Cosimo è più sostenibile

 

[#Egzon14]

AGGIORNAMENTO STYLE:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Cosimo Celeste]

Buonasera, mi intrometto nel discorso:

secondo me state dicendo la stessa cosa da due livelli diversi.
Egzon vuole un sistema veloce da evolvere, con un solo stack, poco attrito e tanto focus sulle feature. In questo senso Node + full JS + cloud DB + SSO + moduli economici è una scelta coerente. Non è un “CMS”, è più un control layer che governa il mondo di gioco, e questo cambia completamente il discorso.
Cosimo invece sta ragionando da enterprise architect: gateway, SSR integrato, SignalR, YARP, EF, librerie condivise, domini centralizzati. È una visione molto più “strutturale”, pensata per durare, scalare e sopravvivere nel tempo anche con team grandi e requisiti di sicurezza elevati.

Il punto non è quindi Node vs .NET o CMS sì / no, ma:
velocità e sperimentazione vs solidità e governance a lungo termine

Egzon punta sulla speed of delivery e sull’unificazione dello stack, Cosimo sulla robustezza architetturale e sull’integrazione totale tra web, client ed emulatore.
Entrambi gli approcci hanno senso, ma per obiettivi diversi:

• se lo scopo è innovare, testare idee e rompere i limiti dei vecchi retro, la strada di Egzon è più adatta;
• se lo scopo è costruire una piattaforma “definitiva”, con security, gateway, dominio centralizzato e controllo totale, allora la visione di Cosimo è più sostenibile

Esatto, inoltre il mio NextHave è anche pensato per essere gestito tramite Kubernetes
Diciamo che il mio obiettivo era creare un eventuale network
Ovvero, un unico software che incorpora habbo, ma dove habbo non è il core concept
Un po' come fortnite oggi no? Una volta era solo battle royale, oggi dalla loby selezioni "a cosa voglio giocare?"
Per me è un idea che potrebbe portare grandi benefici, ma con gli attuali progetti in circolazione, gestire qualcosa di questo calibro comporta una mole di lavoro che non credo abbia senso caricarsi addosso

Per tanto, ho pensato a quest'architettura, in risposta a pensieri, esperienze dirette e contatti con i clienti avvenuti durante il corso della mia esperienza professionale:

1. Adottare la metodologia sviluppo agile del software
2. Adottare il concetto di Software as a service
   Vorrei dare un po' di contesto per questo: ad oggi, un grande problema di ogni retro è dovuto al riavvio manuale dell'emulatore e le prestazioni stesse dovute magari ad un maggiore carico di utenza
   Qui vorrei invece far notare che habbo funziona a microservizi: se habbo ha bisogno di fare manutenzione sul catalogo, è il catalogo ad essere offline, non habbo nella sua interezza
   Pensando in quest'ottica, come rendere automatico ancora di più questo? La mia risposta personale è stata quella di trasformare il concetto di emulatore come "software", e fornirlo come "servizio"
   In realtà la differenza non è così netta come sembra, e cambia solo l'approccio in cui utilizzeresti l'emulatore, e neanche ne adotti completamente il principio
   Il SaaS, per concezione, è la trasposizione del "acquisto una licenza, mi installo il software sul mio server e da lì mi gestisco l'operatività quotidiana" in "Acquisto l'abbonamento, utilizzo il servizio, però tutto il carico di lavoro (infrastruttura, aggiornamenti, backup, sicurezza) me lo gestisce il manutentore dell'abbonamento, e io mi configuro il servizio in base alle mie esigenze"
   Le differenze, la più importante a mio parere è la scalabilità del retroserver: In un approccio classico, richiedi hardware aggiuntivo, mentre in un software SaaS la scalabilità si traduce in "pago di più e il manutentore mi dedica più risorse"
   Non useresti l'abbonamento dell'approccio SaaS, ma guarda ai retroscena del manutentore, e in un contesto kubernetes la gestione della scalabilità si traduce in pochi click se si tratta di un managed kubernetes come AKS (Azure Kubernetes Services)
3. Divedere il concetto di singolo server in N microservizi diversi

Il che mi si traduce in: possibilità di prestazioni migliori, evoluzione dei retroserver e corretto funzionamento del retroserver anche in caso di manutenzione per correzioni

 

[#Egzon14]

UPDATE:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Aggiunto il sistema scommesse! Con quote reali