Mf/feature/dashboard

[jbrezmorf]

No description provided.

[jbrezmorf]

General points:

• put all frontend stuff under .../dashboard/frontend
• create a docker file for full release testing and simple daplyment, something like:

# --- build frontend (builder stage) ---
FROM node:20-alpine AS web-build
WORKDIR /app/frontend
COPY frontend/package*.json ./
RUN npm ci
COPY frontend/ .
RUN npm run build              # outputs to frontend/dist

# --- backend runtime (final image) ---
FROM python:3.12-slim
WORKDIR /app
# install backend
COPY backend/pyproject.toml backend/ .
RUN pip install --no-cache-dir .
# copy static assets produced by Vite
COPY --from=web-build /app/frontend/dist /app/app/static
# run
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

[MocStepan]

Maybe I can create docker compose and deployment OCI(Containerfile), if you need it. @jbrezmorf

[jbrezmorf]

Already done in OCI.

[jbrezmorf]

Put these into .../dashboard/.gitignore

[jbrezmorf]

Merge with .../dashboard/README.md

[jbrezmorf]

Encapsulate the dashboard to its 'dashboard' folder do not use files from upper and side folders.

[jbrezmorf]

• rename keys to lowercase only
• omit keys from S3_ENDPOINT_URL bellow; these should be taken from zarr_fuse.open_store logic reading from: schema, env varaibles and passed arguments

[jbrezmorf]

Replace this class by pure functions, taking the path to the config -> produce dict of EndPointconfig objects. Avoiding env substitution logic which is part of zarr_fuse already it
is a single two line function.

[jbrezmorf]

Should be given by the endpoints config file (presence of test endpoints)

[jbrezmorf]

Remove .env injection. It leads to confusing behavior (shadowing real system variables).

[jbrezmorf]

List only direct dependencies.

[jbrezmorf]

• import at the module level
• uvicorn.run parameter less cryptic by passing the 'app' object directly.

[jbrezmorf]

Keep only essential data, document the meaning of the keys for the frontend.

[jbrezmorf]

Do not pass api prefix to the frontend. Just define it as a constant in the frontend.
The point is to have possible separation of different api versions. If the frontend uses
api prefix passed by the backend, it is like do not have api versions at all.

[jbrezmorf]

just keep empty, this codes does effectively nothing

[jbrezmorf]

I suggest to create single landing page (root endpoint) with list of endpoints = separate dasaset dashboards and then one endpoint the item in the endpoints.yaml
this structure should be reflected by the backend API as well. So you should generate first level routers according to the items in the endpoints.yaml. Then config, s3, log routers should not be module wise instances but sub routers of the endpoints.

[jbrezmorf]

Moreover to manage state and possibly some cache for intividual routers we should introduce our own class per enpoint/store/separate dashboard:

routers/factory.py

from fastapi import APIRouter
from typing import Any, Dict

class ServiceAPI:
def init(self, name: str, cfg: Dict[str, Any]):
self.name = name
self.cfg = cfg
self.state = {"hits": 0}

    self._router = APIRouter(prefix=f"/{name}", tags=[name])
    # bind methods (self is captured)
    self._router.add_api_route("/status", self.status, methods=["GET"])
    self._router.add_api_route("/config", self.get_config, methods=["GET"])
    self._router.add_api_route("/touch", self.touch, methods=["POST"])

@property
def router(self) -> APIRouter:
    return self._router

# handlers (self available)
async def status(self):
    return {"service": self.name, "hits": self.state["hits"]}

async def get_config(self):
    return self.cfg

async def touch(self):
    self.state["hits"] += 1
    return {"ok": True, "hits": self.state["hits"]}