I was learning about binderhub's API and found that the binderhub/ folder contained very many .py files, making reading the source code unessecary complicated. I suggest a refactoring like in jupyterhub/jupyterhub, where there is a handlers/ folder.
As a further refactoring point, I consider it could make sense to split class definitions to their own files, but this issue just represents having a handlers/ folder.
Handlers
In practice we have the following code files defining Tornado web request handlers that I think should be moved to a dedicated handlers folder: main.py, builder.py, base.py, metrics.py, config.py. Searching for imports from .main etc indicates that only other handler files reference .base and only app.py reference the handlers.
If needed to ensure backward compatebility if other packages are directly referencing handlers, we can update binderhub/__init__.py to import the handlers I think.
GET, loading.html and bundle.js, calls /build and redirects to the started user server. With this, users can launch directly without pressing a launch button.
GET, REST API, emits JSON with repo providers configuration. Used by index.js to update the DOM dynamically using JQuery. The DOM updated is the input fields and labels for "repository" and "ref" in index.html. Introduced in https://github.com/jupyterhub/binderhub/pull/1038.
I was learning about binderhub's API and found that the
binderhub/folder contained very many .py files, making reading the source code unessecary complicated. I suggest a refactoring like in jupyterhub/jupyterhub, where there is ahandlers/folder.As a further refactoring point, I consider it could make sense to split class definitions to their own files, but this issue just represents having a
handlers/folder.Handlers
In practice we have the following code files defining Tornado web request handlers that I think should be moved to a dedicated handlers folder:
main.py,builder.py,base.py,metrics.py,config.py. Searching for importsfrom .mainetc indicates that only other handler files reference.baseand onlyapp.pyreference the handlers.If needed to ensure backward compatebility if other packages are directly referencing handlers, we can update
binderhub/__init__.pyto import the handlers I think.main.pyMainHandler -
/GET, index.html and bundle.js, calls /build and redirects to the started user server
ParameterizedMainHandler -
/v2/([^/]+)/(.+)GET, loading.html and bundle.js, calls /build and redirects to the started user server. With this, users can launch directly without pressing a launch button.
LegacyRedirectHandler -
/repo/([^/]+)/([^/]+)(/.*)?GET, redirects to /v2/..., so its in practice /v1/
builder.pyBuildHandler -
/build/([^/]+)/(.+)GET, REST API, streams JSON messages about build and launch progress.
base.pyAboutHandler -
/aboutGET, about.html, provides basic information
VersionHandler -
/versionsGET, REST API, emits JSON about versions for "builder" and "binderhub"
metrics.pyMetricsHandler -
/metricsGET, emits metrics for Prometheus to scrape
health.pyHealthHandler -
/healthGET and HEAD, REST API, emits JSON about deployment health status under keys "ok" and "checks"
config.pyConfigHandler -
/_configGET, REST API, emits JSON with repo providers configuration. Used by index.js to update the DOM dynamically using JQuery. The DOM updated is the input fields and labels for "repository" and "ref" in index.html. Introduced in https://github.com/jupyterhub/binderhub/pull/1038.