shadab9335/connect-sphere

Purpose and topology

ConnectSphere is a hobby/community platform split into a React UI and three independently deployable Java/Spring services: user/interest identity, social feed, and events. Each backend has its own Maven build, properties, and Dockerfile. No API gateway or orchestration layer is present in the tree.

Entry points

• React bootstraps at ConnectSphereUI/src/index.js, renders application composition from ConnectSphereUI/src/App.js, and selects authenticated versus unauthenticated navigation through ConnectSphereUI/src/navigation/AppNavigator.jsx and ConnectSphereUI/src/navigation/AuthNavigator.jsx.

• Spring Boot service processes start at:

- ConnectSphereBackend/UserAndInterest/src/main/java/com/example/UserAndInterest/UserAndInterestApplication.java

- ConnectSphereBackend/FeedService/src/main/java/com/hobbyconnect/feedservice/FeedServiceApplication.java

- ConnectSphereBackend/EventsService/src/main/java/com/hobbyconnect/eventsservice/EventsServiceApplication.java

Identity, profile, and lookup boundary

UserAndInterest is the authoritative identity/profile domain: registration/login, profiles, interests, and work-location configuration. Its controller → service → repository flow centers on controller/AuthController.java, service/UserService.java, and repository/UserRepository.java; adjacent bounded domains use InterestService and WorkLocationConfigService. Security is configured in config/SecurityConfig.java, while persistent entities include model/User.java and model/Interest.java.

Feed domain

FeedService owns social content and engagement: posts, replies, interactions, and notifications. HTTP requests enter controller/FeedController.java, business operations run through service/FeedService.java, and data is persisted through repositories such as repository/FeedPostRepository.java and repository/PostInteractionRepository.java. The domain model is represented by model/FeedPost.java, model/Reply.java, and model/Notification.java. config/MongoIndexConfig.java indicates database indexing is an intentional concern.

Events domain

EventsService owns event creation and retrieval, with model/Event.java as its aggregate and repository/EventRepository.java as persistence access. Its main request path is controller/EventsController.java → service/EventsService.java → repository. It has its own JWT utility and exception boundary, including util/JwtUtil.java and exception/GlobalExceptionHandler.java.

Cross-service and external boundaries

Feed and Events each contain service/UserServiceClient.java, indicating synchronous dependency on the user service for user-related validation or enrichment rather than shared user persistence. Both also contain local util/JwtUtil.java, so token handling is duplicated at service boundaries. Feed media is abstracted behind service/MediaStorageService.java, an external-storage integration point. Runtime connection/security settings reside per service in their respective src/main/resources/application.properties.

Client flow

The UI’s screen-level features map directly to backend domains: feed at screens/app/FeedScreen.jsx, events at screens/app/EventsScreen.jsx and MyEventsScreen.jsx, and profile/auth onboarding under screens/auth/. Service adapters—services/authService.js, services/feedService.js, services/eventsService.js, services/profileService.js, and services/lookupService.js—are the frontend’s API boundary. src/config.js is the likely central endpoint/runtime configuration boundary.

Infrastructure and operational shape

The backend is Java/Spring Boot packaged with Maven (pom.xml per service) and containerized independently (Dockerfile per service). The UI is a Node/React project defined by ConnectSphereUI/package.json. Database technology cannot be confirmed globally from the tree, but FeedService’s Mongo-specific index configuration materially indicates MongoDB usage there. Data seeders in each backend’s config package support bootstrap/development initialization.