Create API endpoints that return leaderboards

[yk]

The frontends will want to display leaderboards. The backend needs to be able to compute these, and should expose API endpoints for the frontends to request their data.

Leaderboards can be made for multiple things: Global leaderboards, time-based (weekly,daily,...), task-based (being the assistant, making prompts, ...), and others. The API endpoints should have the flexibility to allow for this and the backend implementation should start with one or two basic ones (e.g. global and daily).

[jasonmhead]

This task perhaps needs expanded and split out with some feature goals and I could help design and document the API endpoints.

At a higher level it could be good to use the OpenAPI standard and use tools like https://openapi-generator.tech/

Edit: Would the "High-Level Protocol Architecture" document provide enough information to design the endpoints?

[yk]

Yes, I absolutely agree, we should probably split this up. So I guess this issue could mainly track the discussion around what endpoints are even needed.

At a higher level it could be good to use the OpenAPI standard and use tools like https://openapi-generator.tech/

I believe the framework we use, fastAPI, already generates OpenAPI-compatible endpoints and their specs by default (i.e. https://fastapi.tiangolo.com/tutorial/metadata/#openapi-url)

Would the "High-Level Protocol Architecture" document provide enough information to design the endpoints?

No, for the leaderboards, that's not enough. The protocol only defines the main interaction between frontend and backend with respect to the tasks to be fulfilled, but says nothing about leaderboards. That will have to be an entirely different set of (generic) endpoints.

[danielpatrickhug]

Hi @yk, I was wondering if you had any thoughts on the scheduling aspect. I was thinking of the backend implementation. Potentially, Celery could be used for scheduling and updating the person_stats table for the leaderboard endpoint.

[yk]

Hi @yk, I was wondering if you had any thoughts on the scheduling aspect. I was thinking of the backend implementation. Potentially, Celery could be used for scheduling and updating the person_stats table for the leaderboard endpoint.

I think initially, we can get away with just running a SQL query to compute the stats on the fly. In the future I think it makes sense to use some scheduling system like celery.

[yeungadrian]

Hi @yk , I'd like to take this up. Here's some thoughts / question on an initial implementation:

• New Router: Called leaderboards (or could put it under the current stats)
• Initial Proof of Concept endpoints: (one endpoint per stat), copying the phrasing I'm seeing in the UI
  • GET /api/v1/leaderboards/user/{timespan}
  • GET /api/v1/leaderboards/assistant/{timespan}
  • timespan is an enum of (Global, Daily) (expand to others in the future )
• SQL queries to extract top n users and their no. of prompts / rankings (calculate on the fly)
  • Add new functions into PromptRepository, Function per type of leaderboard
    • fetch_user_leaderboard( timespan, n) (n - top n users)
    • fetch_assisstant_leaderboard( timespan, n)
  • In terms of the calculating scores for creating replies as user / assisstants , is it just a groupby aggregate of the message table, filtering where deleted is false?

[yk]

Hey @yeungadrian thank you so much, the plan looks very nice! I've assigned you. Probably @andreaskoepf is the best person to advise you on the questions. I think initially, you can just choose some simple calculation, we'll make that more refined soon, as we introduce a points system etc. so don't worry too much about the exact calculation now.