Menu
Forums
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Trending
What's new
New posts
New profile posts
Latest activity
Members
Current visitors
New profile posts
Search profile posts
Upgrades
Log in
Register
What's new
Search
Search
Search titles only
By:
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
Server Development
Habbo Retros
Habbo Development
Envy ~ Distributed Habbo Retros
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Leader" data-source="post: 477363" data-attributes="member: 21320"><p><strong><span style="color: rgb(44, 130, 201)"><span style="font-size: 22px">Envy</span></span></strong></p><p><strong></strong></p><p><strong>Introduction:</strong></p><p>Throughout my career, I've worked on several projects focused on creating a suite of libraries to streamline the development of Habbo retro applications. Along the way, I've accumulated invaluable insights and started contemplating the future of retro architecture—specifically, how to resolve persistent issues from the past.</p><p></p><p>Initially, retros were developed with the straightforward goal of reverse-engineering Habbo. Developers didn't fully consider the long-term implications or how to make these projects scalable. As a result, hundreds of emulators have been built, with only a few gaining significant community traction. Most, however, suffer from the same core problem: monolithic architecture.</p><p></p><p>MMOs, such as Habbo, are designed to handle thousands, if not millions, of concurrent users. While modern retros don't necessarily aim for those numbers, the consequences of monolithic design quickly surface. The retro community remains restricted by outdated architectural decisions, with development often shaped by constraints like the revision, CMS, HTML5, app, or SWF. A well-designed emulator shouldn't be hindered by these variables.</p><p></p><p>The solution is <strong>distributed architecture</strong> based on microservices. With a modern stack you get a system that is scalable, resilient, and performant.</p><p></p><hr /><p><strong>Project Goals:</strong></p><ul> <li data-xf-list-type="ul">Develop a distributed architecture capable of scaling to millions of users.</li> <li data-xf-list-type="ul">Provide common types and libraries for both front-end and back-end.</li> <li data-xf-list-type="ul">Provide an external <strong>GraphQL Websocket API</strong> for CMS and plugin implementations to support real-time updates.</li> <li data-xf-list-type="ul">Use an internal <strong>Kafka</strong> messaging system for efficient microservice communication.</li> <li data-xf-list-type="ul">Ensure strict separation of concerns in the codebase.</li> <li data-xf-list-type="ul">Enable database distribution for optimal scaling.</li> </ul><hr /><p><strong>Scope Goals:</strong></p><ul> <li data-xf-list-type="ul">Provide the essential foundation to help you implement your preferred retro revision</li> <li data-xf-list-type="ul">Accomplish this without dictating how users connect or interact with the system.</li> <li data-xf-list-type="ul">Scale Up will provide its events and API calls, which can be integrated into your business logic or packet structure.</li> <li data-xf-list-type="ul">Offer a full implementation example using Nitro.</li> </ul><p><strong>Tech Stack:</strong></p><ul> <li data-xf-list-type="ul"><strong>Golang</strong>: High-performance, efficient language for building scalable microservices.</li> <li data-xf-list-type="ul"><strong>Kafka</strong>: Distributed messaging system for reliable, asynchronous communication between services.</li> <li data-xf-list-type="ul"><strong>Protobuff</strong>: Lightweight and efficient serialization format for structured data transmission.</li> <li data-xf-list-type="ul"><strong>Postgres</strong>: Robust, relational database for storing structured data and ensuring ACID compliance.</li> <li data-xf-list-type="ul"><strong>MongoDB</strong>: NoSQL database for flexible, unstructured or semi-structured data storage.</li> <li data-xf-list-type="ul"><strong>Redis</strong>: In-memory data structure store used for caching and real-time performance.</li> <li data-xf-list-type="ul"><strong>GraphQL</strong>: Query language for APIs, enabling flexible and efficient client-server interactions.</li> <li data-xf-list-type="ul"><strong>WebSockets</strong>: Protocol for real-time, bi-directional communication, critical for live updates.</li> </ul><p><strong>Architecture:</strong></p><ul> <li data-xf-list-type="ul"><strong>Internal-Facing Services</strong>: All microservices are designed to be internal, with no direct external API exposure.</li> <li data-xf-list-type="ul"><strong>Backend for Frontend (BFF)</strong>: External interactions, whether from the CMS or the game client, are routed through a BFF layer. This isolates the core services and optimizes interactions tailored specifically for client needs, ensuring security and performance.</li> </ul></blockquote><p></p>
[QUOTE="Leader, post: 477363, member: 21320"] [B][COLOR=rgb(44, 130, 201)][SIZE=6]Envy[/SIZE][/COLOR] Introduction:[/B] Throughout my career, I've worked on several projects focused on creating a suite of libraries to streamline the development of Habbo retro applications. Along the way, I've accumulated invaluable insights and started contemplating the future of retro architecture—specifically, how to resolve persistent issues from the past. Initially, retros were developed with the straightforward goal of reverse-engineering Habbo. Developers didn't fully consider the long-term implications or how to make these projects scalable. As a result, hundreds of emulators have been built, with only a few gaining significant community traction. Most, however, suffer from the same core problem: monolithic architecture. MMOs, such as Habbo, are designed to handle thousands, if not millions, of concurrent users. While modern retros don't necessarily aim for those numbers, the consequences of monolithic design quickly surface. The retro community remains restricted by outdated architectural decisions, with development often shaped by constraints like the revision, CMS, HTML5, app, or SWF. A well-designed emulator shouldn't be hindered by these variables. The solution is [B]distributed architecture[/B] based on microservices. With a modern stack you get a system that is scalable, resilient, and performant. [HR][/HR] [B]Project Goals:[/B] [LIST] [*]Develop a distributed architecture capable of scaling to millions of users. [*]Provide common types and libraries for both front-end and back-end. [*]Provide an external [B]GraphQL Websocket API[/B] for CMS and plugin implementations to support real-time updates. [*]Use an internal [B]Kafka[/B] messaging system for efficient microservice communication. [*]Ensure strict separation of concerns in the codebase. [*]Enable database distribution for optimal scaling. [/LIST] [HR][/HR] [B]Scope Goals:[/B] [LIST] [*]Provide the essential foundation to help you implement your preferred retro revision [*]Accomplish this without dictating how users connect or interact with the system. [*]Scale Up will provide its events and API calls, which can be integrated into your business logic or packet structure. [*]Offer a full implementation example using Nitro. [/LIST] [B]Tech Stack:[/B] [LIST] [*][B]Golang[/B]: High-performance, efficient language for building scalable microservices. [*][B]Kafka[/B]: Distributed messaging system for reliable, asynchronous communication between services. [*][B]Protobuff[/B]: Lightweight and efficient serialization format for structured data transmission. [*][B]Postgres[/B]: Robust, relational database for storing structured data and ensuring ACID compliance. [*][B]MongoDB[/B]: NoSQL database for flexible, unstructured or semi-structured data storage. [*][B]Redis[/B]: In-memory data structure store used for caching and real-time performance. [*][B]GraphQL[/B]: Query language for APIs, enabling flexible and efficient client-server interactions. [*][B]WebSockets[/B]: Protocol for real-time, bi-directional communication, critical for live updates. [/LIST] [B]Architecture:[/B] [LIST] [*][B]Internal-Facing Services[/B]: All microservices are designed to be internal, with no direct external API exposure. [*][B]Backend for Frontend (BFF)[/B]: External interactions, whether from the CMS or the game client, are routed through a BFF layer. This isolates the core services and optimizes interactions tailored specifically for client needs, ensuring security and performance. [/LIST] [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Server Development
Habbo Retros
Habbo Development
Envy ~ Distributed Habbo Retros
Top