ivonnedpa/sprint-mind-hackathon

1. Top-level shape

- This is a monorepo with two independently runnable applications:

- backend/sprintmind: Spring Boot service

- frontend/sprintmindapp: Angular SPA

- The architecture is split cleanly into a browser UI, a REST backend, and at least one external Atlassian/Jira integration.

2. Backend runtime and entrypoints

- The backend is a Java 17 + Maven Spring Boot application.

- SprintmindApplication is the main bootstrapping class.

- ServletInitializer suggests the backend is also prepared for traditional servlet-container deployment, not just local spring-boot:run.

3. Backend API layer

- controller/HelloController is the simplest demo endpoint, likely serving the /api/hello flow described in the README.

- controller/TicketController is the domain-facing API for ticket-related operations, probably the main functional endpoint set of the hackathon app.

- This controller layer is the boundary between HTTP requests and internal business logic.

4. Backend business/integration layer

- jira/JiraService is the key integration service and likely encapsulates all communication with Atlassian/Jira.

- jira/TicketRequest is the request DTO used to carry ticket creation or ticket action data from the controller layer into the service layer.

- TestAtlassian appears to be a helper or experiment class for validating Atlassian connectivity or API behavior.

5. External system boundary

- The most important external dependency beyond the browser is Jira / Atlassian APIs.

- The probable backend flow is: HTTP request → controller → JiraService → Jira API → response back to controller.

- This is the main place where the repo crosses from application code into a third-party service.

6. Backend configuration and static assets

- src/main/resources/application.properties holds runtime configuration for the Spring app.

- src/main/resources/static/index.html means the backend also contains a small static web entrypoint or fallback page, separate from the Angular app.

- This static content is not the primary UI; it is secondary to the frontend app.

7. Backend tests

- SprintmindApplicationTests provides the backend test harness and confirms the Spring context starts correctly.

- The backend test boundary is focused on application startup rather than deep integration coverage, based on the file layout.

8. Frontend runtime and structure

- The frontend is an Angular application under frontend/sprintmindapp.

- src/main.ts, app.ts, app.html, app.css define the root application shell.

- src/app/sprint-mind/* is the main feature component, indicating the UI is organized around a single primary screen/feature module.

9. Frontend-to-backend communication

- The README states the Angular app calls /api/hello.

- proxy.conf.json forwards local API traffic to the Spring Boot server on http://localhost:8080, which keeps the browser-facing origin simple during development.

- This means the frontend talks to the backend through a dev proxy, not by hardcoding backend URLs in the UI.

10. Frontend deployment boundary

- The frontend runs separately on http://localhost:4200.

- The backend runs on http://localhost:8080.

- In local development, the proxy bridges those two processes; in architecture terms, the browser never directly talks to Jira or other services.

11. Tooling and build system

- Backend: Maven Wrapper (mvnw) keeps the Java build reproducible.

- Frontend: Angular CLI / npm with package-lock.json for deterministic dependency installs.

- The repo is set up to be run as two distinct dev processes rather than one combined build artifact.

12. What to draw in an architecture diagram

- Draw three main nodes:

- Browser / Angular UI

- Spring Boot backend

- External Jira/Atlassian service

- Show two local flows:

- Angular UI → Spring Boot API via proxy during development

- Spring controllers → JiraService → Jira API

- Keep the backend split into controller layer and service/integration layer, since that is the main internal architectural boundary.