Architecture discussion: JSON-RPC, CSR, and SSR boundaries

[cfuehrmann]

Context

We should explicitly document and review the boundary between the Leptos frontend and the Axum backend:

• Which frontend/backend interactions use JSON-RPC, if any, versus the current typed JSON-over-HTTP API under /api/*.
• Which rendering and behavior is intentionally client-side (CSR).
• Which rendering or data loading is intended to happen server-side (SSR).
• Whether the current split is a good design for Flasher, and where it creates unnecessary complexity or latency.

The current code appears to use CSR effects and event handlers with gloo-net to call same-origin Axum endpoints. Request and response payloads are shared through flasher-types. The frontend has an ssr feature and host-target rendering tests, but it is not yet obvious which SSR behavior is part of the runtime architecture versus test/build support. The API routes are resource/action-shaped HTTP endpoints rather than an obvious single JSON-RPC endpoint, so the terminology and intended direction should be made explicit.

Questions to answer

1. Can we make a complete call/rendering matrix by page and operation?
   • What calls cross the frontend/backend boundary?
   • Which are JSON-RPC, ordinary JSON HTTP, or something else?
   • Which components require browser APIs, passkey ceremonies, or client-only state?
   • What can be rendered or loaded during SSR, and what must wait for hydration?
2. Is the current CSR-first approach appropriate for this single-user app?
   • Consider first paint and perceived latency, auth and passkeys, hydration complexity, caching, error handling, and implementation/maintenance cost.
3. If SSR should be expanded, what data-fetching and hydration model should we use?
4. Should the transport remain explicit resource/action endpoints, move toward actual JSON-RPC, or use a deliberate hybrid?
5. What constraints should guide the decision: shared Rust types, browser e2e testing, deployment as one binary, and the internal-only API contract?

Desired outcome

• A short architecture note or decision record with a request/rendering diagram.
• An explicit page/operation matrix for JSON transport, CSR, SSR, and hydration.
• A decision with rationale and identified tradeoffs.
• Follow-up implementation issues, if the decision requires changes.

This issue is for discussion and architecture clarification; it does not prescribe an immediate implementation change.