36 lines
4.4 KiB
Text
36 lines
4.4 KiB
Text
3.1 Zusammenfassung der Aufgaben
|
||
Das Projekt „Ticketsystem für Raumbetreuer“ wurde als praxisnahe Abschlussarbeit konzipiert, um den vollständigen Entwicklungszyklus einer modernen Webanwendung abzubilden.
|
||
Die Kernaufgabe bestand darin, eine Plattform zu schaffen, auf der Lehrkräfte technische Mängel in Räumen melden können, während Raumbetreuer diese zentral verwalten und bearbeiten. Dabei lag der Fokus auf einer strikten Trennung der Verantwortlichkeiten, Datensicherheit und einer intuitiven Bedienbarkeit.
|
||
Die Architektur wurde gemäß moderner Standards in Frontend (Next.js), Backend (Spring Boot) und Datenbank (PostgreSQL) unterteilt. Dies ermöglichte uns, die theoretischen Kenntnisse der Ausbildung – von der Datenbankmodellierung bis hin zur Integration von REST-Schnittstellen – praktisch anzuwenden.
|
||
|
||
3.2 Teilaufgabe – Erstellung der Webseite (Frontend)
|
||
Herr Milkovic übernahm die Konzeption und Realisierung des Frontends. Das Ziel war eine moderne Single-Page-Application (SPA), die sowohl auf Desktop- als auch auf mobilen Endgeräten performant läuft.
|
||
Als Technologie wurde Next.js (React-Framework) mit TypeScript gewählt. TypeScript war hier besonders wertvoll, da es durch die statische Typisierung viele Fehler bereits zur Entwicklungszeit verhinderte und die Zusammenarbeit im Team durch klare Schnittstellendefinitionen erleichterte.
|
||
Für ein professionelles Look-and-Feel wurde die Komponentenbibliothek "Shadcn UI" in Verbindung mit Tailwind CSS genutzt. Dies sparte viel Entwicklungszeit beim Styling und sorgte für eine konsistente Designsprache.
|
||
Herausfordernd war die Integration von NextAuth.js für die Authentifizierung, da hier sichergestellt werden musste, dass der Benutzerstatus (Lehrer vs. Raumbetreuer) korrekt vom Backend übernommen und in der UI berücksichtigt wird.
|
||
|
||
3.3 Teilaufgabe – Implementierung des Backends
|
||
Herr Buchkamer war für das Backend verantwortlich. Hierbei kam Java mit dem Spring Boot Framework (Version 3.2.2) zum Einsatz.
|
||
Die Backend-Entwicklung umfasste:
|
||
• Design und Implementierung der REST-API Endpunkte.
|
||
• Umsetzung der Geschäftslogik (z.B. Ticket-Statusübergänge).
|
||
• Sicherheitskonfiguration mittels Spring Security (Passwort-Hashing mit BCrypt).
|
||
• Datenbankanbindung über Spring Data JPA.
|
||
Besonderes Augenmerk lag auf der Validierung eingehender Daten, um inkonsistente Zustände in der Datenbank zu verhindern.
|
||
|
||
3.4 Teilaufgabe – Datenbankkonzeption
|
||
Als persistenter Datenspeicher diente PostgreSQL. Das Datenmodell wurde vor der Implementierung in einem Entity-Relationship-Modell (ERM) geplant und anschließend normalisiert (3. Normalform), um Redundanzen zu vermeiden.
|
||
Wichtige Entitäten waren User, Tickets, Rooms und Comments. Die Beziehungen (z.B. ein User betreut mehrere Räume) wurden über entsprechende Fremdschlüssel und Join-Tables (n:m Beziehungen) realisiert.
|
||
|
||
3.5 Probleme, Lösungen und Fazit
|
||
Wie in jedem Entwicklungsprojekt lief nicht alles reibungslos. Wir sahen uns mit einigen technischen Hürden konfrontiert, die wir jedoch lösen konnten.
|
||
|
||
CORS (Cross-Origin Resource Sharing):
|
||
Ein hartnäckiges Problem war die CORS-Policy. Da Frontend und Backend in der Entwicklungsumgebung (und auch im Docker-Setup) auf unterschiedlichen Ports bzw. Domains laufen, blockierte der Browser zunächst die API-Anfragen. Wir mussten uns intensiv mit der `SecurityConfig` in Spring Boot auseinandersetzen, um die korrekten Header und Origins freizugeben, ohne dabei Sicherheitslücken zu öffnen.
|
||
|
||
Login / Authentifizierung:
|
||
Das größte Problem trat kurz vor der Abgabe auf: Der Login-Prozess funktionierte plötzlich nicht mehr zuverlässig. Es gab Schwierigkeiten bei der Sitzungsübergabe zwischen NextAuth (Frontend) und dem Spring Security Backend. Teilweise wurden Benutzer trotz korrekter Daten abgelehnt oder die Rolle wurde nicht richtig übertragen.
|
||
Wir mussten in einer "Nachtschicht" kurz vor dem Deadline-Termin den gesamten Authentifizierungs-Flow debuggen. Letztendlich lag es an einem Detail in der Token-Verarbeitung und der Cookie-Konfiguration. Glücklicherweise konnten wir den Fehler rechtzeitig finden und beheben, sodass zur Präsentation ein funktionierendes System bereitstand.
|
||
|
||
Fazit:
|
||
Trotz dieser Schwierigkeiten sind wir stolz auf das Ergebnis. Das Projekt hat uns gezeigt, wie wichtig saubere Schnittstellenabsprachen und frühzeitiges Testen (insbesondere von Integrationspunkten wie Login) sind. Wir haben als angehende Fachinformatiker viel über das Zusammenspiel komplexer Frameworks gelernt.
|