Details about the design decisions and how the acceptance criteria is met is documented in the Handover to Coding Chiefs and Realtimes clickup task. Even more details on the complete development journey is documented in the subtasks of the Release: v0.0.1 - Player Overview Solution clickup milestone task.
Release: v0.0.1 - Player Overview Solution
- Setup Project, Migrate, and Cherry Pick Data for Development
- (AFK) Importing Match Stats Data
- Solutioning
- Create Denormalized Player Overview Table
- Create the Player Overview Page
- Handover to Coding Chiefs and Realtimes
Estimated time to do this: 45 minutes.
Summary of commands to execute:
Copy .env and *.csv from Coding Challenge
folder to the storage/seeders folder
./vendor/bin/sail up
docker exec -it rtn-player-overview-laravel.test-1 bash
php artisan migrate --seed
php artisan rtn-player-overview:populate-all-years
Paste in the .env file provided by Ervinne to the root directory. He should send an email with it as an attachment.
- Start up the containers:
./vendor/bin/sail up
- Bash in to the application
docker exec -it rtn-player-overview-laravel.test-1 bash
- Migrate and seed
Copy the contents of the
Coding Challenge
folder to the storage/seeders folder then run:
php artisan migrate --seed
Note that the seeding process may take about 5-10 minutes. I've set the match stats seeder to log every 10k row of data inserted to see that the thing is still running.
- Populate denormalized table used for cached data:
php artisan rtn-player-overview:populate-all-years
Populating the player overview should take about 15-20 minutes of processing.
If you inspect the database, there should be an extra table personal_access_tokens
, this is created by Laravel Sanctum. For this iteration, let's please ignore this table for now.
failed_jobs
should be retained for laravel background processes.
- Sanctum is not being used, find a way to gracefully uninstall it and prevent it from creating its own table when application is migrated
- We used sail as is without modifications. We can actually remove uneeded containers like the mail tester and selenium though I opted to keep it to play with it later on after this task.
Dockerfile may be built and deployed to AWS Container Registry or similar solution. From there, ECS or AWS App Runner may be used to run the application.
WARNING: AWS App Runner is just an ECS without a load balancer and is easier to set up. Under the hood both use EC2 so make sure you have credits in your AWS, or only deploy this with whitelisting to avoid uninteded costs. Double check the services created in AWS cloudformation to see which services are running.
I didn't actually try to deploy this as I'm out of credits right now and is running on my own credit card but it should work like how you normally deploy container based solutions.