studium.FULL-STACK LMS
Student workspace / actual screenshot
STUDENT / TEACHER / ADMINAPPLICATION INTERFACE
04 / Full-stack LMS · academic project
Studium.
A learning platform for students, teachers and administrators.
RoleSole developer
StatusTest environment
In briefFull-stack academic application
Studium interface. Actual screens from student, teacher and administrator workspaces.
An LMS with distinct student and teacher workflows
Studium is a learning management system I developed independently. Students can work with assignments, tests, materials, grades and schedules; teachers manage their courses and review submissions; administrators handle the academic structure and user accounts.
I built a React/TypeScript frontend and a Java 21/Spring backend split into services behind a single API gateway. The application runs in a test environment and was developed as an academic project, not as a deployed commercial LMS.
What I worked on
- Role-specific React interfaces, API integration and assignment/test workflows.
- Java/Spring services, gateway routing, JWT authorization and separate data ownership.
- PostgreSQL persistence, MinIO file storage, Kafka events, notifications and testing.
An assignment from creation to review
A single assignment crosses several areas of the platform. The teacher creates and publishes it, the student submits a file, and the teacher grades the submission. Permissions and file access have to remain consistent at each step.
01
Publish
The teacher creates an assignment for a subject and group. The service keeps the assignment state and access scope.
02
Submit
The student uploads their work through the gateway. File metadata is stored in PostgreSQL; the actual file is kept in MinIO.
03
Review
The teacher sees the relevant submissions and records feedback or a grade, subject to role and ownership checks.
04
Update
The new result becomes available in the student workspace and can produce a notification through the event pipeline.
The frontend presents a consistent workflow while assignments, files, identity and notifications remain separate backend responsibilities.
Inside the implementation
01
Gateway and data ownership
The public frontend uses a single Spring Cloud Gateway. Behind it, education, schedules, assignments, tests, files, notifications and other services own their respective data schemas. The gateway handles routing, access policy and selected response aggregations.
Services communicate by REST where a result is needed immediately and through Kafka where a domain change should trigger another component. Cross-service database reads are not part of the business flow.
02
Authorization around real workflows
The role model includes student, teacher, admin and owner. A student can submit work and see their own results. Teachers manage subjects within their assigned scope, while administrators manage groups, rooms, schedules and users.
Authorization is enforced by the backend and gateway rather than relying on hiding UI elements. The frontend still has distinct navigation and workspaces for each role.
03
Files and notifications
Binary files are stored in MinIO with metadata in PostgreSQL. Assignment services reference file identifiers and enforce policies, while file-service handles downloads and previews.
Domain events are published to Kafka; notification-service can persist the resulting notification and make it available to the app or a Telegram bot. I also added integration and backend verification procedures for the test environment.
Technologies
JavaSpring BootReactTypeScriptPostgreSQLKafka
Where it stands
Studium is a substantial full-stack project with separate student, teacher and administrator interfaces. The screenshots on this page are from the real application.
It has been developed and tested in a non-production environment. I do not present it as a commercial deployment with real users.
Interface
Studium in use
