From 2c766b10a3c3ed67eec2c246cf13ba3a4e744f8d Mon Sep 17 00:00:00 2001 From: kasun Date: Sun, 10 May 2026 03:32:16 +0200 Subject: [PATCH] added doc for claude code implementation --- .../07-claude-code-feasibility.md | 172 ++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 docs/02-Preparation/07-claude-code-feasibility.md diff --git a/docs/02-Preparation/07-claude-code-feasibility.md b/docs/02-Preparation/07-claude-code-feasibility.md new file mode 100644 index 0000000..2f2c884 --- /dev/null +++ b/docs/02-Preparation/07-claude-code-feasibility.md @@ -0,0 +1,172 @@ +**vaessl: Claude Code feasability** + +This is a showcase of how useful Claude Code can be for an app such as vaessl. There were very little steps to do to achieve an entire feature. This was achieved with a standard paid plan over 2 days. I never hit the limits and I must have used around 300k tokens likely a little more. Not only was I able to setup Java classes and React componentes. Claude Code pretty much nailed the CSS for the app. After minor adjustments for styling, CORS configurations, solving SonarQube warnings and generating additional integration tests I was good to commit the changes. The following documentation was also generated via CC. + +The entire commit can be reviewed under following hash 43bbcece7a901e94021e10bca8b227c8ba285ac2. + + +# What the feature achieves + + Users can connect Vaessl to external services (starting with Homebox) by entering their credentials in a UI. The backend authenticates against the remote service, persists the + connection in the database, and issues an HTTP session cookie. The frontend dashboard reflects live connection status and lets users disconnect. + + --- + ## Backend + + **build.gradle.kts** + + Added spring-boot-starter-session-jdbc (and its test counterpart). This enables Spring Session to store HTTP sessions in the PostgreSQL database rather than in-memory, so + sessions survive server restarts and work correctly in multi-instance deployments. + + --- + **application.yaml** + + Two additions: + - spring.session.store-type: jdbc activates the JDBC session store added above. + - server.servlet.context-path: /api prefixes all endpoints with /api, keeping the API cleanly separated from the frontend when served from the same host. + - vaessl.frontend-url externalizes the frontend origin so CORS can be configured without hardcoding. + + --- + **config/CorsConfig.java (new)** + + Spring MVC CORS configuration. The frontend runs on a different port/domain than the backend, so without this every browser request would be blocked. Key detail: + allowCredentials(true) is required for the session cookie to be sent cross-origin — this is why the allowed origins are explicit (wildcards are forbidden when credentials are + allowed). The three origins cover local dev, a LAN IP, and a tunnelled code-server URL. + + --- + **config/SessionConfig.java (new)** + + Customises the session cookie that Spring Session issues. HttpOnly prevents JavaScript from reading it (XSS mitigation). SameSite=Lax allows the cookie to travel with + cross-site navigations (needed for the separate frontend origin) while blocking CSRF from third-party sites. CookieMaxAge = Integer.MAX_VALUE keeps the cookie persistent in the + browser across tabs/restarts; the actual session lifetime is controlled per-login in the controller. + + --- + **META-INF/additional-spring-configuration-metadata.json (new)** + + Registers the custom vaessl.frontend-url and spring.session.store-type properties with the IDE. This gives autocomplete and documentation hints in application.yaml — it has no + runtime effect. + + --- + **dto/LoginResult.java (new)** + + An internal record (connectionId, expiresAt) used as the return type of ConnectionService.login(). It carries back the database ID of the saved connection and the token expiry + so the controller can use both without coupling to the entity layer. + + --- + **dto/AuthResponse.java (new)** + + The JSON body returned to the client after a successful login. It intentionally contains only serviceType and expiresAt — no tokens, no internal IDs — because all sensitive + state lives server-side in the session and the database. + + --- + **dto/ConnectionStatusResponse.java (new)** + + The JSON body returned by the status endpoint for each active connection. Includes enough for the UI to show: which service, the URL it's connected to, the logged-in username, + when the token expires, and whether it is currently considered connected (expiry has not passed). + + --- + **connection/ConnectionProvider.java (modified)** + + The provider interface gained five new methods: + - checkCredentials — validates the request before any network call is made. + - findUniqueConnectionEntry — looks up an existing database row for this user+URL combination. + - connectionToEntity / updateToRepository — split "create new row" from "refresh token on existing row", so re-logging in updates the token rather than creating a duplicate. + - getTokenExpiry — lets each provider expose its token lifetime (defaults to null meaning no expiry check). + + This keeps all provider-specific logic inside the provider, not scattered across the service. + + --- + **connection/ConnectionService.java (modified)** + + login() was refactored to use the new provider methods and now returns LoginResult instead of void. The upsert logic (find existing → update or create new) lives here. A new + method getConnectionStatus() was added: it loads the entity by ID, asks the provider for its expiry, and returns the status DTO. The ID-based lookup is safe here because the + controller already resolved the ID from the session. + + --- + **connection/ConnectionController.java (modified)** + + Three endpoints now exist: + + - POST /login — calls ConnectionService.login(), stores the returned connectionId in the HTTP session under a key like HOMEBOX_CONNECTION_ID, sets the session timeout to match + the token expiry (minimum 5 minutes), and responds with AuthResponse. + - GET /connections/status — reads all *_CONNECTION_ID keys from the session and calls getConnectionStatus for each, returning a list. Returns an empty list if no session exists + (not an error). + - DELETE /connections/{serviceType} — removes the specific key from the session. If no connections remain, the session is invalidated entirely. + + --- + **connection/HomeBoxConnectionProvider.java (modified)** + + Implements the new interface methods: + - checkCredentials validates that username and password are present before touching the network. + - findUniqueConnectionEntry queries the repository by appUrl + username. + - connectionToEntity delegates to HomeboxEntity.from(...). + - updateToRepository pattern-matches on HomeboxEntity and refreshes token, expiresAt, and attachmentToken. + - getTokenExpiry returns the stored expiresAt from the HomeboxEntity. + + --- + **connection/Endpoint.java (modified)** + + Added CONNECTION_STATUS("/connections/status") to the enum, alongside the existing constants, so the integration test can reference the status endpoint without a magic string. + + --- + ##Frontend + + types/connection.ts (new) + + TypeScript interfaces that mirror the backend DTOs exactly: LoginRequest, AuthResponse, ConnectionStatus. This is the single source of truth for shapes shared across the + frontend — the API layer and UI components both import from here. + + --- + **api/client.ts (new)** + + A thin apiFetch wrapper around the native fetch API. Two important behaviours: + - credentials: 'include' — sends the session cookie on every request (required for cross-origin session auth). + - Error normalisation — on non-2xx responses it tries to extract a detail or title field from the JSON body (standard Spring error format) and throws it as an Error with a + human-readable message. + - 204 No Content is returned as undefined cast to T, avoiding a JSON parse error on empty bodies (used by the DELETE endpoint). + + --- + **api/connections.ts (new)** + + Three typed API call functions — login, getStatuses, logout — each wrapping the corresponding endpoint via apiFetch. The component layer calls these directly; they are not + aware of the session cookie mechanism. + + --- + **components/Dashboard.tsx (new)** + + The top-level page component. It: + - Defines the static SERVICES registry (currently just Homebox) — adding a new service means adding one entry here. + - Fetches connection statuses on mount via useEffect. + - Manages which connect-modal is open via openModal state. + - Passes connect/disconnect callbacks down to ServiceCard and on success calls refresh() to re-fetch statuses. + + --- + **components/ServiceCard.tsx (new)** + + A presentational card for a single service. Displays the service icon, name, a coloured connected/disconnected badge, the logged-in username, and token expiry date. Shows a + "Connect" or "Disconnect" button depending on state. It receives everything as props — no API calls inside. + + --- + **components/ConnectModal.tsx (new)** + + A modal dialog with a login form (App URL, username, password). On submit it calls login() from the API layer and calls onSuccess if it succeeds, or renders the error message + if it fails. Auto-focuses the first field on open and closes on Escape key — both accessibility practices. Clicking the overlay also closes it. + + --- + **App.tsx (modified)** + + Replaced the previous placeholder content with a single render. The app entry point is now minimal by design — all layout and state live inside Dashboard. + + --- + ## Summary flow + + User clicks "Connect" → ConnectModal form submitted + → POST /api/login (with credentials) + → backend authenticates against Homebox + → saves/updates connection row in DB + → stores connection ID in HTTP session (JDBC-backed) + → returns AuthResponse with expiry + → Dashboard calls getStatuses() + → GET /api/connections/status (session cookie sent) + → backend reads session, looks up DB rows, returns status list + → ServiceCard shows "Connected" with username + expiry \ No newline at end of file