Technical Architecture Overview

HOME > TECHNICAL DOCUMENTATION > TECHNICAL ARQUITECTURE OVERVIEW

ConGaLi has an architecture which consists of the following sub-systems:

Actually the architecture is in the midst of changes to go from a monolithic to a microservices architecture, change that it's explained in detail on the technical documentation, and will end up with a schema like the following:

In the rest of this page we explain our rationale for this architecture, map out the specific technical components and finally flag up the strengths and limitations of this architecture.

  Rationale

ConGaLi's distinctive architecture has been informed by a set of key design principles:

  Architecture

First and foremost, this implementation is agnostic regarding the separation with the clients, ensuring a clean separation and avoiding any opinionated issue that may arose.

The choice of the technology support was directed with main purposes such as rapid response, as-close-as-possible realtime response to the client, and lightweight footprint services. Also, the need to have a prototype as fast as possible, without debarring the team of any possibility of pursuing the aforementioned goals.

The first technologies selected for that purpose are listed on the software thanks wiki page.

  Communication

Does the README clearly and concisely explain the problem, solution, and areas for review? Are choices, remaining TODOs, and technical tradeoffs explored and explained? Was there clear communication and expectation setting with us during the process?

  Code Quality

We are using ESLint to consolidate the code base in terms of format, and practices. Also, we encourage the use of modules across the app, so we provide also a good base to mock behavior on the test tasks.

The logging criteria is something that's not completely consolidated, we have pending discussions on what should log at trace level and what will be the overhead of doing that on the code.

We do provide debug functionality based on Chrome Tools tools set.

  Functionality

Of course we are functionality driven, but without relegate the needs of the gamer and the possibility to extend the application to add new features and go even bigger :)

We had added some helpful features on that direction like:

• The possibility to select your own color for each game you join as a player.
• The possibility to kill cells.

  Security

If well it's really important to have a very good (if not flawless) security architecture, given time constraints and the scarce resources that we have right now, we have prioritized features over security at this stage of the development. Hence, we have still pending to work on:

• Logging mechanism across all the app using JWT/JWS.
• Secure logging data storage.
• Use secure protocols to communicate (being WSS or HTTPS part of the choices that we have in mind)

  Testing

There are lots of unit tests for the domain layer, and the rest of the layers. the integration tests are something that we have to work on more thoroughly as a second priority.

The priority on them is to build the integration tests to ensure we will need to change them only if we really need to, and for that we need to have the architecture more or least already done.

  Scalability

We have different matters to take into account for scalability. The main ones are memory usage and speed. The use of memory on the application is something that's took into account and we try to apply best practices across the app.

• We focus on having a lightweight on memory model.
• The thread use should be as efficient as we can.
• Each process on the server should be fast and with little to non blocking time.
• We have pending to implement a command model that will allow us to store each modification done onto each game instance, allowing us to repeat or rebuild the game in case it's the game server is broke.

  Production-readiness

We have into account the next main issues as goals to accomplish to ensure production readiness:

• We don't have monitoring facilities for the app (Although, this will change in the mid term)
• We provide a way to deal with application errors and unexpected exceptions to make the service resilient
• We provide dockerizable configurations for the app.

  Technical aspects

  Strengths

The ConGaLi approach has several technical advantages over more conventional game approaches. In no particular order, these advantages are:

• Scalable.
• Integrable with other data
• Clean separation of gaming interaction and data storage an analysis.
• Easy to modify and extend.

Limitations

The current ConGaLi architecture has some specific limitations to consider:

• Still don't have strong security measures.
• Still not proved under heavy app stress.

For more information on these limitations, please see the Technical FAQ.