Closed phwizard closed 1 year ago
After this is updated on the server-side, we will implement this Apps list view update, and after this we will implement the detailed stats interface.
Detailed Stats interface will be opened via Stats icon on the right.
It will be similar to how it was before (below) in the previous version, but the stats will be:
Головні нюанси
Transactions doesn't work in MongoDB on single (same instance) set up. Will likely have to move to a cluster MongoDB with a replica set.
Updated - added "Files"
this is done for the main dashboard screen, thank you!
@dendidibe just add the decimals coma sign, so instead of '12001' we show '12,001'
and next step is implement the detailed view
done. thanks @dendidibe
As discussed earlier, please update / implement the stats logic so that we can track the following statistics:
Users registrations
with App attribution and timestamps.
From the architecture and high-load point of view, it is likely going to be better if Stats for the core/API app is implemented as a separate service. I.e. it writes into its own separate DB (could be MongoDB but a column-based NoSQL DB such as Cassandra may be a faster working choice here) and its API also works as a separate application so it: 1) Doesn't affect the performance of the main core API/app 2) Can be moved to a separate server instance when needed. 3) In future can have its own performance optimizations such for example as pre-calculation and caching of popular requests at DB level such as daily stats, monthly stats etc.
The above (implementing it as a separate service with its own DB) is a recommendation but is not critical at this stage.
Also note that we will likely need future developments around this service that are important for the platform. I.e. 1) Daily stats e-mail feature - our Customers (app owners) will receive an e-mail every 24h showing them how many Users, API calls, Chats, Push notifications etc have been generated by their apps over last 24h, and similarly we can do a monthly summary e-mail. 2) Billing and Throttling - Stats service may be used by the core application to check whether the Customer (app owner) has a right to consume this much resources during this month, according to the Plan they are on (or alternatively to bill them Platform Tokens on a pay-as-you-go basis).
Currently we need an implementation that allows in our Apps UI to display the vital stats like this over the last 24h:
and also detailed stats with graphs / diagrams of usage over Hour, Day, Month for any specific Application and any specific Metric.