Game Plan

[rye]

Here's what we want?

• An API server (data_server) accepting the following routes: In a very strong way, these routes and operations actually mirror Git very well. A suggestion can be thought of as a commit on a branch, with each "change" being a commit... But there's some additional metadata to collect.

  • GET /ping [-auth] (basic deadness check) (Rocket #5)
  • GET /healthz [-auth] (healthiness check) (Healthz #22)
  • GET /statusz [-auth] (status check)
  • GET /varz [+auth] (metrics check)
  • GET /<data path> [~auth] (data fetch, to be used by ccc)
  • GET /suggestions [+auth] (get suggestions, filtered)
  • POST /suggestions [~auth] (create a suggestion)
  • GET /changes [+auth] (get all changes)
  • GET /suggestion/<id> [+auth] (get contents of suggestion)
  • GET /suggestion/<id>/changes [~auth] (get body of suggestion)
  • GET /changes/<id> [~auth] (changes)

• A frontend (React, SPA in web browser land, github app/GH pages?)

Am I missing anything?

[hawkrives]

I wonder if we want to namespace some of those (suggestions, changes, maybe others) under the "data path" namespace?

[rye]

My thought was that a suggestion is an analog to a branch, a change is an analog to a commit. Each suggested file change gets its own commit.

I'm actually almost tempted to make this just a web front-end for a Git repository, if that makes sense? I mean, using the same terminology. Clients would POST to a /blob endpoint? And a /tree endpoint, and a /commit endpoint? The point of abstracting it away was so that we could flatten it out and make less requests required, but… I could see this server taking a bare-Git-y approach and then having ccc or another server do the extra thinking what with users, authentication, and handling wrapped requests. Each of these endpoints should authenticate with a rate-limited token.

Completely open to thoughts.