The backend has new API endpoints for retrieving the top projects on the Utopian. This can be used for statistical or analytical purposes or for a front end to display the top projects. Other bug fixes were made as well :)
Endpoint to retrieve the top 3 projects based on number of contributions in the last week
/api/posts/top?limit=3&start_date=2017-12-1&end_date=2017-12-8
Endpoint to retrieve the top new 4 projects of the last week based on the number of contributions/rewards
/api/posts/top?limit=4&start_date=2017-12-1&end_date=2017-12-8&include_rewards=true&only_new=true
Endpoint to retrieve the top 10 contributions of the last week, based on number of rewards
/api/posts/top?limit=10&start_date=2017-12-1&end_date=2017-12-8&include_rewards=true&sort_by=rewards
limit How many top projects to receive from the APIstart_date Analyze top projects starting from this date.end_date Analyze top projects ending to this day, used in combination with start_date to form a query for retrieving top projects in a given week.include_rewards When set to true the Steem API will be queried to aggregate the rewards across the top projects.sort_by Can be set to contributions or rewards. When set to rewards then include_rewards must be set to true for this to work. The Steem API will be queried for many more posts to get an accurate projection of top projects based only on rewards.Querying the local database is easy (as seen in the first endpoint sample). The server can aggregate the data quickly in less than a second. When rewards are involved, things are much trickier. We must now query the DB on many posts. The DB backend is MongoDB and data is queried through the aggregation pipeline.
First I tried response streaming but this wasn't playing well at all, it also had the downside of needing to query the blockchain again. This was then replaced with an async model. The API server will return a status and any data it completes.
There is a caching system in place for storing these expensive results. As a result data may become stale after a certain amount of time. So the caching system is capable of expiring the stale data after a certain amount of time, allowing for fresh data to be retrieved. The caching system is smart in regards to the parameters passed in and knows whether or not it is cached based on the query parameters parameter. A weak hash (md5) creates a unique identifier of the cache data in the backend. Caching happens entirely transparently to the user. Checks are added if the data has already been paid out or not, to avoid querying the Steem API if necessary.
A rate limiting system is in place as well to prevent abuse of this endpoint, but only applies if data needs to be queried from the blockchain. The limit is tied to a Steem account to prevent circumventing the system. The date range is limited to 8 days maximum and a maximum limit of 100 projects.
A universal post updater is now in use, allowing data queried from the Steem API to update the stale data in the DB, greatly simplifying the process and reducing coupling of the previous review function.
All commits can be found at https://github.com/utopian-io/api.utopian.io/commits/master