|
5 | 5 | ## Agile Process
|
6 | 6 | The Agile process used here is very simple as there is only one developer, it shouldn't be complicated at all.
|
7 | 7 |
|
8 |
| -This has been done simply using Clickup as the board management tool: |
9 |
| -- The Challange itself has been separated into mini-tasks. |
| 8 | +This has been done simply using ClickUp as the board management tool: |
| 9 | +- The Challenge itself has been separated into mini-tasks. |
10 | 10 | - Each task has simply 3 statuses (TODO, In Progress, Completed), acceptance criteria, time-estimation and due-date, also comments if needed.
|
11 |
| -- The tasks hasn't been written as a user-stories, it was much simpler and better to be segregatted as a technical-based stories that fits with the challenge target. |
| 11 | +- The tasks hasn't been written as a user-stories, it was much simpler and better to be segregated as a technical-based stories that fits with the challenge target. |
12 | 12 |
|
13 | 13 | If you are interested, you can check the board's **[List view](https://sharing.clickup.com/42008161/l/h/6-222229294-1/ef602d4c6f6412b)**, it also has a **[Gantt-Chart view](https://sharing.clickup.com/42008161/g/h/181zk1-20/6ed8fc490596066)**.
|
14 | 14 |
|
15 |
| - |
| 15 | + |
16 | 16 | ## Covered points
|
17 | 17 | ## Documentation
|
18 | 18 | ### API Documentation
|
@@ -62,5 +62,39 @@ As you can see it's very simple and serves the requirement given but there is 2
|
62 | 62 |
|
63 | 63 | The reason why I have ignored using JWT was that I tried to make it simple and the application table read/writes operations is not the main hassle and additional read for the current scale is fair enough.
|
64 | 64 |
|
| 65 | +#### Chats and Messages counts per Applications and Chats tables records |
| 66 | +The requirements here was simply to have chats_count and messages_counts aggregated in each record and they can't be live but should be updated every hour at most. |
| 67 | + |
| 68 | +So I decided to use scheduled Cron jobs to run background tasks every ```0 * * * *``` corn-ly using **Sidekiq** and **Sidekiq-Cron**. Also I have mounted their portals which can be accessed after running the rails server at `localhost:3000/sidekiq` and `localhost:3000/sidekiq/cron`. |
| 69 | + |
| 70 | + |
| 71 | +The jobs configuration was simple with 3 reties and without timeout handling for now. |
| 72 | +Both the jobs simply call custom queries I have made to do the aggregation, I thought it's better for them to stay in the ActiveRecord models to keep it smart and consistent. |
| 73 | + |
| 74 | +The queries are as follows: |
| 75 | +```ruby |
| 76 | +class Application < ApplicationRecord |
| 77 | + # ... The remainder of the code ... |
| 78 | + def self.aggregate_chats_count |
| 79 | + self.connection.execute( |
| 80 | + 'UPDATE applications apps |
| 81 | + JOIN(SELECT application_id, COUNT(application_id) as aggregation |
| 82 | + FROM chats |
| 83 | + GROUP BY application_id) c ON apps.id = c.application_id |
| 84 | + SET apps.chats_count = c.aggregation;' |
| 85 | + ) |
| 86 | + end |
| 87 | +end |
| 88 | +``` |
| 89 | + |
| 90 | +```ruby |
| 91 | +# To be documented later |
| 92 | +``` |
| 93 | + |
| 94 | +There are a lot of notes that I like to share here: |
| 95 | +- I could actually found any ActiveRecord-based query to implement it, so here comes the custom queries. |
| 96 | +- I am new with MySQL ```Explain``` **-but familiar with other engines' execution plans results-** but I have run it and I didn't find anything bad from my perspective. |
| 97 | +- There might be a DBMS-based approach but I choose to use **Sidekiq** specifically to deal more with the async background tasks. |
| 98 | +- No major need here for 3rd party Pub-Sub services such as Kafka or RabbitMQ. |
65 | 99 |
|
66 | 100 | ### Git-flow used
|
0 commit comments