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: 477470" data-attributes="member: 21320"><p>1. <strong>Skill Transition</strong>: There shouldn't be too much of a difficulty assuming the developers are competent and can follow documentation or understand libraries. Every service I create will expose an internal API with a client lib for other services to use when connecting to it. This allows their interaction to remain type protected and type documented so it's easy for developers to know what they can interact with</p><p></p><p>2. <strong>Testing & Debugging</strong>: Tools may be developed as I develop this out. My primary goal for local development is using pm2 for running all apps/services locally and restarting as needed. Long term, I hope to have hot reload capability on the backend services. The frontend is already hot reload capable including library integrations.</p><p></p><p>3. <strong>Inter-service Communication</strong>: Assuming the infrastructure is correct in production and all services are on a private network with exposure only where necessary and behind a proxy or gateway - latency should be fairly low and you can setup services to be geolocated in addition. NATS has queue groups allowing for events to be processed once and by a single subscriber. I may also add Kafka for the actual event streams. NATS is primarily for request->response on the internal communication. Locally, I haven't had any issues with latency and it performs similar to monoliths even with 3+ service calls chained</p><p></p><p>4. <strong>Database Management: </strong>Every service is directly responsible for it's own data and will use ids for interacting with other services. With this approach, services are simpler and easier to manage. Their databases don't reference external properties aside from a name and key. Feature services will be used for situations where multiple services are chained together and will be responsible for managing the data and ensuring it's success at each step. Databases are setup to be completely independent of one another and have no connections to each other. I use Postgres as well which provides <a href="https://www.postgresql.org/docs/8.1/mvcc.html" target="_blank">concurrency control</a></p><p></p><p>5. . <strong>Infrastructure Cost: </strong>Hotels can run this on a single server or hundreds of servers. Hotels would scale their cost to their demand but overall it should use lower resources than a typical setup by being able to fine tune where demand comes from.</p><p></p><p>6. <strong>Security</strong>: Services have multiple layers of APIs. Internal APIs should never be exposed on a port and are expected to be ran behind an internal network only. There is no inherit security outside the internal network, although I may add authentication keys for internal APIs in the future. External APIs have full authentication and authorization protections and can be scoped to the feature level. Currently, I use JWT bearer tokens for external APIs and have additional checks by the session service.</p><p></p><p>7. <strong>Project Release: </strong>If people could contribute to this project, they would have made their own version. The earliest time at which the source would be shared is when I believe it's capable of reproducing the core retro features.</p><p></p><p>I haven't worked on this much in the past few weeks - but the core of the project has been built out including everything I described above outside the retro implementation.</p></blockquote><p></p>
[QUOTE="Leader, post: 477470, member: 21320"] 1. [B]Skill Transition[/B]: There shouldn't be too much of a difficulty assuming the developers are competent and can follow documentation or understand libraries. Every service I create will expose an internal API with a client lib for other services to use when connecting to it. This allows their interaction to remain type protected and type documented so it's easy for developers to know what they can interact with 2. [B]Testing & Debugging[/B]: Tools may be developed as I develop this out. My primary goal for local development is using pm2 for running all apps/services locally and restarting as needed. Long term, I hope to have hot reload capability on the backend services. The frontend is already hot reload capable including library integrations. 3. [B]Inter-service Communication[/B]: Assuming the infrastructure is correct in production and all services are on a private network with exposure only where necessary and behind a proxy or gateway - latency should be fairly low and you can setup services to be geolocated in addition. NATS has queue groups allowing for events to be processed once and by a single subscriber. I may also add Kafka for the actual event streams. NATS is primarily for request->response on the internal communication. Locally, I haven't had any issues with latency and it performs similar to monoliths even with 3+ service calls chained 4. [B]Database Management: [/B]Every service is directly responsible for it's own data and will use ids for interacting with other services. With this approach, services are simpler and easier to manage. Their databases don't reference external properties aside from a name and key. Feature services will be used for situations where multiple services are chained together and will be responsible for managing the data and ensuring it's success at each step. Databases are setup to be completely independent of one another and have no connections to each other. I use Postgres as well which provides [URL='https://www.postgresql.org/docs/8.1/mvcc.html']concurrency control[/URL] 5. . [B]Infrastructure Cost: [/B]Hotels can run this on a single server or hundreds of servers. Hotels would scale their cost to their demand but overall it should use lower resources than a typical setup by being able to fine tune where demand comes from. 6. [B]Security[/B]: Services have multiple layers of APIs. Internal APIs should never be exposed on a port and are expected to be ran behind an internal network only. There is no inherit security outside the internal network, although I may add authentication keys for internal APIs in the future. External APIs have full authentication and authorization protections and can be scoped to the feature level. Currently, I use JWT bearer tokens for external APIs and have additional checks by the session service. 7. [B]Project Release: [/B]If people could contribute to this project, they would have made their own version. The earliest time at which the source would be shared is when I believe it's capable of reproducing the core retro features. I haven't worked on this much in the past few weeks - but the core of the project has been built out including everything I described above outside the retro implementation. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Server Development
Habbo Retros
Habbo Development
Envy ~ Distributed Habbo Retros
Top