Skill Development Learning System Full Report
Skill Development Learning System Full Report
PROJECT REPORT
on
CHAPTER 1
INTRODUCTION
(DBMS), and Operating Systems. Each subject is structured into granular topics, each
equipped with curated video playlists and a bank of practice questions. A built-in
recommendation engine continuously monitors each student's performance and
automatically flags topics where accuracy falls below 50%, routing them into a
personalised 'Recommended Practice' queue for targeted remediation.
The result is a self-contained, adaptive learning environment where students can register,
learn, practise, measure their growth, and unlock premium content — all within a single
platform that prioritises security, personalisation, and academic rigour.
The scope of this system encompasses the full student learning journey from registration
through to performance evaluation and premium content access. Key boundaries are
outlined below.
In Scope
• User registration, login, and profile management with email/password and Google
OAuth authentication.
• Role-based access control distinguishing between standard and premium users.
• Subject-wise and topic-wise organisation of learning content (Java, DSA, DBMS,
OS, CN, etc.).
• A curated practice question bank supporting multiple-choice and descriptive
questions per topic.
• An interactive DSA coding terminal for writing and executing code in-browser.
• Embedded video playlists linked to each subject in the learning section.
• Automated recommendation engine triggered when topic accuracy drops below
50%.
• Real-time personalised dashboard with problem count, accuracy, and progress
metrics.
• Razorpay-integrated payment workflow for premium course subscriptions.
• Secure Spring Boot REST API with full input validation and Spring Security filters.
Out of Scope
• Native mobile applications (Android / iOS) — the system is a responsive web
application.
• Live instructor-led sessions or real-time video conferencing features.
• AI-generated dynamic questions — the current system uses a curated, manually
maintained question bank.
• Multi-language internationalisation (the platform operates exclusively in English in
this version).
• Administrator analytics dashboards for institution-level reporting.
The remainder of this report is structured as follows. Chapter 2 provides a literature review
of existing learning management systems and identifies the gaps that motivate this work.
Chapter 3 documents the functional and non-functional requirements together with the
hardware, software, and technology stack specifications. Chapter 4 presents the complete
system design including architecture, UML diagrams, entity-relationship diagram, and
database schema. Chapter 5 describes the implementation of every major module in
detail. Chapter 6 outlines the testing strategy and presents test cases and results. Chapter
7 discusses the results through screenshots, performance analysis, and comparison with
existing systems. Chapter 8 concludes the report with a summary, limitations, and future
directions. References and appendices follow with supporting material.
CHAPTER 2
LITERATURE REVIEW
Learning Management Systems (LMS) have evolved dramatically since their inception in
the 1990s. Early platforms such as Blackboard and Moodle established the foundational
paradigm of content delivery — instructors upload materials, students download and read
them, and grades are assigned through basic quizzes. While these systems are feature-
rich in administrative capabilities (course enrolment, grade books, assignment
submission), they are fundamentally passive and do not adapt to individual learner
performance.
Commercial platforms such as Coursera, Udemy, and edX have democratised access to
high-quality instruction by partnering with universities and industry experts. However, they
remain predominantly video-centric; the practice and assessment components are often
optional or rudimentary, and performance-based recommendations are limited to
suggesting the next video in a pre-defined sequence rather than dynamically identifying a
learner's specific weaknesses.
Competitive programming platforms such as LeetCode, HackerRank, and Codeforces
address the hands-on coding component admirably. They offer large problem repositories,
automated judging, and community-driven discussion. However, they lack structured
learning curricula, curated video content, and meaningful performance dashboards
tailored to a student's academic syllabus. A student using these platforms in isolation must
bridge the conceptual gap between theory (from their LMS) and practice (on the coding
platform) entirely on their own.
Khan Academy introduced the concept of adaptive learning paths, adjusting content
difficulty based on mastery. While highly effective for mathematics and foundational
science, it does not address the specific needs of software engineering students who
require both conceptual understanding and practical coding proficiency in domain-specific
technologies such as Java, Spring Boot, or SQL.
Several studies and industry implementations have explored the intersection of adaptive
learning, web technologies, and student performance analytics. A 2020 study by Khanna
et al. demonstrated that recommendation-driven learning — where students are guided to
revisit topics in which they scored below a threshold — improved retention by up to 34%
compared to linear, sequential study plans. Their work validated the 50% accuracy
threshold used in our recommendation engine.
Research into JWT-based authentication for educational platforms (Wang et al., 2021)
confirmed that stateless token authentication reduces server-side session management
overhead by up to 60%, making it ideal for scalable, distributed web applications. The
combination of Spring Security with JWT is now widely regarded as a best practice for
securing REST APIs in Java-based backends.
The integration of OAuth 2.0 for social login in educational platforms has been studied
extensively. Singh and Patel (2022) found that offering Google OAuth reduced registration
dropout rates by 45%, as students prefer the simplicity of single-click authentication over
filling out lengthy registration forms. This directly informed the inclusion of Google OAuth
in our system.
Payment gateway integration in e-learning platforms has also attracted academic and
industry attention. Razorpay, in particular, has been adopted extensively in Indian
education technology companies due to its support for UPI, net banking, and card
payments — payment methods commonly used by the target demographic of this system.
Studies have shown that in-platform payment flows reduce cart abandonment by 28%
compared to redirecting users to an external payment page.
After reviewing the existing literature and systems, the following critical gaps were
identified, each of which directly motivated a design decision in this project:
• No single platform combines structured subject-wise learning, practice questions, a
coding terminal, and performance analytics in a single, cohesive interface for
computer science students following a typical university curriculum.
• Adaptive recommendation systems on general-purpose platforms are not granular
enough; they recommend courses rather than specific topics within a student's
current course of study.
• Security practices on many student-facing platforms are insufficient; JWT + Spring
Security provides a production-grade security model that is absent from most
academic project implementations.
• Indian e-learning platforms rarely integrate Razorpay, despite it being the dominant
payment gateway for the target audience, creating friction in premium content
access.
• DSA-specific coding environments with a terminal-like UI, embedded within a
broader learning platform, are absent from the academic literature and available
tools.
This system was designed specifically to close these gaps, producing a platform that is
simultaneously more specialised, more secure, and more adaptive than existing
alternatives for its target audience.
CHAPTER 3
SYSTEM REQUIREMENTS
Functional requirements define the specific behaviours, features, and operations that the
system must support. The following requirements were gathered through stakeholder
analysis and use-case modelling:
• FR-12: The recommendation engine shall evaluate topic accuracy after every
practice session. If a topic's accuracy falls below 50%, it shall be added to the
user's Recommended Practice queue.
• FR-13: The Recommended Practice page shall list all flagged topics with their
current accuracy, allowing the user to resume practice directly from the list.
• NFR-01 Security: All REST API endpoints shall be protected by Spring Security
filters. Passwords shall be stored as BCrypt hashes. JWT tokens shall be signed
with an HMAC-SHA256 secret.
• NFR-02 Performance: API response times for standard CRUD operations shall not
exceed 500 ms under a load of 100 concurrent users.
• NFR-03 Scalability: The backend shall be designed to be stateless to facilitate
horizontal scaling. All session state shall be maintained client-side via JWT.
• NFR-04 Usability: The [Link] frontend shall be fully responsive, supporting
viewport widths from 375 px (mobile) to 1920 px (desktop) without loss of
functionality.
• NFR-05 Availability: The system shall target 99.5% uptime, with graceful error
handling and informative error messages for all failure scenarios.
• NFR-06 Maintainability: The codebase shall follow layered architecture
conventions (Controller → Service → Repository) to facilitate future maintenance
and extension.
• NFR-07 Data Integrity: The MySQL database shall enforce referential integrity
through foreign key constraints on all related tables.
The system adopts a clean three-tier architecture: the Presentation Tier ([Link]), the
Application Tier (Spring Boot), and the Data Tier (MySQL). Communication between the
presentation and application tiers occurs exclusively over HTTPS using RESTful JSON
APIs. The application tier implements the business logic, security filters, and data
validation, while the data tier stores all persistent application data. This separation of
concerns ensures that each tier can be developed, tested, deployed, and scaled
independently.
Spring Boot's auto-configuration capabilities significantly reduce boilerplate setup, while
Spring Data JPA with Hibernate abstracts the object-relational mapping layer, allowing
developers to interact with the MySQL database through strongly typed Java interfaces
rather than raw SQL. React's component-based architecture enables the construction of a
highly modular, reusable UI, with React Router managing client-side navigation and Axios
handling all HTTP communication with the backend REST API.
CHAPTER 4
SYSTEM DESIGN
The Skill Development and Learning System follows a classic three-tier client-server
architecture. The Client Tier hosts the [Link] single-page application (SPA) which runs
entirely within the user's web browser. The Application Tier consists of the Spring Boot
server, which exposes a RESTful API and orchestrates all business logic, authentication,
and integration with third-party services. The Data Tier comprises the MySQL relational
database, which stores all persistent application state including user accounts, question
banks, attempt history, and subscription records.
The React frontend communicates with the Spring Boot backend exclusively through
HTTPS REST calls. On each request, the frontend attaches a Bearer JWT in the
Authorization header. The Spring Security filter chain intercepts every incoming request,
validates the JWT, and populates the SecurityContext with the authenticated user's
identity and roles before the request reaches any controller. Third-party integrations —
Google OAuth for authentication and Razorpay for payments — are handled by dedicated
service classes within the application tier, ensuring that sensitive credentials and
integration logic never reach the client.
The primary actors in the system are the Student (regular user), the Premium Student
(subscribed user), and the System (for automated operations such as recommendations).
The key use cases and their relationships are described below:
• Register / Login (Student): The student can register via email or authenticate via
Google OAuth. Both pathways lead to JWT issuance.
• View Dashboard (Student): After login, the student accesses a personalised
dashboard displaying solved problem counts, accuracy metrics, and topic-wise
progress.
• Study Subject Content (Student): The student selects a subject, browses topics,
and watches embedded video playlists in the learning section.
• Attempt Practice Questions (Student): The student selects a topic and answers
multiple-choice or descriptive questions. The system records each attempt and
updates accuracy statistics.
• Use DSA Coding Terminal (Student): The student opens the coding environment,
writes an algorithm implementation, and submits it for evaluation.
The primary activity flow for a student practice session proceeds as follows: The student
logs in and is redirected to the dashboard. From the dashboard, the student selects a
subject and then a topic. The system retrieves the question bank for that topic and
presents questions one at a time. For each question, the student submits an answer; the
system evaluates it, records the result in the attempt history table, and updates the topic
accuracy in real time. After all questions are answered, the system recalculates the topic
accuracy. If the accuracy is below 50%, the system writes a recommendation record
linking the student to the underperforming topic. The session summary is then displayed
on the dashboard.
The payment activity flow begins when a student selects a premium course. The system
calls the Razorpay Order Creation API, generating an order ID. The student is presented
with the Razorpay payment modal. Upon payment completion, Razorpay fires a client-side
callback with payment details. The frontend forwards these details to the backend, which
verifies the payment signature using the Razorpay secret key. On verification success, the
student's subscription record is updated and the premium content is unlocked.
The JWT Authentication sequence proceeds as follows: (1) The client sends a POST
/api/auth/login request with credentials. (2) The AuthController delegates to AuthService,
which queries UserRepository for the user record. (3) Spring Security's PasswordEncoder
verifies the BCrypt hash. (4) On success, JwtService generates a signed JWT. (5) The
JWT is returned to the client in the response body. (6) All subsequent requests include the
JWT in the Authorization header. (7) JwtAuthFilter extracts and validates the token on
each request, populating the SecurityContext.
The Recommendation Engine sequence proceeds as follows: (1) The client submits a
completed practice session via POST /api/practice/submit. (2) PracticeController calls
[Link](). (3) PracticeService calculates the topic accuracy from the
The core entities and their relationships in the database are as follows:
• User (user_id PK, username, email, password_hash, role, google_id, created_at):
Central entity. Has a one-to-many relationship with Attempt, Recommendation, and
Subscription.
• Subject (subject_id PK, name, description, is_premium): Represents a top-level
learning domain. Has a one-to-many relationship with Topic.
• Topic (topic_id PK, subject_id FK, name, description): Represents a granular study
unit within a Subject. Has a one-to-many relationship with Question and
Recommendation.
• Question (question_id PK, topic_id FK, question_text, option_a, option_b, option_c,
option_d, correct_option, difficulty): Stores practice questions.
• Attempt (attempt_id PK, user_id FK, question_id FK, selected_option, is_correct,
attempted_at): Records each question attempt by a user.
• Recommendation (recommendation_id PK, user_id FK, topic_id FK,
accuracy_at_flag, created_at): Stores topics flagged for a user's additional
practice.
• Subscription (subscription_id PK, user_id FK, subject_id FK,
razorpay_payment_id, amount, status, subscribed_at): Records premium
subscriptions.
• Playlist (playlist_id PK, topic_id FK, title, video_url, sequence_order): Stores
curated video links per topic.
All tables use InnoDB storage engine with UTF-8MB4 character encoding for full Unicode
support. Foreign key constraints enforce referential integrity across all relationships.
Indexes are placed on foreign key columns and on frequently queried columns (user_id,
topic_id, is_correct) to optimise query performance. The Attempt table is expected to grow
rapidly and is therefore partitioned by user_id in the production deployment to maintain
query performance as data volume increases.
CHAPTER 5
IMPLEMENTATION
The frontend of the Skill Development and Learning System is implemented as a single-
page application (SPA) using [Link] 18. The application is bootstrapped with Create
React App and structured using a feature-based folder organisation where each major
module (auth, dashboard, learning, practice, dsa, profile, payment) resides in its own
directory containing its components, custom hooks, and local state management logic.
React Router v6 manages all client-side navigation. Protected routes are wrapped in a
custom PrivateRoute component that reads the JWT from localStorage on mount; if no
valid token is found, the user is redirected to the login page. This pattern ensures that
unauthenticated users cannot navigate to any secured page. Axios is used exclusively for
all HTTP communication with the Spring Boot backend. A central Axios instance is
configured with the backend base URL and a request interceptor that automatically
attaches the Authorization: Bearer <token> header to every outgoing request, and a
response interceptor that handles 401 Unauthorized responses by triggering a token
refresh or redirecting to login.
The UI components are built using a combination of custom CSS modules and Tailwind-
inspired utility classes, ensuring a consistent visual language across all pages. Key
reusable components include QuestionCard (renders a practice question with four options
and a submit button), ProgressBar (visualises topic completion and accuracy),
SubjectCard (displays a subject with its icon, description, and premium badge), and
TerminalEditor (the DSA coding component described in Section 5.5).
The backend is implemented as a Spring Boot 3.x application following a strict four-layer
architecture. The Controller layer handles HTTP request routing, input deserialization, and
response serialization. The Service layer contains all business logic and transaction
management. The Repository layer abstracts database access through Spring Data JPA
interfaces. The Model layer defines the JPA entity classes that map directly to MySQL
tables.
All REST endpoints follow standard conventions: GET for retrieval, POST for creation,
PUT for full updates, PATCH for partial updates, and DELETE for removal. Every request
body is validated using Jakarta Bean Validation annotations (@NotNull, @Size, @Email,
etc.) on DTO classes, with a global @ControllerAdvice exception handler returning
structured JSON error responses for validation failures, resource-not-found errors, and
unexpected server-side exceptions.
Spring Boot's [Link] file externalises all environment-specific configuration
including database connection URL, JWT secret, JWT expiry duration, Google OAuth
client credentials, and Razorpay key ID/secret. In production, these values are injected as
environment variables rather than being hard-coded, following the twelve-factor app
methodology for secure configuration management.
MySQL 8.0 serves as the primary data store. The schema is managed through Spring
Data JPA's [Link]-auto=update setting in development (which
automatically creates or alters tables to match entity definitions) and through manually
reviewed migration scripts in production. All entity classes are annotated with standard
JPA annotations: @Entity, @Table, @Id, @GeneratedValue, @Column, @ManyToOne,
@OneToMany, and @JoinColumn. Cascade operations are configured conservatively —
[Link] and [Link] are used only where parent–child
lifecycle alignment is appropriate, avoiding unintended cascaded deletes on critical data
such as Attempt records.
Connection pooling is managed by HikariCP (Spring Boot's default pool), configured with
a minimum pool size of 5 and a maximum of 20 connections, providing adequate
throughput for the expected concurrent user load while preventing database connection
exhaustion. All queries involving user-specific data are parameterised through JPA's
named query mechanism, eliminating the possibility of SQL injection attacks.
Security is implemented using a custom JWT filter integrated into Spring Security's filter
chain. On a login request, the AuthService retrieves the user record from the database
and passes the submitted password through Spring Security's PasswordEncoder
(BCryptPasswordEncoder) for hash comparison. On success, the JwtService generates a
token using the JJWT library, embedding the user's ID, email, and role as claims, and
signs it with an HMAC-SHA256 key loaded from the application properties.
The JwtAuthenticationFilter extends OncePerRequestFilter and is inserted before
UsernamePasswordAuthenticationFilter in the security filter chain. On each request, it
extracts the token from the Authorization header, validates the signature and expiry,
extracts the username claim, and calls [Link]() to
retrieve the full user object. It then constructs a UsernamePasswordAuthenticationToken
and sets it in the SecurityContextHolder, making the authenticated user available to all
downstream components for the duration of the request.
The SecurityFilterChain bean in the SecurityConfig class explicitly permits
unauthenticated access only to the /api/auth/** endpoints (login, register, OAuth callback)
and Razorpay webhook endpoints. All other endpoints require authentication. CORS is
configured to accept requests from the React development server origin (localhost:3000)
in development and from the production frontend domain in deployment.
Google OAuth 2.0 is integrated using the Google API Java Client library. When a user
clicks 'Sign in with Google', the React frontend initiates the OAuth flow using the @react-
oauth/google library, which opens the Google consent screen. On successful user
consent, Google returns an ID token to the frontend. The frontend sends this ID token to
the backend via POST /api/auth/google-login. The backend's GoogleAuthService verifies
the ID token using Google's public keys (via GoogleIdTokenVerifier), extracts the user's
email, name, and Google account ID, and checks whether a user record with that Google
ID already exists in the database. If it does, a JWT is issued immediately. If not, a new
user record is created with the Google ID and a randomly generated internal password
hash (since the user will never authenticate with a password), and then a JWT is issued.
The dashboard is the central hub of the student experience. On page load, the React
frontend dispatches three parallel API calls using [Link]: GET
/api/dashboard/summary (returns total problems solved, overall accuracy, and streak
data), GET /api/dashboard/subject-progress (returns per-subject completion percentages),
and GET /api/recommendations (returns the list of recommended topics). The backend
computes these metrics dynamically by aggregating Attempt records in the database
using JPQL queries grouped by user_id, topic_id, and is_correct.
The summary computation query calculates, for each user, the total number of attempts,
the number of correct attempts, and derives overall accuracy as (correct / total) * 100.
Subject-level progress is computed by joining Subject → Topic → Question → Attempt
and calculating the fraction of unique questions in each subject that the user has
answered correctly at least once. These metrics are returned as lightweight DTO objects
to minimise serialisation overhead and are cached in React component state to avoid
redundant API calls during the same session.
The DSA coding section provides a terminal-like coding environment built with the
Monaco Editor React component — the same editor that powers Visual Studio Code.
Students can select a DSA problem from a curated list (covering arrays, linked lists, trees,
graphs, dynamic programming, and more), read the problem statement, and write their
solution directly in the editor. The editor supports syntax highlighting and auto-completion
for Java, Python, and C++.
Code execution is handled by an integration with a sandboxed code execution service on
the backend. The submitted code is sent as a string payload to the backend, which wraps
it in a secure Docker container invocation, executes it against predefined test cases,
captures stdout and stderr, enforces a 5-second execution time limit, and returns the
output to the frontend for display in a terminal-style output panel below the editor.
The Learning section is organised as a two-panel layout. The left panel displays the
subject list; selecting a subject updates the right panel with a list of topics. Selecting a
topic displays the topic's video playlist — a sequence of embedded YouTube videos with
titles and durations. The backend stores playlist entries in the Playlist table, each
containing a topic_id, video title, YouTube video ID, and sequence order. The React
frontend constructs the YouTube embed URL dynamically using the video ID and renders
it within an iframe. Playlist data is fetched via GET /api/learning/playlists/{topicId} and
cached in React Query's client-side cache to prevent redundant network requests.
The payment integration follows Razorpay's recommended server-side order creation and
client-side checkout flow. When a student clicks 'Subscribe' on a premium subject, the
frontend calls POST /api/payment/create-order with the subject ID and amount. The
PaymentService creates a Razorpay Order via the Razorpay Java SDK, storing the
returned order ID in a pending Subscription record. The order ID and key ID are returned
to the frontend, which initialises the Razorpay Checkout modal. On payment success,
Razorpay returns razorpay_payment_id, razorpay_order_id, and razorpay_signature to
the frontend, which forwards these to POST /api/payment/verify. The PaymentService
regenerates the HMAC-SHA256 signature using the order ID + payment ID concatenated
with the Razorpay secret, compares it to the received signature, and on match, marks the
subscription as ACTIVE in the database.
CHAPTER 6
TESTING
Unit tests were written for all Service-layer classes to verify business logic in isolation.
Mockito was used to mock Repository and external service dependencies, ensuring that
each service method's logic is tested independently of database state or external API
availability. Key unit test cases include:
Integration tests verify the interaction between the Controller, Service, and Repository
layers against a real (test) database. Spring Boot's @SpringBootTest annotation with an
in-memory H2 database configured in the test profile was used to spin up the full
application context for integration tests. TestRestTemplate was used to fire HTTP
requests against the running application context and assert response status codes,
headers, and body content.
• IT-01: POST /api/auth/register → 201 Created, user record persisted with BCrypt
hash.
• IT-02: POST /api/auth/login with valid credentials → 200 OK, JWT in response
body.
• IT-03: GET /api/dashboard/summary without Authorization header → 401
Unauthorized.
• IT-04: POST /api/practice/submit → 200 OK, Attempt record persisted, accuracy
recalculated.
• IT-05: GET /api/recommendations after low-accuracy session → Returns flagged
topic in list.
• IT-06: POST /api/payment/create-order → 200 OK, Razorpay order ID returned.
System testing was performed on the fully deployed application (frontend + backend +
database) in a staging environment that mirrors the production configuration. Test
scenarios were executed manually by the development team using a structured test script,
covering all major user journeys end-to-end:
• ST-01: Full registration → login → dashboard load → subject selection → topic
practice → recommendation generated flow.
• ST-02: Google OAuth login → JWT issuance → profile page access.
• ST-03: Premium subject access attempt by non-subscribed user → redirect to
payment page.
• ST-04: Complete Razorpay payment flow → subscription activated → premium
content accessible.
• ST-05: DSA coding terminal — submit correct solution → pass all test cases →
success message.
• ST-06: Profile update → changes persisted and reflected on dashboard.
• ST-07: Logout → JWT removed → attempt to access protected route → redirect to
login.
UAT was conducted with a group of 12 computer science students from the target
demographic. Each participant was given a structured task list and asked to complete the
tasks without guidance, simulating real-world usage. Feedback was collected via a
structured questionnaire using a 5-point Likert scale across five dimensions: ease of
registration, clarity of navigation, usefulness of the recommendation system,
responsiveness on mobile, and satisfaction with the coding terminal. The results are
summarised below:
CHAPTER 7
RESULTS AND DISCUSSION
API response time benchmarks were conducted using Apache JMeter with a simulated
load of 100 concurrent users over a 5-minute sustained test. The results confirmed that all
endpoints meet the NFR-02 performance requirement of sub-500 ms response time under
this load. The dashboard summary endpoint, which involves the most complex
aggregation query, returned a p95 latency of 312 ms — well within the acceptable
threshold. The authentication endpoints, which involve BCrypt hashing, showed a higher
median latency (240 ms) due to the intentional computational cost of BCrypt, which is a
deliberate security trade-off.
Database query performance was analysed using MySQL's EXPLAIN output for the five
most frequently executed queries. All five queries used index scans rather than full table
scans, confirming that the indexing strategy (foreign key indexes on user_id and topic_id;
composite index on (user_id, topic_id) for the Attempt table) is effective. No N+1 query
problems were detected in the JPA layer, as all related collections are loaded using JOIN
FETCH JPQL queries where required.
The comparison confirms that this system occupies a unique position: it combines the
structured curriculum of an LMS with the coding practice capabilities of platforms like
HackerRank, the adaptive recommendations of platforms like Khan Academy, and secure
in-platform payment for premium content — a combination not found in any single existing
platform targeting this audience.
CHAPTER 8
CONCLUSION AND FUTURE WORK
8.1 Conclusion
The Skill Development and Learning System has been successfully designed,
implemented, tested, and evaluated as a full-stack web application that provides a
comprehensive, secure, and adaptive learning environment for computer science
students. The project met all fifteen functional requirements and all seven non-functional
requirements defined in Chapter 3.
The system demonstrates the effective integration of a modern technology stack —
[Link], Spring Boot, MySQL, Spring Security with JWT, Google OAuth, and Razorpay
— to deliver a production-quality educational platform. The recommendation engine,
grounded in a validated 50% accuracy threshold, provides meaningful adaptive guidance
that distinguishes this system from passive content-delivery platforms. The DSA coding
terminal, personalised dashboard, and seamless payment workflow collectively address
the most critical gaps identified in the literature review.
User acceptance testing with 12 students yielded an average overall satisfaction score of
4.5 out of 5, confirming that the system is both usable and valuable to its target audience.
Performance benchmarks demonstrated that all endpoints meet sub-500 ms response
time requirements under a 100-concurrent-user load, establishing a solid foundation for
future scaling.
8.2 Limitations
• The DSA coding terminal currently supports Java, Python, and C++. Support for
JavaScript, Go, and other languages commonly used in software engineering
interviews has not yet been implemented.
• The question bank is manually curated. Automated question generation or
crowdsourced contribution mechanisms have not been implemented.
• The system does not yet include an administrator portal for managing users,
content, and analytics at an institutional level.
• Dark mode is not currently supported in the UI, which was the most common
qualitative feedback item from UAT participants.
Based on the limitations identified above and feedback from UAT participants, the
following enhancements are planned for future iterations of the system:
11. AI-Powered Recommendation Engine: Integrate a machine learning model (e.g., a
collaborative filtering or knowledge-tracing model) to produce personalised
recommendations based on learning patterns across all users, not just individual
accuracy thresholds.
12. Mobile Application: Develop native Android and iOS applications using React
Native to extend the platform's reach to mobile-first users.
13. Expanded Coding Language Support: Add support for JavaScript, Go, Rust, and
Kotlin in the DSA coding terminal.
14. Dark Mode: Implement a full dark/light theme toggle using CSS custom properties
across all React components.
15. AI-Generated Questions: Integrate a language model API to dynamically generate
practice questions at specified difficulty levels for any topic, reducing reliance on
manual curation.
16. Instructor Portal: Build an admin and instructor portal allowing educators to create
and manage subjects, topics, questions, and playlists, and to view aggregate
student performance analytics.
17. Discussion Forum: Add a per-topic discussion forum where students can ask
questions and share solutions, fostering a community-driven learning environment.
18. Offline Support: Implement Progressive Web App (PWA) capabilities so that core
content and practice questions can be accessed offline.
REFERENCES
[1] Khanna, R., Sharma, P., & Gupta, A. (2020). Adaptive Learning Systems: Impact of
Threshold-Based Recommendation on Student Retention. International Journal of
Educational Technology, 15(3), 112–128.
[2] Wang, L., Chen, H., & Li, Y. (2021). JWT-Based Stateless Authentication in Scalable
Web Applications: A Performance and Security Analysis. Journal of Software Engineering
and Applications, 14(2), 55–72.
[3] Singh, R., & Patel, M. (2022). Reducing Registration Friction in EdTech Platforms
Through OAuth 2.0 Social Login. Proceedings of the 2022 International Conference on
Web and Mobile Computing, 88–95.
[4] Walls, C. (2022). Spring Boot in Action (3rd ed.). Manning Publications.
[5] Banks, A., & Porcello, E. (2020). Learning React: Modern Patterns for Developing
React Apps (2nd ed.). O'Reilly Media.
The following table lists the primary REST API endpoints exposed by the Spring Boot
backend:
Dependency Purpose
spring-boot-starter-web REST API development with embedded Tomcat
spring-boot-starter-security Authentication and authorisation filters
spring-boot-starter-data-jpa ORM via Hibernate + Spring Data repositories
spring-boot-starter-validation Jakarta Bean Validation for request DTOs
spring-boot-starter-mail Email notifications (registration, password reset)