Dashboard service: with mechanism for notification of new saves

[nikochiko]

It should have two endpoints:

• A webhook that should be hit when a file is saved
  • Data should have:
    • which user performed the save
    • the filesystem path of the notebook
  • The service will then figure out how to use this information
• An endpoint that will return which notebook was the last to be saved and when.
  • This can be polled to figure out if there has been a new change.

Webhook:

> POST /events/save
> {
>    "user": "alice",
>    "path": "/home/alice/module1-day1.ipynb",
> }
>
...
< 200 OK

Polling endpoint:

> GET /events/save/module1-day1  # /events/save/{path/to/file/after/home} ?
>
...
< 200 OK
< {
<     "timestamp": "2022-11-14T06:19:03Z",
<     "user": "alice"
< }

Jupyterhub services reference: https://jupyterhub.readthedocs.io/en/stable/reference/services.html

[anandology]

Here is my suggestion for the API:

Create event:

POST /events

{
    "type": "save-notebook",
    "user": "alice",
    "filename": "module1-day1.ipynb"
    "path": "/home/alice/module1-day1.ipynb"
    "timestamp": "...""
}
---
200 OK / 201 Created

{
    "id": 4,
    "type": "save-notebook",
    "user": "alice",
    "filename": "module1-day1.ipynb"
    "path": "/home/alice/module1-day1.ipynb"
    "timestamp": "...""
}

List events:

GET /events
---
200 OK

[
  {
    "id": 4,
    "type": "save-notebook",
    "user": "alice",
    "filename": "module1-day1.ipynb"
    "path": "/home/alice/module1-day1.ipynb"
    "timestamp": "...""
  },
  ...
]

Listing events may also support filtering.

GET /events?user=alice
GET /events?user=alice&filename=day1.ipynb
GET /events?filename=day1.ipynb

[nikochiko]

What would filename be for /day1/module1.ipynb vs /day2/module1.ipynb, for example?

[nikochiko]

Would GET events also support order by and limit operations?

[nikochiko]

I don't think we should persist all events. It would add complexity without having a use case for us.
Maybe we could set a key from the client, and the server would update an item if the given key already exists.
So,

POST /events
{
    "type": "save-notebook",
    "key": {
        "user": "alice",
        "path": "/home/alice/module1-day1.ipynb"
     },
     "data": {
        "user": "alice",
        "path": "/home/alice/module1-day1.ipynb",
        "timestamp": "..."
        "filename": "module1-day1.ipynb"
      }
}
--- 
200 OK / 201 Created
{
    "id": ...,
    "type": ...,
    "key": ...,
    "data": ...,
}

Querying could be same as suggested.

What do you think?

[anandology]

Filename is the relative path from homedir. Path is already the unique key. Let's keep it simple and flat. Remember, the important part is the integration, not the api.

…

On Mon, Nov 14, 2022, 2:03 PM Kaustubh Maske Patil ***@***.***> wrote: I don't think we should make it a complete event logging solution. It would add complexity without having a use case for us. Maybe we could model it like creating a key on the frontend with user + path, and the server would update an item if the given key already exists. So, POST /events { "type": "save-notebook", "key": { "user": "alice", "path": "/home/alice/module1-day1.ipynb" }, "data"': { "user": "alice", "path": "/home/alice/module1-day1.ipynb", "timestamp": "..." "filename": "module1-day1.ipynb" } } --- 200 OK / 201 Created { "id": ..., "type": ..., "key": ..., "data": ..., } Querying could be same suggested. What do you think? — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAB3ELGZ64SP5AGIC4GXBLWIH2N7ANCNFSM6AAAAAAR7PPLME> . You are receiving this because you commented.Message ID: ***@***.***>

[nikochiko]

Added in this commit: 8c559c2
It uses just a list for now but we can make it a database later.