Leader
github.com/habbo-hotel
- Aug 24, 2012
- 1,007
- 267
Envy
Introduction:
In the past, I have worked on numerous projects with the goal of creating a suite of libraries for rapidly developing Habbo applications. During this time, I have gained invaluable knowledge and started to consider the future of retro architecture and how to solve past issues.
Retros were initially developed with the simple goal of reverse-engineering Habbo. Developers didn't consider the implications of what they were building, nor did they think about how these projects would scale over the long term. As a result, hundreds of emulators have been created over the years, with only a few dozen gaining significant community traction. Ultimately, all of these emulators were plagued by the same underlying issue: monolithic architecture. Retros were meant to emulate MMOs, which can support thousands if not millions of concurrent players. While these numbers are mostly unattainable now, the consequences of a monolithic architecture will always become apparent. Our community has been unable to expand emulators much, and we often make decisions based on factors like the revision, CMS, HTML5, app or SWF. If an emulator were built correctly, these things wouldn't matter.
The answer is distributed architecture based on microservices. Paired with TypeScript, you get a stack that developers can maintain and only need to know one language for. Types can be shared, code can be shared, and you'll have more flexibility to do what you really want with the project.
Project Goals:
Tech Stack:
NodeJS - TypeScript - NestJS - React - Postgres - HTTP2
NATS - REDIS - Bull - Vite - Turbopack - NX - PM2
What This Project Is Not:
This project is not a typical emulator. The goal is not to reproduce the exact events or structures 1-1 but instead to create everything from scratch with my own API and events.
This project is not required to run distributed. Internal testing will be done on a monorepo with PM2 managing the processes and with a single database with separate schemas.
However, if you wish to scale this, you can do so by putting the independent services on their server(s) with their respective databases and processing power. AWS is typically the best for running distributed environments that scale to demand.
This Project Sounds Over-Engineered:
It is. Everything I do is over-engineered because it's fun and the right solution if you look far enough ahead.
Source Code:
This project will not be released for the foreseeable future. Updates will be shared on this thread. This project will be released when it's stable and iterative.
Introduction:
In the past, I have worked on numerous projects with the goal of creating a suite of libraries for rapidly developing Habbo applications. During this time, I have gained invaluable knowledge and started to consider the future of retro architecture and how to solve past issues.
Retros were initially developed with the simple goal of reverse-engineering Habbo. Developers didn't consider the implications of what they were building, nor did they think about how these projects would scale over the long term. As a result, hundreds of emulators have been created over the years, with only a few dozen gaining significant community traction. Ultimately, all of these emulators were plagued by the same underlying issue: monolithic architecture. Retros were meant to emulate MMOs, which can support thousands if not millions of concurrent players. While these numbers are mostly unattainable now, the consequences of a monolithic architecture will always become apparent. Our community has been unable to expand emulators much, and we often make decisions based on factors like the revision, CMS, HTML5, app or SWF. If an emulator were built correctly, these things wouldn't matter.
The answer is distributed architecture based on microservices. Paired with TypeScript, you get a stack that developers can maintain and only need to know one language for. Types can be shared, code can be shared, and you'll have more flexibility to do what you really want with the project.
Project Goals:
- Provide a distributed architecture that can scale to millions of users
- Provide common types and libraries for the FE and BE
- Provide an external GraphQL API for CMS implementations over HTTP2
- Provide an external WebSocket API for CMS and Plugin implementations to receive real-time updates
- Provide an internal NATS API for microservice communication
- Ensure all code follows true separation of concerns
- Ensure the database can be distributed
- Provide the minimum necessary to start creating your implementation for your preferred revision and connection type (e.g., Nitro, Flashplayer, Shockwave)
- Accomplish the above without making opinionated decisions on how the end-user connects or interacts
- Scale Up will provide its events and API calls that you can implement into your business logic associated with a packet structure or WebSocket events
- Provide an example using Nitro
Tech Stack:
NodeJS - TypeScript - NestJS - React - Postgres - HTTP2
NATS - REDIS - Bull - Vite - Turbopack - NX - PM2
What This Project Is Not:
This project is not a typical emulator. The goal is not to reproduce the exact events or structures 1-1 but instead to create everything from scratch with my own API and events.
This project is not required to run distributed. Internal testing will be done on a monorepo with PM2 managing the processes and with a single database with separate schemas.
However, if you wish to scale this, you can do so by putting the independent services on their server(s) with their respective databases and processing power. AWS is typically the best for running distributed environments that scale to demand.
This Project Sounds Over-Engineered:
It is. Everything I do is over-engineered because it's fun and the right solution if you look far enough ahead.
Source Code:
This project will not be released for the foreseeable future. Updates will be shared on this thread. This project will be released when it's stable and iterative.
You must be registered for see links
Last edited: