feat: hot server reload & debugging over docker

[BlairCurrey]

Changes proposed in this pull request

• adds hot sever reload on save to auth/backend docker services
• exposes debugger with instructions on how to use in most development-environment-agnostic way

Context

fixes #2650 fixes #2672

Checklist

• [x] Related issues linked using fixes #number
• [ ] Tests added/updated
• [x] Documentation added
• [x] Make sure that all checks pass
• [ ] Bruno collection updated

[netlify[bot]]

✅ Deploy Preview for brilliant-pasca-3e80ec canceled.

Name	Link
🔨 Latest commit	38ad16e880b7ce8abf972ba0f39d0ac1e20d637b
🔍 Latest deploy log	https://app.netlify.com/sites/brilliant-pasca-3e80ec/deploys/664b5f2290bd0a0008f776e1

[BlairCurrey]

It's not a factor in these changes, but I noticed we have docker-compose in our services, like rafiki/packages/backend/docker-compose.yml. Why?

As far as I can tell they are unused. Do we need them? Should I get rid of them?

[BlairCurrey]

I considered adding a CI step for checking that frontend starts OK with the production image. This is not trivial to setup since frontend depends on quite a few things (kratos, backend db, etc.). It would also be completely redundant if we add any sort of frontend e2e test as part of this issue, so I figured we could defer to that: https://github.com/interledger/rafiki/issues/2627

[mkurapov]

using ts-node instead of explicit build step. Never really liked the idea but its the more common use-case with nodemon. Tried it briefly but ran into some typescript errors and didn't pursue it further.

@BlairCurrey curious to hear your thoughts on debugging the complied JS files or the TS files directly.

I tried using ts-node-dev in this commit, and it ended up working quite well with the following VS code launch.json for debugging cloud-nine-backend (with the remote root pointing to the volume you expose):

    {
      "name": "Attach to docker (cloud-nine-backend)",
      "type": "node",
      "request": "attach",
      "port": 9229,
      "address": "localhost",
      "localRoot": "${workspaceFolder}",
      "remoteRoot": "/home/rafiki/",
      "restart": true
    },

Let me know what feels better/what issues you had when trying TS, but it was quite nice debugging the files we end up writing.

[BlairCurrey]

using ts-node instead of explicit build step. Never really liked the idea but its the more common use-case with nodemon. Tried it briefly but ran into some typescript errors and didn't pursue it further.

@BlairCurrey curious to hear your thoughts on debugging the complied JS files or the TS files directly.

I tried using ts-node-dev in this commit, and it ended up working quite well with the following VS code launch.json for debugging cloud-nine-backend (with the remote root pointing to the volume you expose):

    {
      "name": "Attach to docker (cloud-nine-backend)",
      "type": "node",
      "request": "attach",
      "port": 9229,
      "address": "localhost",
      "localRoot": "${workspaceFolder}",
      "remoteRoot": "/home/rafiki/",
      "restart": true
    },

Let me know what feels better/what issues you had when trying TS, but it was quite nice debugging the files we end up writing.

Thanks for sharing this - seems promising. I like that we dont have to copy files every change (since they arent being wiped out by building).