opalescentt/haven

1. Overall shape

- This is a Next.js App Router application with both UI pages and server API routes in the same repo.

- The architecture is centered on a MongoDB-backed application server, with Next.js handling rendering, routing, and API access.

2. Primary product areas

- The UI is organized around a few user-facing modules: child profile, staff directory, resources map, partner organizations, and support groups.

- These correspond to the repository’s main care-coordination concepts: children, staff, events, registrations, and community resources.

3. Frontend boundary

- Pages live under app/*/page.js, so the main presentation layer is route-based rather than component-library driven.

- Shared UI is kept in components/, including the Navbar and a small set of reusable widgets like the calendar dropdown and support-group icons.

- app/layout.js, app/providers.js, and app/globals.css provide the global shell, app-wide providers, and styling baseline.

4. Server/API boundary

- The operational backend is implemented as Next.js route handlers under app/api/*/route.js.

- Key API domains are:

- auth for login/session handling

- user for user profile data

- children for child records, including an individual-child subroute

- events for event retrieval and management

- registrations for signups or attendance records

- staff and staff-directory for staff-facing data

- This keeps the public UI thin and pushes business logic into server routes.

5. Authentication and request gating

- Authentication is built around NextAuth via app/api/auth/[...nextauth]/route.js.

- middleware.js likely protects selected routes and enforces session-aware access control.

- The architecture suggests a split between public informational pages and protected or role-aware workflows for sensitive child-related data.

6. Data model layer

- MongoDB integration is encapsulated in lib/mongodb.js.

- The domain models are defined in models/:

- User

- Child

- Event

- Registration

- This implies a classic app-server pattern: route handler → model → database, with the models acting as the schema and validation boundary.

7. Sensitive child data handling

- lib/childEncryption.js indicates that child records contain sensitive fields encrypted at the application layer rather than stored fully in plain text.

- That is an important architectural boundary: child data is not just stored; it is intentionally protected before persistence and likely decrypted only where needed by trusted server-side code.

8. Event and community workflows

- Events are first-class domain data, with constants in lib/constants/events.js and a seeding script in scripts/seed-events.js.

- The registrations API and models/Registration.js show a flow where users can discover events and register for them.

- lib/utils/calendar.js and the calendar dropdown component suggest the UI includes date-based browsing or filtering of events.

9. Resource discovery and directory data

- staff-directory, partner-organizations, and resources-map pages indicate the app is also a resource navigation layer, not just a case-management tool.

- Static reference data appears to be centralized in lib/constants/partners.js and lib/constants/features.js, which likely drive what is shown in these directory-style views.

10. Support-group ingestion pipeline

- The app/support-groups/ folder includes parser scripts such as alliancecares_parser.cjs and amara_parser.cjs.

- That suggests support-group content is partially ingested from external sources and normalized into app-friendly data rather than manually authored only.

- The support groups page likely consumes this parsed output to show organizations and contact/resource details.

11. Auxiliary classification tooling

- The classifier/ directory contains Python code for classifier.py, classifier-test.py, and sensitive_info_detector.py.

- This looks like an offline or batch-oriented analysis tool, likely used to classify text and detect sensitive information in imported content.

- It is separate from the main Next.js request path, which makes it an auxiliary processing subsystem rather than a runtime dependency of the UI.

12. Operational scripts and automation

- scripts/fetch-places.js suggests external data enrichment, likely pulling place or location data for the resources map.

- .github/workflows/weekly-scrape.yml shows the repo has scheduled automation, probably to refresh community/support data on a cadence.

- These scripts form an ingestion/maintenance layer around the core app.

13. Data flow summary

- The main flow is: user visits a Next.js page → authenticated session is checked → page calls an API route → route reads/writes MongoDB models → response drives the UI.

- For sensitive child data, the flow includes an extra encryption/decryption step in the server layer.

- For support resources and directory content, there is an additional external-source scrape/parse step before data lands in the app.

14. Diagram boundaries to show

- A good architecture diagram should separate:

- Client/UI pages

- Next.js server routes

- Authentication/session layer

- MongoDB persistence

- Sensitive-data encryption

- External ingestion jobs and parsers

- Python classification utilities

- Those are the meaningful boundaries in this repository; everything else is supporting implementation detail.