CSGO is an FPS game that has a lot of items you can get with drops, unboxing, or trading.

The items don’t give you any form of advantage in the game, it is only cosmetic and like a status for having the most “good-looking” and expensive items. For example, an AK-47 skin is still the default AK-47 mechanically speaking, but the skin can make it look in a ton of different ways. Items (skins) can be for weapons, knifes, gloves, stickers to put on the weapons and so on. Some skins are very rare and can have an insane price in real fiat currency (pun intended).

So, our project CSGO BANK will be a secure vault, like an inventory if you will, to store your items and operate transactions of these items to other users.

• You will find OpenApi endpoint-documentation in /csGoBankOpenAPIDoc.

We have a docker-compose that runs local images, and one that uses images from dockerhub.

First time creating the containers the mysql container my take too long with the init.sql and the other services will fail at startup. This is only an issue when starting the compose-file for the first time

We used the build-image plugin from spring-boot with maven from intellij GUI for all our services. Frontend:

cd frontendSvelte
docker build -t frontend:1.0 . 

consul-importer:

cd docker\consul
docker build -t consul-importer:1.0 .

In every service (Vault, Item, TransactionHistory, TransactionValidator, Gateway, account and logs)

mvn spring-boot:build-image

• Zipkin: http://localhost:9411
• RabbitMQ: http://localhost:15672
• Consul: http://localhost:8500
• Frontend: http://localhost:8888
• Gateway: http://localhost:8000

The account service is where all account related stuff happens (update, create, delete, etc). In this service is where login would most likely be if not in its own service. Event on account creation and deletion is sent to RabbitMQ

The item service is a small service with the intention to act like an intermediary for the official API for items in CS:GO. This service only has a few Get endpoints for items. If we had time, the official API would be used instead of a local DB of items.

The vault service is the "main" service. The vault itself is the main part of the program, so most services have communication ASYNC and SYNC with the vault service. Everything to do with vault happens here, creating transaction, transferring items Takes in accepted transactions from RabbitMQ and does the transferring of items and send out a transaction-complete event

The transaction validator service has the single role of validating transactions. It makes sure the transaction is correct and both items and credits are present before accepting any transactions. Simple transfer is SYNC communication with Vault. Transaction needing a response from the recipient is taken in trough RabbitMQ, it listens to transaction-created event and sends out transaction accepted/declined events on completion

Transaction history service is a simple service, listens for transaction-complete events and put them in a database. With endpoints to access them

Takes in all logs from rabbitMQ and displays them on screen

• As a user I want to
  • Create an account
  • Login/Choose account
    • Create different vault
    • Choose vault
      • Deposit skins to vault.
      • Withdraw skins from vault.
      • Transfer skins between vaults (mine and other accounts).
      • Create a trade offer, either buying or selling an item
        • Accept/Decline pending offers.
  • Display vault
    • Display items
    • Display info on skins.
    • Check the price of skin.
    • Display total value of vault.
    • Click on skin to display price history.
    • Display transaction history on an item.

We both worked on everything more or less together, so we both had influence on what got done. But we did divide the responsibility on the logic of services. The infrastructure (logging, tracing, gateway etc.) we both did at the same time and no clear division, both worked on one computer most of the time. All decisions were made with the explicit agreement from both parties

Item service should be a "faked" API from valve (Owners of the game CS:GO). If we had time, we would implement an API call to get real item data live.

We wanted to focus on our application itself, since deposit items and credits would require outside confirmation, bank transaction for credits, etc. we chose to implement a basic version of these that don't take any confirmation from the outside.

Services:

• TransactionValidator
• TransactionHistory
• Transaction part of vault service

The Transaction "logic"

Services:

• Account
• Item
• Item and account part of Vault service
• Frontend

• Use multiple services, that fulfill different functionality and communicate with each other

• At least two of the services communicate using synchronous communication (for example, direct REST calls between two services).
• At least two of the services communicate using asynchronous communication (for example, using Message Queue). This will be done in accordance with event-driven architecture, as discussed in class.

• The project uses a unique access point, that handled calls and routes them to appropriate services – Gateway
• The project uses a unique access point that, in addition to routing calls, also does load balancing

• The project has a means of centrally controlling the health of running services – health check
• The project has a means of centrally controlling configurations for the services – for example, using Consul

• The project has a means of containerization – building container images from the existing services and getting such containers running and interacting with each other

• docker run --name vault_db -e MYSQL_ROOT_PASSWORD=Marengs -p 3306:3306 -d mysql:latest

• consul agent -node=learnmicro -dev

• docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3.12-management

• docker run -d -p 9411:9411 openzipkin/zipkin

• docker build -t consul-importer:1.0 .

• Login
  • docker login
• Change tag :
  • docker image tag gateway:0.0.1-SNAPSHOT rikatob/gateway:0.0.1-SNAPSHOT
• Push that image:
  • docker image push rikatob/gateway:0.0.1-SNAPSHOT

• Prettify report with drawings and decisions about RabbitMQ.
• Update report with process regarding:
  • Gateway
  • Centralised logg
  • Docker
• Create a "module" diagram of our planned project structure.

• Vault publisher to transaction history.

• Restructure project package structure.

• Float problems with int cant be feks 0233 that indicates 0,0233. The Total value in vault should not be field but a method. Should it be in Vault or service?

• TODO's.

  • VaultController.
  • VaultService.
  • Change from layour to encoder logback. (https://logback.qos.ch/codes.html#layoutInsteadOfEncoder)
  • Use health checks to avoid that some services start before a service it is dependent on an/or spamming repuest ?
    • https://devops.stackexchange.com/questions/12092/docker-compose-healthcheck-for-rabbitmq?newreg=614274132fbc4f92a92ba80f6d758a76
    • https://www.rabbitmq.com/monitoring.html#health-checks
  • Frontend running on own server.

• Gateway
  • Service Discovery
    • Spring-cloud-starter-consul-discovery (Discovery server)
    • Spring-boot-starter-actuator (Health check)
  • Load Balancer.
    • Spring-cloud-load-balancer
  • Routing.
    • Spring-cloud-starter-gateway
• Centralized Configuration.
  • Consul config server. ( bootstrap.yml)

• Make account, transactionhistory and vault use flyway.
• Populate databases
• Withdraw item
• Total value in vault.
• Deposit check, cant be deposit if yet in vault_item_db
• Total value in vault should not be static, prob not i database at all and only with getter.
• Add more logging.
• Create scratchfile with all endpoints and description.
• FRONTEND
• ACCOUNT -> VAULT -> ITEM
  • List all accounts
  • Create new account.
  • Delete account.
  • Account
    • List all vaults for account.
    • Create new vault.
    • Delete Vault.
  • Vault
    • List items.
    • Withdraw item.
    • Deposit item.
  • Item
    • Transfer item.
    • Transaction history on item.

• Account
  • Email osv (Bruker profile)
• Create new vault
• Withdraw
• Deposit skins
• Transfer
• Validate transaction
• List Items (get vault items)
• [x Update database

• Buy/Sell items
  • Item need to be sold with price
  • Account based money/credit
  • Transaction needs price
  • Create "offer" rabbitMQ
    • Vault sends offer to RabbitMQ
    • Validator validates offer, sets "offer" to pending
    • User accepts/decline pending offers
    • validator sets offer to "validated"
    • Vault listens on rabbitMQ, validated offers happens, and sends event to history with rabbit
  • Accept "offer" rabbitMQ

• Price history