afnan9700/some-document-editor

1. This is a polyglot collaborative document-editing system split into four deployable pieces: an Angular frontend, a Spring Boot backend, a Node/TypeScript collaboration-state worker, and a Go WebSocket service. A docker-compose.yml and haproxy config suggest the services are intended to run together behind a reverse proxy.

2. The Spring Boot backend is the main application API and business-logic layer. It owns authentication, documents, permissions, sharing/invites, locks, access requests, and issuing WebSocket tickets. It also exposes internal endpoints used by the collaboration worker service.

3. The frontend is an Angular SPA. It contains distinct UI areas for auth, document library, document workspace, sharing/invites, and live collaboration. Frontend services indicate it talks to the backend over HTTP for normal CRUD flows and to the WebSocket service for real-time editing.

4. Authentication is backend-owned and JWT-based. The backend includes AuthController, AuthService, JwtService, JWT and internal auth filters, a CustomUserDetailsService, and a SecurityConfig. The frontend has a JWT interceptor, so authenticated API calls are token-attached on the client side.

5. The document subsystem is the core persistence boundary in the backend. It has document metadata and content models/repositories, plus DocumentService and DocumentController. The frontend mirrors this with document models, library pages, entry pages, and workspace pages, indicating separate flows for browsing documents versus editing a specific document.

6. Sharing and access control are first-class backend subsystems. sharing, invite, permission, and access packages show a model where users can invite others, manage permission levels, and request access. The frontend has matching document-sharing pages and invite-link UI, so sharing is a user-visible workflow rather than an internal admin feature.

7. Locking is a separate coordination layer in the backend. The presence of DocumentLock, LockService, lock status/type enums, and lock repository suggests the system prevents conflicting edits or distinguishes editing modes. This is likely used alongside collaboration to manage who can edit and when.

8. Real-time collaboration is offloaded to dedicated services rather than handled directly in the Spring API. The backend has a collaborationstateworkerclient package with proxying/routing components, and an internal collaborationstateworker package for syncing worker-owned document state. This implies the backend brokers document sessions and delegates live state handling to a separate worker tier.

9. The Node/TypeScript collaboration-state-worker appears to maintain document runtime state and bridge to Spring. Its documentManager, documentRuntime, springClient, and server files suggest it receives collaboration requests, tracks per-document session state, and synchronizes with backend-persisted state or permissions. This is the stateful collaboration layer.

10. The Go ws-service is the real-time transport layer. Its internal packages for ws, hub, broker, auth, and protocol indicate it terminates WebSocket connections, authenticates them via tickets/Redis-backed auth state, and fans messages out through a hub/broker abstraction. This service is the live message bus between editors.

11. WebSocket access is ticket-based rather than raw JWT handoff. The backend has websocketticket models/services, and the frontend has a websocket-ticket.service.ts. That suggests the frontend first asks the backend for a short-lived ticket, then uses that ticket to connect to the Go WebSocket service.

12. The collaboration flow likely looks like this: user logs in through Angular, receives a JWT, loads a document via backend APIs, requests a WebSocket ticket, connects to the WebSocket service, and then exchanges editing events through the collaboration stack. The worker and backend synchronize document/session state, while persistent document data remains in the Spring backend database layer.

13. The repo also includes strong cross-cutting concerns in the backend: a global exception model, API error response type, and utility security helpers. That indicates the Spring service is the canonical place for request validation, authorization failures, and domain errors.

14. From an architecture-diagram perspective, the main boundaries are: browser UI, Spring backend API, worker/state service, WebSocket transport service, and the shared backing stores implied by JPA and Redis usage. The important external interactions are HTTP for normal app operations, Redis for WebSocket/session coordination, and proxied WebSocket connections for live editing.