CDAC Connect – Interview Script (Frontend +
Backend)
Use this as your step‑by‑step script. Read the 30‑sec intro, then follow the flow order.
Wherever you see You say: you can speak that line.
0) 30‑Second Elevator Pitch
You say: CDAC Connect is a collaboration platform for students, faculty, and alumni. Users can sign up, log
in, chat in real time, and manage profiles. The stack is React on the frontend, Spring Boot on the backend,
JWT + Spring Security for auth, WebSockets (STOMP) for chat, and MySQL + MongoDB for data. I’ll quickly
walk through Authentication → User Management → Real‑time Chat → API Docs & Config → Database
Flow → Non‑functional aspects.
1) Architecture Snapshot (what runs where)
React (Login, Signup, Chat UI, ProtectedRoute, authService)
│ Axios
▼
Spring Boot (Controllers → Services → Repositories)
│ Security: JwtFilter + SecurityConfig
│ WebSocket: STOMP endpoints + Message mappings
▼
Databases: MySQL (users, roles, profiles) + MongoDB (chat messages)
You say: Frontend calls REST APIs via Axios. Auth is stateless using JWT. After login, WebSocket connects for
chat. MySQL stores user/role data; MongoDB stores chat messages for fast writes.
2) Authentication Flow — Step‑by‑Step (with class interactions)
Frontend → Backend path
Login.jsx / SignUp.jsx → authService (Axios) → AuthController → AuthService →
UserRepository
↘ JwtService (for token)
1
2.1 Frontend trigger
• Login.jsx : collects username/password, calls authService.login() .
• SignUp.jsx : collects username/email/password, calls authService.signup() with local
validation.
• ProtectedRoute.jsx : uses authService.isAuthenticated() to guard routes.
You say: The frontend wraps protected pages with ProtectedRoute . If not logged in, user is redirected
to /login .
2.2 Controller layer (AuthController)
• Accepts DTOs: LoginRequestDTO , RegisterRequestDTO .
• Delegates to AuthService and returns either LoginResponseDTO { userDTO, jwt } or
created user.
You say: Controllers are thin—no business logic—just request/response mapping.
2.3 Service layer (AuthService)
• Signup:
• UserRepository.existsByUsername() → reject duplicates.
• PasswordEncoder (BCrypt) → hash password.
• UserRepository.save(user) → persist new user.
• Map to UserDTO and return.
• Login:
• UserRepository.findByUsername()
• AuthenticationManager validates credentials.
• JwtService.generateToken(user) → build JWT with userId/roles & expiry.
• Return LoginResponseDTO .
You say: Auth logic lives in AuthService ; controllers don’t hash or generate tokens.
2.4 JWT Service (JwtService)
• Creates claims (userId, roles), signs using jwt.secret , sets jwt.expiration .
• Helpers: extractUserId() , isTokenValid() .
2.5 Security filter (JwtAuthenticationFilter) + SecurityConfig
• Every post‑login request passes the filter:
• Extract token (Authorization header or cookie)
• JwtService.extractUserId()
• Load user via UserRepository
• Validate token
• Put UsernamePasswordAuthenticationToken into SecurityContext
• SecurityConfig defines which endpoints are public vs protected and plugs the JWT filter.
2
You say: This makes the API stateless and scalable—no server session needed.
2.6 Frontend storage & global error handling
• authService.login() stores currentUser (plus color and loginTime) and user in
localStorage .
• Axios instance has withCredentials: true for cookie support.
• A response interceptor handles 401/403/404/500 globally → on 401 it calls
authService.logout() and redirects to /login .
Pro tips / quick fixes:
• In isAuthenticated() , fix the key typo: use 'user' not 'úser' .
• Throw real errors: throw new Error(errorMessage) , not new errorMessage .
• Consolidate duplicate methods: fetchOnlineUsers() and getOnlineUsers() .
You say: We also added a global Axios interceptor so unauthorized errors log you out consistently.
3) User Management Flow (post‑login)
Frontend (Profile page) → UserController → UserService → UserRepository (MySQL)
• Fetch profile, update user details, list online users.
• Admin‑only actions guarded with annotations like @PreAuthorize("hasRole('ADMIN')") .
• DTOs for API payloads; Entities remain internal.
• Transactional service methods ensure consistency.
You say: We separate DTOs from entities and keep business rules in services for clean architecture.
4) Real‑Time Chat — WebSocket Flow (STOMP)
Frontend (STOMP client) ─ CONNECT ─▶ /ws endpoint
│ (JWT validated via handshake/interceptor)
▼
@MessageMapping("/chat.send") ChatController → ChatService.save()
│ ↘
SimpMessagingTemplate.convertAndSend()
▼
MongoDB (persist messages) /topic/chat/{roomId or userId} (broadcast)
3
Steps you speak
1. Connect: Frontend opens a STOMP connection to /ws . A handshake interceptor validates the JWT.
2. Send: User sends {sender, receiver|roomId, content, timestamp} to /app/chat.send .
3. Process & Persist: ChatController → ChatService.save() → message stored (MongoDB fits
real‑time writes).
4. Broadcast: SimpMessagingTemplate publishes to /topic/chat/{target} ; all subscribed
clients receive it.
5. Offline: If recipient is offline, they’ll fetch messages later via REST ( /api/messages/
private?... ).
You say: We use STOMP topics for fan‑out and MongoDB for chat history. It’s fast and scalable.
5) API Documentation & Configuration (Swagger/OpenAPI)
• @Configuration + @Bean in SwaggerConfig enable OpenAPI docs and Swagger UI.
• Benefits:
• Self‑documented APIs
• Try‑it‑out UI for manual testing before frontend integration
• Faster onboarding for new devs
You say: I demo endpoints in Swagger first, then plug the URLs into the frontend.
6) Database Interaction Flow (JPA + Mongo)
Relational (MySQL with Spring Data JPA):
• Entities: User , Role , etc. annotated with @Entity , relationships via @OneToMany ,
@ManyToOne .
• Repositories: extend JpaRepository ; methods like findByUsername , existsByUsername .
• Services: business logic + @Transactional .
Document (MongoDB for Chat):
• Documents: Message stored with sender, receiver|room, content, timestamps.
• Repositories or template‑based operations for high‑write chat streams.
You say: User and auth data are relational; chat is document‑oriented for speed.
7) Non‑Functional Highlights
• Security: BCrypt hashing, JWT with expiry, role‑based access.
• Error Handling: Global exception handlers; Axios interceptor for frontend.
4
• Performance: Stateless auth, WebSockets for low‑latency chat, MongoDB for write‑heavy logs.
• Scalability: Clear separation of concerns; can deploy services independently.
8) 2‑Minute Demo Plan (scripted)
1. Open Swagger → show /auth/signup , /auth/login → test login.
2. In React app, log in → ProtectedRoute lets me in.
3. Open Chat → send a message; show it appears on another browser as well.
4. Refresh → messages load from DB (history works).
5. Show logout → interceptor + route guard.
You say: This proves auth, authorization, real‑time messaging, persistence, and UX.
9) Rapid‑Fire Q&A (answer like this)
• Why JWT over sessions? Stateless, horizontally scalable, works well with gateways.
• Why BCrypt? Slow hash resists brute force; standard for passwords.
• Why Mongo for chat? High write throughput, flexible schema for messages.
• How do you protect WebSocket? JWT validated during handshake; only authenticated sessions can
subscribe/send.
• How do you handle 401 globally? Axios response interceptor logs out and redirects.
• How do you enforce roles? @PreAuthorize on controller/service methods + claims in JWT.
• How do you avoid leaking entities? Use DTOs; map explicitly.
10) Code Callouts (things you improved)
• Fixed isAuthenticated() key typo ("user" not "úser").
• Throw new Error(message) instead of new message .
• Removed duplicate getOnlineUsers / fetchOnlineUsers .
• Added strict password policy on signup (UPPERCASE, digit, special, length ≥ 8).
You say: These small details show code quality and production readiness.
11) One‑liner closers
• Impact: "We delivered a secure, real‑time collaboration app with a clean layered architecture."
• Ownership: "I implemented the auth flow end‑to‑end and integrated WebSockets with persistence."
• Next steps: "I’d containerize services and add tests & CI/CD for production."
