raiyashu2004/juris

1. System shape

JurisAI is a two-tier application: a React/Vite single-page frontend and a FastAPI backend. The frontend owns the user experience and lightweight client state; the backend owns legal AI orchestration, retrieval, and security-sensitive API calls.

2. Frontend boundary

The frontend lives under frontend/src and is organized by screens such as Chat, Legal Research, Case Finder, Document Analyzer, Draft Generator, My Documents, Saved Research, and Settings. This suggests a single SPA that routes between legal workflows rather than multiple separate apps.

3. Client state and persistence

The README indicates chat history is kept in browser storage for persistent conversational sessions. That means the frontend is not just rendering results; it also preserves user interaction state locally to avoid server-side session dependency.

4. Backend API surface

backend/main.py is the FastAPI entrypoint, with route modules split by domain: auth, chat, documents, and cases. This is a clean API boundary where each legal workflow is exposed through its own router instead of a single monolithic endpoint set.

5. AI orchestration layer

The core AI work is isolated in backend/services/: llm.py for model access, embeddings.py for vectorization, rag.py for retrieval-augmented generation, and langchain_chat.py for conversational memory/chain behavior. This indicates the backend acts as an LLM orchestration proxy rather than embedding AI logic in route handlers.

6. Legal document pipeline

document_analyser.py is the dedicated service for uploaded document review, summarization, and risk flagging. The document flow likely enters through the documents router, is processed in this service layer, and returns structured AI feedback to the frontend.

7. Legal knowledge retrieval

The data/ scripts (ingest_constitution.py, ingest_judgments.py) show an offline ingestion pipeline for Indian legal sources. These scripts appear to prepare the corpus that feeds embeddings and RAG, so the app’s answers are grounded in constitutional text and case law rather than general-purpose chat.

8. Auth and security boundary

Authentication is separated into backend/routers/auth.py and backend/utils/auth.py, with a mirrored frontend auth context in frontend/src/context/AuthContext.jsx. This suggests a dedicated identity boundary around login/session handling, distinct from the AI and document features.

9. Persistence and shared utilities

backend/models/db_models.py, backend/utils/database.py, and backend/utils/config.py indicate shared backend infrastructure for config and any persisted records. The README notes the deployment is designed to work without requiring a provisioned PostgreSQL database, so persistence is intentionally lightweight and deployment-friendly.

10. External services and runtime

The key external dependency is Google Gemini, accessed from the backend using an API key. The frontend points to the backend via VITE_BACKEND_URL, and the repo is set up for Vercel-hosted frontend plus Render-hosted backend, with docker-compose.yml and render.yaml capturing deployment wiring.

11. Build and delivery

The frontend is built with Vite into frontend/dist, which is what gets served in production. The backend runs as a Python ASGI service under Uvicorn/FastAPI. This separation makes the UI deployable as static assets while keeping AI and retrieval logic server-side.

12. Useful diagram takeaway

A good architecture diagram should show: user → React SPA → FastAPI routers → AI/services layer → Gemini + legal corpus. Separately, show offline ingestion feeding the corpus, and local browser storage supporting persistent chat history on the client.