asifahmedsahil/full-stack-developer-technical-assessment---jumatechs

1. This repo is a two-tier support inbox: a Django REST backend exposes all data and business rules, and a Next.js 14 frontend renders the agent UI and talks to the backend over HTTP. There is no separate application server or message broker; async behavior is handled in-process.

2. The Django project is split into two domain apps:

- accounts owns identity and authentication.

- chat owns the support inbox domain: conversations, messages, locks, and sentiment records.

config is the top-level Django project that wires settings, URLs, ASGI/WGI, and app registration.

3. Authentication is JWT-based with a custom email-based user model. The flow is:

- register/login via backend auth endpoints,

- receive access/refresh tokens from SimpleJWT,

- frontend stores/uses the access token for all protected API calls,

- /api/auth/me/ returns the current agent profile.

This is the main security boundary around the rest of the API.

4. The core backend data model lives in chat. The important entities are:

- Conversation as the container for a support thread,

- Message for customer/agent messages,

- ConversationLock to enforce single-agent assignment,

- ConversationSentiment to persist background sentiment results.

The lock record is the central coordination mechanism for write access to replies.

5. Conversation access is mostly read-heavy, with a controlled write path:

- list endpoint supports pagination, search by customer_name, and status filtering,

- detail endpoint returns the full message history plus lock/sentiment state,

- reply endpoint checks that the caller owns a valid lock before allowing an agent response,

- lock endpoint acquires or refreshes a 5-minute lock and rejects conflicting ownership.

This creates a clear separation between viewing a conversation and mutating it.

6. The “AI suggestion” feature is deliberately lightweight. A backend endpoint uses a rule-based keyword matcher (refund, shipping, password) to return canned reply suggestions, rather than calling an external LLM service. That keeps the architecture self-contained and deterministic.

7. Sentiment processing is asynchronous but not externally queued. When an agent reply is saved, the backend starts a background thread that computes sentiment from the reply text and writes a ConversationSentiment row. In test mode, this work runs synchronously so the tests can assert outcomes immediately.

8. The frontend is organized by route-first App Router structure:

- /login for authentication,

- the main page for the conversation list,

- /conversation/[id] for conversation detail and replying.

Shared UI behavior is encapsulated in ConversationList, MessageComposer, AuthGuard, and Toast.

9. Frontend state is mostly server-driven through polling. The conversation detail page re-fetches the conversation every 3 seconds when the tab is visible, merges new messages by ID, and clears expired locks in the UI. Reply submission is optimistic, so the UI updates before the next poll round-trip confirms it.

10. The frontend’s data layer is small but important:

- lib/api.ts wraps fetch calls to the Django API,

- lib/auth.ts handles token storage/access,

- type definitions in src/types keep the UI aligned with API payloads.

This is the main boundary between React components and backend contract.

11. Persistence is local and simple: SQLite is the configured database, with Django migrations defining the schema. This makes the system easy to run locally and keeps the deployment story centered on the Django app plus the Next.js frontend.

12. Seed commands are part of the operational architecture:

- seed_data creates demo users,

- seed_conversations populates sample inbox data.

These commands support repeatable local setup and demo workflows without relying on external fixtures.

13. Testing is split along the same boundaries as the runtime architecture:

- Django tests cover auth, conversation rules, locking, and sentiment behavior,

- Jest/React Testing Library covers the key frontend components and interaction flows.

The tests reflect the main system seams: authentication, inbox state, locking, and reply composition.