This project has been created as part of the 42 curriculum by kikwasni, alraltse, korzecho, sandrzej, zslowian
This project is licensed under the GNU GPL v3 License.
➡️ [GNU GPL v3 License]
LICENSE.md)]
JustPlay42 is a team-based web application developed at 42 Warsaw as part of the ft_transcendence project. The platform combines real-time communication with the classic 2048 puzzle game, allowing users to connect, chat, and compete with friends.
The platform provides the following functionalities:
-
Authentication: A user management system supporting registration, login, and session handling.
-
Interactive Chat: A real-time messaging system that allows users to communicate, connect with friends, and interact directly through the platform.
-
2048 Game: A classic puzzle game where players combine tiles with the same number to create larger values, aiming to reach the 2048 tile.
-
Challenges and Competition: Users can challenge their friends through the chat, adding a competitive element to the gaming experience.
-
User Profiles: Individual profiles that allow users to have their own identity within the platform.
The goal of JustPlay42 is to bring gaming and social interaction together in one place, creating an engaging environment where users can communicate, challenge their friends, and enjoy playing together
Create and configure the environment files before running the project:
- infra/.env and infra/.env.example
- infra/postgres/.env and infra/postgres/.env.example
- infra/redis/.env and infra/redis/.env.example
- backend/.env and backend/.env.example
- backend/transcend/.env and backend/transcend/.env.example
- frontend/.env and frontend/.env.example
From the repository root, start the application on dev profile with make up.
Components can be started separately (on dev or local profiles) using makefiles in infra, backend, or frontend folders (see supporting documentation).
Supporting documentation:
Application will be available via nginx proxy on port 8443.
Kinga — Project Manager & Developer
Lead the project through the full development lifecycle while contributing as a developer.
-
Project Management & Team Coordination: Coordinated team communication, facilitated discussions and negotiations, and helped resolve conflicts to maintain effective collaboration. Organized meetings, aligned team members on decisions and next steps, tracked task progress, and supported task distribution and ongoing project planning.
-
Documentation: Created Confluence articles, architecture diagrams, feature specifications, and visual guides for the project knowledge base. Coordinated documentation and knowledge sharing across the entire team.
-
UI/UX Design: Designed the application's visual identity and user interface, creating high-fidelity mockups and feature visualizations in Canva. Planned the layout, user flows, and overall user experience to ensure a consistent design across all modules.
-
Design Documentation: Documented UI concepts, workflows, and feature specifications in Confluence, providing implementation guidelines and maintaining design consistency throughout development.
-
Project Documentation Repository: Created and maintained the Documentation folder containing project-related documentation, including UI/UX visualizations, articles, meeting presentations, and progress tracking materials. Organized resources such as design concepts, feature descriptions, project updates, and presentation materials to provide a centralized knowledge base for the team.
Documentation resources include:
-
Chat Module: Implemented the Real-Time Chat Module feature.
-
UI/UX Implementation Support: Created high-fidelity mockups for the entire application and participated in the process of translating the designed interfaces into the frontend implementation. Collaborated with the frontend team to ensure consistency between the proposed design, user flows, and the final application interface. Related documentation: Frontend Design Integration.
-
Code Quality: Managed pull requests and conducted code reviews with the Technical Lead.
-
Legal & Compliance: Created and integrated the Privacy Policy and Terms of Service pages, drafted the required legal documentation, and integrated the Open-Source License into the repository.
Szymon — Technical Lead, Software Architect
Managed the technical side of the project during initial stages of development. Defined the technology stack and standards.
- Architectured a Hexagonal spring boot backend following SOA, DDD, UseCase centric design, separation of Concerns and CQRS, enabling development consistent with the Open closed principle.
- Oversaw frontend backend JWT token integration, for stateless Rest API and STOMP websocket AsyncApi, allowing for secure token isolation and permission management with Spring Security.
- Documented the backend according to the Docs as Code, Self Documenting Code, and Living Documentation principles.
- Utilized gradle plugins and test pipelines for diagram and asciidoc generation, providing insight into the architecture and state of the backend.
- Tested the backend in accordance with TDD and BDD, utilized Spring context splitting.
- Integrated Spring WebSockets with Redis.
Alina — DevOps, Database Engineer
Designed and maintained the project's infrastructure and database layer
- Containerization: Containerized the backend and frontend applications using Docker.
- Infrastructure: Configured PostgreSQL and the Docker Compose environment for local development.
- Environment Management: Established a shared, idempotent Docker network and coordinated environment configuration across Docker Compose and Makefiles.
- Build & Compatibility: Improved the Docker build process.
- Database Design: Designed and updated the database schema as new features were added.
- Persistence: Integrated PostgreSQL with the backend using Spring Data JPA and implemented the repositories.
- Transactions: Researched and applied transaction management to keep data consistent.
- Migrations: Set up database migrations and managed schema changes over time.
- Testing: Wrote integration tests for the repository layer.
- Documentation: Created and maintained database documentation, including the entity-relationship diagram.
Kacper — Frontend Developer, API Integration Engineer
Led the initial frontend setup and established core integrations for REST API and WebSocket communication.
- Frontend Architecture: Bootstrapped the Next.js application and development environment, including linters, formatters, and initial HTTPS configuration.
- 2048 Game Development: Designed and implemented the 2048 game, integrating its core gameplay mechanics into the platform to enable users to play and compete with friends.
- API Integration: Developed the integration layer between the Next.js frontend and the Spring Boot backend. Implemented the BFF (Backend-for-Frontend) pattern, API web clients, and robust error handling for authentication flows (login/register).
- Real-Time Communication: Integrated WebSocket (STOMP) connections on the client side, enabling real-time chat functionality and live user presence (online/offline) updates.
- UI/UX Design: Designed and developed the foundational layout and aesthetics for the platform's landing page and user profile views.
- Chat implementation: Developed the chat logic based on STOMP and HTTPS backend endpoints, with sending and removing messeges, creating conversations with friends and error handling when backend connection breaks.
Zyta — Product Owner, Frontend Developer & Designer
Owned the application's visual language and frontend quality bar, and the build environments the team develops and evaluates on.
- Product Owner: Set the direction for the workstreams she led — design system, theming, social features, accessibility, and internationalization.
- Design System & Theming: Responsible for the design-token layer, the shared component library, and the three application themes.
- Identity & Social Frontend: Responsible for the profile, friends, and chat surfaces of the SPA.
- Accessibility & Internationalization: Responsible for WCAG 2.1 AA compliance and multi-language support (EN / PL / FR / AR with RTL).
- CI & Build Environments: Responsible for the GitHub Actions pipeline, the two supported build profiles, and their automated verification.
Established a structured workflow for team coordination and task execution:
- Kick-off Meeting: Defined the application concept, project scope, and allocated team roles through collaborative brainstorming.
- Task Distribution: Assigned development tasks based on team members' responsibilities and agreed priorities.
- Synchronization: Organized regular full-team and sub-team meetings to monitor progress and resolve blockers.
- Hybrid Meetings: Coordinated both on-site sessions at the 42 Warsaw campus and remote meetings.
- Timeline Management: Monitored project progress, adapted priorities to meet deadlines, and coordinated scope adjustments when necessary.
- Design Coordination: Planned the application's interface and feature designs before implementation, ensuring developers followed a unified vision documented in Confluence.
- Team Support & Collaboration: Supported and motivated team members throughout the development process, fostering a positive and collaborative atmosphere. Encouraged open communication, knowledge sharing, and teamwork to maintain strong team engagement and effective cooperation.
Tools: Jira (task tracking), Confluence (project documentation, architecture & design specifications), Canva (UI/UX mockups and feature visualizations), Slack (project communication), Messenger (rapid team updates).
- Next.js: The core frontend framework, chosen due to its industry-standard status, and its powerful Server-Side Rendering (SSR) capabilities which improve performance and SEO.
- TailwindCSS & Catppuccin: Used for styling and theming, allowing for a robust, reusable, and easily switchable custom design system.
- openapi-fetch: For type-safe API calls generated directly from backend OpenAPI specifications.
- sockJS & @stomp/stompjs: For handling STOMP WebSocket connections to provide real-time updates and messaging.
- Spring Boot: Used as the core backend framework, mainly because Szymon (Technical Lead, Software Architect) already had experience with it, which made development faster and lowered the risk of getting stuck on the learning curve.
- Spring Data JPA (Hibernate): Handles the mapping between our Java objects and the PostgreSQL database, so we don't have to write repetitive SQL by hand.
- Liquibase: Keeps track of database schema changes over time, so updates stay consistent and easy to reproduce across environments.
- PostgreSQL: Our main database. We went with it because it's one of the most popular and reliable open-source options out there, and it works smoothly with Spring Boot.
- Redis: Used alongside PostgreSQL. Like Postgres, it's open-source, well-supported, and integrates easily with the rest of our Spring Boot setup.
- Nginx: A lightweight and powerful open-source router configured for SSL certificate termination and request proxying.
- Makefile & Docker: Custom orchestration setup made to adhere to the separation of concerns and ensure simple, reproducible builds.
All feature development followed a structured, API-first approach that enabled parallel execution across different technology layers:
- Requirements & Core Domain: Feature development began with business requirements defined by the Project Manager (Kinga). The Technical Lead (Szymon) then implemented the core domain models and use cases in Java, exposing the functionality via REST and Async APIs.
- Parallel Integration: Once the API contracts were established, the team split into simultaneous tracks to prevent bottlenecks:
- Persistence Layer (Infra): Implementing database repositories and integrating infrastructure (Alina).
- Client Layer (Frontend): Designing the UI components (Zyta) and consuming the backend endpoints (Kacper).
Integration standards were enforced through an CI pipeline combined with team policies and repository configuration:
- Continuous Integration (GitHub Actions): Every push and pull request targeting
mainruns a three-job pipeline:- Backend tests — the Gradle test suite executed inside Docker against PostgreSQL and Redis containers.
- Dev/eval build verification — brings up the containerized stack and asserts the security topology: REST and STOMP endpoints must answer through nginx's HTTPS proxy while the backend's ports are confirmed closed. It then generates API types from the live OpenAPI/AsyncAPI specs, lints and builds the Next.js frontend, and verifies the homepage is served end-to-end through nginx.
- Local build verification — validates the frontend developer workflow: the backend must be published on loopback only (
127.0.0.1:5001, invisible to the network) with health and STOMP endpoints reachable for a host-run dev server. - Docker layer, Gradle, and Next.js caches keep pipeline runs to a few minutes.
- Formatters & Linters: Integrated static analysis tools to eliminate stylistic debates, catch logical bugs before runtime, and enforce framework best practices. This allowed peer reviews to focus entirely on architecture and business logic.
- GitHub Flow: Adopted a feature-branching strategy. Developers frequently synced with the main branch to preempt massive merge conflicts, submitting all work exclusively through Pull Requests.
- Conventional Commits: Enforced structured commit messaging. This provided instant context for changes, streamlined debugging, and prepped the repository for automated release changelogs.
- Repository Protection & Linear History: Configured GitHub branch protection rules to disable pushes to main and require peer approvals. All PRs were integrated using "Squash and Merge," ensuring the main branch maintained a clean, readable, and chronological history of deployable features.
| Column | Type |
|---|---|
val |
UUID |
display_name |
varchar(255) |
avatar_id |
UUID |
| Column | Type |
|---|---|
val |
UUID |
content |
bytea |
| Column | Type |
|---|---|
user_id |
UUID |
friend_id |
UUID |
| Column | Type |
|---|---|
val |
UUID |
email |
varchar(255) |
hash |
varchar(255) |
role |
public."user_role" |
Note: role uses a custom Postgres enum type.
| Column | Type |
|---|---|
val |
UUID |
| Column | Type |
|---|---|
chat_id |
UUID |
user_id |
UUID |
| Column | Type |
|---|---|
val |
UUID |
chat_id |
UUID |
sender_id |
UUID |
content |
text |
created_at |
timestamptz |
Each feature spans several layers, so the last column names who built which part.
| Feature | Description | Who worked on it |
|---|---|---|
| Registration & Login | Sign up with email and password — passwords must meet strength rules (length, no whitespace, not a common password) and emails must be unique. Logging in issues a JWT kept in a cookie; users can log out. The forms validate input before it reaches the server. | Backend: Szymon · Database: Alina · Frontend: Kacper (BFF auth flow, token cookie), Zyta (pages, form validation, logout) |
| User Profile | Every user has a profile page with a display name and avatar (a default avatar if none is set). Owners can edit their name and upload a new avatar; visitors see a read-only view. | Backend: Szymon · Database: Alina · Frontend: Zyta, Kacper (initial layout) |
| User Search | Find other users by display name, with paginated results, and add them as friends from the results. | Backend: Szymon, Alina (page-size limits) · Frontend: Zyta |
| Friends | Add and remove friends; a paginated friends list shows avatars and online status and links to each friend's profile. | Backend: Szymon · Database: Alina (query optimization, pagination) · Frontend: Zyta |
| Online Presence | Users are marked online or offline from their live connection, and their status updates for others in real time. | Backend: Szymon (STOMP WebSockets, Redis) · Frontend: Kacper |
| Real-Time Chat | Start a conversation with a friend, send messages that arrive instantly, delete your own messages, and scroll back through history. An offline banner and automatic reconnection handle dropped connections, and screen readers announce new messages. | Backend: Kinga (chat domain model, starting a chat), Szymon (REST and WebSocket chat API) · Database: Alina · Frontend: Kacper (messaging logic, reconnection), Zyta (chat UI) |
| 2048 Game | The classic 2048 puzzle in the browser — slide tiles to merge matching numbers and reach 2048 — with friends invited to play through the chat. | Kacper |
| Themes & Design System | Three switchable themes (42Hub, Catppuccin Mocha, Catppuccin Latte) remembered between visits, a shared component library, and a responsive layout with compact navigation on narrow screens. | Frontend: Zyta · UI/UX mockups: Kinga |
| Accessibility | WCAG 2.1 AA compliance: full keyboard navigation, skip link, landmark regions, screen-reader support, and AA contrast in every theme. | Zyta, Kacper (2048 game) |
| Multiple Languages & RTL | The interface is available in English, Polish, French, and Arabic, switchable at any time; Arabic is laid out right-to-left. | Zyta, Kacper (2048 game) |
| Landing Page | Public start page that introduces JustPlay42 and leads visitors to sign up or log in. | Kacper (initial layout), Zyta (redesign, rebrand) |
| Legal Pages & License | Privacy Policy and Terms of Service pages, readable without logging in; the project is licensed under GNU GPL v3. | Kinga, Kacper, Zyta (public access, restyle) |
| Public API & Documentation | A secured REST API (JWT authentication, rate limiting) documented with OpenAPI/Swagger, WebSocket events documented with AsyncAPI, and an in-app page explaining how to use the API. | Szymon (API, rate limiting, docs) · Alina (endpoint access fixes) · Kacper (Swagger over HTTPS) · Zyta (API docs page) |
| HTTPS Deployment | The whole stack starts in Docker with a single make command and is served only over HTTPS through nginx on port 8443. |
Alina (containerization, PostgreSQL, Docker network) · Szymon (Compose orchestration, nginx TLS) · Zyta (build profiles, HTTPS-only backend) |
| Continuous Integration | A GitHub Actions pipeline runs the backend tests and verifies both builds end-to-end on every pull request. | Zyta, Szymon (backend test job) |
| Generated Backend Documentation | AsciiDoc reference pages and architecture diagrams generated directly from the backend code. | Szymon, Kinga (module documentation) |
Total Points Calculated: 19 Points (Major = 2pts, Minor = 1pt)
- Implementation: Backend built with Java Spring Boot; frontend built with Next.js using a Backend-for-Frontend (BFF) pattern.
- Justification: Provides a robust ecosystem, dependency injection on the backend, and industry-standard SSR capabilities on the frontend.
- Contributors: All team members
- Implementation: Built a real-time system using Java WebSockets (STOMP protocol) and sockJS on the frontend. Broadcasts messages, synchronizes status, and handles disconnects.
- Justification: Eliminates HTTP polling overhead, providing an immersive, low-latency user experience for chatting and presence updates.
- Contributors: Szymon, Kacper
- Implementation: Developed a chat system (send/receive messages), user profile pages, and a friends system (add/remove friends, online statuses).
- Justification: Establishes the core pillars for a social platform, allowing users to connect and communicate effectively.
- Contributors: All team members
- Implementation: Developed a public REST API for database interaction, protected via JWT Tokens, with rate limiting and comprehensive documentation (OpenAPI). Includes 5 distinct endpoints.
- Justification: Essential for allowing secure client interactions while protecting the backend from unauthorized access or brute-force requests.
- Contributors: Szymon
- Implementation: Used Spring Data JPA (Hibernate) as the ORM layer for object-to-database mapping in PostgreSQL.
- Justification: Prevents SQL injection vulnerabilities, maintains type safety, and abstracts database schema complexity.
- Contributors: Alina
- Implementation: Leveraged Next.js Server Components and server-side logic for rendering profiles and layouts before sending them to the client.
- Justification: Ensures faster First Contentful Paint, improved performance, and significantly better SEO compared to a standard SPA.
- Contributors: Zyta, Kacper
- Implementation: Built a semantic design-token layer using TailwindCSS and Catppuccin, extracting more than 10 reusable components (Buttons, Cards, TextFields, Avatars, etc.).
- Justification: Ensures visual consistency, allows rapid theming across the application, and standardizes UI
- Contributors: Zyta, Kinga
- Implementation: Brought every page to WCAG 2.1 AA in all three themes. Contrast was fixed at the design-token level; pages gained a skip link, per-page titles, landmark regions, and keyboard-reachable scroll regions; a reusable
Dialogbuilt on the native<dialog>element handles focus management; a live-region announcer lets screen readers speak incoming chat messages; and form fields carry programmatic labels, required state, andautoCompletehints. The 2048 game is playable by keyboard and screen reader.eslint-plugin-jsx-a11yin strict mode blocks regressions, and compliance was verified with axe-core scans (driven by Playwright) of every route in every theme and language, plus a manual NVDA screen-reader pass. - Justification: Real-time chat and games are where assistive-technology users are most often left out, and a social platform that only part of its audience can use fails its purpose. Because colors already flowed through semantic design tokens, meeting contrast requirements took one change per token instead of one per component.
- Contributors: Zyta, Kacper
- Implementation: The full interface is available in English, Polish, French, and Arabic, built with next-intl and one message catalogue per language (
messages/*.json). Users switch language from the footer; a server action stores the choice in an HttpOnlyNEXT_LOCALEcookie, so server-rendered pages arrive already translated. Type-checking enforces that all four catalogues define the same keys, and thereact/jsx-no-literalslint rule stops untranslated text from entering the UI. Backend error responses are mapped to translated messages instead of being shown in English, and server-only text (the legal pages) is kept out of the client bundle. - Justification: Polish serves the team's home campus, English is the common language of the 42 network, French reflects 42's origin, and Arabic exercises right-to-left support. next-intl was chosen because it works with Next.js Server Components, so translation happens on the server alongside SSR.
- Contributors: Zyta, Kacper
- Implementation: Selecting Arabic switches the document to
<html dir="rtl" lang="ar">from a single source of truth (getDirection()inlib/i18n/config.ts), so the layout, sidebar, chat bubbles, and footer links mirror. User-generated content is wrapped in<bdi>so names and messages that mix scripts render in the correct order, and a dedicated Arabic font applies through the:lang(ar)selector. The language and theme toggles stay left-to-right so they do not move under the pointer when switching languages. - Justification: RTL support is more than translated text: reading order, alignment, and mixed-direction user input must all follow the language. Setting direction in markup rather than CSS also informs assistive technology and the browser's bidirectional text algorithm.
- Contributors: Zyta, Kacper
- Implementation: Verified and adjusted UI/UX consistency and feature compatibility across major modern browsers.
- Justification: Broadens accessibility to users regardless of their browser preference.
- Contributors: Alina
- Implementation: Used Spring Security for registration/login flows. Users can update their profile information and upload custom avatars.
- Justification: Securing user identity and managing profiles is the foundational requirement for personalizing the user experience and maintaining data integrity.
- Contributors: Szymon, Kacper, Alina
- Implementation: Created a comprehensive GitHub Actions CI pipeline separating frontend and backend jobs. It handles API type generation, Docker stack bring-up, Gradle caching, and end-to-end verification.
- Justification: We chose GitHub Actions CI because automated verification is critical for a dual-stack architecture. It addresses the technical challenge of ensuring the API contracts (OpenAPI/AsyncAPI) stay synced with the frontend before merging, preventing regression bugs and broken builds. It deserves module recognition because it significantly stabilized our development workflow.
- Contributors: Zyta
As Project Manager and Developer, Kinga guided the project through its full development lifecycle — structuring task distribution, organizing hybrid team meetings, and coordinating work across sub-teams — while also contributing hands-on to the codebase. She shaped the application's visual identity from the ground up, designing high-fidelity mockups and feature visualizations in Canva that served as the team's shared reference point for UI/UX work. Beyond the design work itself, she was directly involved in bringing that vision into the product, collaborating with the frontend team on translating the mockups into the interface and helping integrate them with the existing codebase. She authored the project's Confluence documentation, architecture diagrams, and feature specifications, and maintained the repository's Documentation folder as the team's centralized knowledge base. She also implemented the Real-Time Chat Module, managed pull requests and code reviews with the Technical Lead, and drafted and integrated the Privacy Policy, Terms of Service, and Open-Source License.
As Frontend Developer, Designer, and Product Owner, Zyta owned the application's visual language — from the semantic token layer and runtime theming to the shared component library — and delivered the identity and social surfaces of the SPA. She later brought the whole frontend to WCAG 2.1 AA and added four-language support with right-to-left layout. On the infrastructure side, she introduced the project's CI pipeline and took ownership of the build environments and their verification.
- Design System: Built a semantic design-token layer (
surface,on-surface,primary,elevated-*,success,danger) so pages and components consume intention-revealing theme roles instead of hardcoded palette colors — the change that made re-theming possible at all. - Theming: Implemented a three-way runtime theme switcher (42Hub / Catppuccin Mocha / Catppuccin Latte) driven by a single source of truth in
lib/theme.ts, with Tailwind'sdarkvariant rebound fromprefers-color-schemeto the theme class and a blocking pre-hydration script that applies the stored flavour before first paint. Adding a fourth flavour is one array entry plus one CSS block — no component changes. - Component Library: Extracted the component library the tokens imply — primitives (
Button,Card,TextField,AccentLink,Tag,Avatar,PresenceAvatar) and composites (SessionCard,ContactBlock,LegalSection,Hero,Footer,BareLayout,ThemeToggle) — reducing pages to composition and auditing every page to route colors through the token layer. - Route Architecture: Restructured the app into route groups so unauthenticated routes stop rendering the app sidebar, and inverted dependencies in shared components (
UserSearchparameterised over its search and action renderers) so they are reusable beyond the flow they were born in. - Visual Identity: Introduced the 42Hub palette as an additive brand-token layer with dedicated gradient utilities, applied across the app shell, navigation, and CTAs.
- Design Migration: Completed the migration to the new design — split border roles into
dividerandedge, themed the light-page shadows, switched the sans font to Manrope, and retired the parallel legacy palettes so every color now flows through the token layer. Added a custom icon set to the interface.
- User Profile: Replaced the hardcoded mock profile with a live per-user page — a server component fetching real user details with 401/403/404 handling, inline display-name editing, and avatar upload with modal, file picker, and preview via Next.js Server Actions.
- Session Handling: Wired the authenticated session through the UI entirely server-side (no client-side cookie reads): login/logout flows, an auth-layout guard for already-authenticated visitors, and session-aware sidebar and landing page.
- Friends System: Built the friends feature end-to-end — user search with pagination, add/remove friendships, and a friends list with avatars, names, and live rendering — using Server Actions over the typed
openapi-fetchclient, with profile ownership derived server-side so visitors never see the owner's controls. - Chat UI: Delivered the chat screen in the new design language (friend rail, conversation, message bubbles, composer) as a presentational split with all placeholder data isolated in a single fixtures module, so the data layer is wired in by replacing one file rather than restructuring components.
- State Handling: Introduced a shared
useAsyncActionhook to manage loading and error state consistently across friend and profile actions. - Forms & Navigation: Added client-side form validation (including login email validation), linked friends-list entries to their profiles, and made the legal pages publicly reachable without signing in.
- Public API Page & Rebrand: Added a public API documentation page and rebranded the application to JustPlay42, aligning the name and hero copy across every language.
- Contrast: Re-tuned the token layer so text and controls meet AA contrast in all three themes, including a dedicated on-CTA token and a re-pointed footer band on the start page.
- Keyboard & Structure: Added a skip link, per-page titles, landmark regions, and keyboard-reachable scroll regions; built a reusable
Dialogcomponent on the native<dialog>element for correct focus handling. - Screen Readers: Added a live-region announcer so incoming chat messages are spoken, and gave form fields programmatic required-state labels and
autoCompletehints. - Enforcement & Verification: Switched
eslint-plugin-jsx-a11yto strict mode, scanned every route in all three themes with axe-core driven by Playwright, and completed a manual NVDA screen-reader pass.
- Multi-language Support: Added English, Polish, French, and Arabic translations across the application, with right-to-left layout for Arabic.
- Continuous Integration: Introduced the project's GitHub Actions CI pipeline, splitting frontend and backend into separate jobs for sound technical reasons: the frontend job brings up the full Docker stack because API types are generated at CI time from live OpenAPI/AsyncAPI endpoints, while the backend job uses native service containers to enable Gradle caching. Added Docker Buildx layer caching and healthcheck-gated startup to remove race-condition flakiness.
- Dual Build Profiles: Established the two supported builds as single-command flows — the Docker dev/eval build (
make, fully nginx-fronted over HTTPS on port 8443) and the local frontend-development build (make frontend-local, host-runnext devagainst a loopback-only backend). - HTTPS Enforcement: Closed the backend's host-published port so it is reachable exclusively through nginx's TLS termination, satisfying the HTTPS-only requirement.
- nginx Routing: Introduced dynamic upstream resolution and explicit prefix rewriting in nginx, breaking a startup circular dependency between nginx, the frontend image build, and API type generation.
- Build Reliability: Repaired the root-to-service Makefile chain and added content-based staleness tracking, so
make uprebuilds images only when their build context actually changed. Made the shared Docker network creation idempotent and fixed the environment strategy (.env+ optional.env.local) so local and containerized runs stay consistent. - Automated Verification: Authored
docs/env_verification.sh— an end-to-end check of both builds covering HTTPS routes, closed backend ports, loopback isolation, and cross-build leak checks.
- Re-theming was impossible: Pages used hardcoded palette colors, so a new theme meant editing every component. Introducing semantic tokens and auditing every page to use them turned a theme change into a single CSS block.
- Startup circular dependency: nginx needed the frontend running, the frontend image build needed generated API types, and type generation needed nginx. Dynamic upstream resolution and explicit prefix rewriting in nginx broke the cycle.
- Flaky, slow CI: Jobs failed intermittently when tests started before services were ready. Healthcheck-gated startup removed the races, and Buildx and Gradle caching kept runs to a few minutes.
- Verifying the chat announcer: NVDA only reads live regions in the focused window, so sending a message from a second browser window could never be heard. A helper script that sends a message as a second user after a delay made the announcement testable.
- Contrast on gradients: axe cannot compute contrast over gradient backgrounds and reports those cases as "incomplete". They were reviewed by hand and fixed by adjusting the tokens.
- RTL side effects: Switching the document to right-to-left also mirrored the language and theme toggles, so the buttons jumped under the pointer when switching languages. The toggle group was pinned left-to-right while the rest of the page, footer links included, still mirrors.
As Technical Lead and Software Architect, Szymon managed the technical side of the project during its initial stages and defined the technology stack and standards. He architected a Hexagonal Spring Boot backend following SOA, DDD, use-case-centric design, separation of concerns, and CQRS, and oversaw the JWT token integration between frontend and backend for the stateless REST API and STOMP WebSocket AsyncAPI. He documented the backend according to Docs as Code, Self-Documenting Code, and Living Documentation principles, used Gradle plugins and test pipelines for diagram and AsciiDoc generation, tested the backend following TDD and BDD practices with Spring context splitting, and integrated Spring WebSockets with Redis.
As DevOps and Database Engineer, Alina designed and maintained the project's infrastructure and database layer. She containerized the backend and frontend applications using Docker, configured PostgreSQL and the Docker Compose environment for local development, and established a shared, idempotent Docker network alongside coordinated environment configuration across Docker Compose and Makefiles. On the database side, she designed and evolved the schema as new features were added, integrated PostgreSQL with the backend using Spring Data JPA, and implemented the repositories. She researched and applied transaction management to keep data consistent, set up database migrations, wrote integration tests for the repository layer, and created and maintained the database documentation, including the entity-relationship diagram.
As Frontend Developer and API Integration Engineer, Kacper led the initial frontend setup, bootstrapping the Next.js application along with its linters, formatters, and initial HTTPS configuration. He developed the integration layer between the Next.js frontend and the Spring Boot backend, implementing the Backend-for-Frontend (BFF) pattern, API web clients, and error handling for the authentication flows. He integrated WebSocket (STOMP) connections on the client side to enable real-time chat and live presence updates, designed the foundational layout for the landing page and profile views, and implemented the chat logic for sending and removing messages, creating conversations with friends, and handling backend connection failures. Additionally implemented the core game logic and UI for a 2048 game (TypeScript, React, Tailwind CSS), including tile movement algorithm, board state management, and component architecture.
This section contains the official documentation, articles, and video tutorials used during the development of this project, combining standard references with AI-assisted research.
- Spring Boot Reference Guide – Foundation for the Java backend.
- Spring Framework Reference – Documentation for core Spring concepts.
- Spring Modulith Documentation – Guidelines for building and structuring modular monoliths.
- Backend-for-Frontend (BFF) Pattern – Architectural explanation of creating dedicated backends tailored for specific frontend applications.
- Spring Security Reference – Implementation guides for Web Security, authentication filters, and authorization.
- Bcrypt Password Hashing – Details on the cryptographic hash function used for securely storing user passwords with salt.
- JSON Web Tokens (JWT) – Open standard defining the compact and self-contained way for securely transmitting information.
- PostgreSQL Documentation – Technical manual for managing relational data, schemas, and relational integrity.
- Redis Documentation – Reference for implementing fast, in-memory caching and session state management.
- Docker Documentation – Official reference for containerizing the application, managing multi-container setups via Docker Compose, and deployment.
- Securiti.ai: What is a Privacy Policy? – A breakdown of data privacy compliance, regulations (like GDPR/CCPA), and data gathering practices.
- Usercentrics: Guide to Terms of Service – Legal guidelines and requirements for implementing user agreements and defining platform liability limits.
- What are Website Policies? (Privacy Policy, Terms of Service, Cookie Policy) – A practical video guide explaining the distinct differences between website policies and why they are critical for user management.
- Open Source Licence Types – An overview of the 5 main categories of open-source licenses (from public domain to copyleft/GPL), explaining how they impact downstream code and dependencies.
In line with the project's AI Instructions, AI tools were used by the team strictly as a supporting resource throughout the learning journey, not as a substitute for the team's own understanding, decision-making, or implementation work.
AI assistance was limited to:
- Supporting the team's learning process when exploring unfamiliar technologies, frameworks, and documentation.
- Helping clarify concepts and technical documentation referenced in the Resources section below.
- Supporting the organization of work and planning of tasks alongside the team's project management tools (Jira, Confluence).
- Assisting in the early ideation of interface concepts and mockups, which were then developed and refined by the team in Canva and implemented in the frontend.
- Acting as a general-purpose and domain-specific prompting aid that helped the team build technical and problem-solving skills during development.
All architectural decisions, feature design, code implementation, and integration of functionality were carried out by the project team. Any AI-assisted input was reviewed, tested, and validated by team members and discussed with peers before being relied upon, consistent with the good-practice approach of using AI to reduce repetitive or tedious tasks while ensuring the team could fully explain and take responsibility for the resulting work.