lin0et/dev-projects

1. This is a pnpm/Nx monorepo with three main runtime surfaces: the API backend, several frontend apps, and a shared client-libraries package. The rest of the repo is supporting infrastructure: tests, scripts, config, and CI.

2. The backend lives in api/ and is the central orchestration layer. It is a Node.js service built on Fastify, with MongoDB as the primary database. api/src/index.js boots loaders that wire up Fastify, Mongo, rate limiting, and Inngest.

3. Request handling on the API follows a clear layering: routers expose endpoints, controllers handle HTTP-level coordination, services contain business logic, repositories encapsulate database access, models define Mongo data shapes, and schemas/validators guard request and response contracts. This is the core boundary to diagram for the backend.

4. The backend also owns background and event-driven workflows through api/src/functions/ and the Inngest loader. These jobs cover recurring automation such as SMS drips, rebill handling, order follow-up, shipping updates, and sync tasks, so not all domain work happens through synchronous HTTP requests.

5. External integrations are a major architectural concern in the API. Dedicated adapters under api/src/lib/ and corresponding services wrap third parties such as Konnektive, GogoMeds, MD Integrations, Twilio, Zendesk, AfterShip, Braze, SendGrid, Slack, AWS S3, SmartyStreets, Google Maps/Auth, Facebook, and Genderize. These integrations are isolated behind service boundaries rather than called directly from controllers.

6. Authentication, authorization, and anti-abuse are enforced in middleware and loaders. The API has auth middleware, dashboard whitelisting, SSL/rate-limiting support, and webhook-specific authentication for external callbacks. Error handling is centralized in Fastify middleware, with structured logging and Sentry/Rollbar-style error reporting noted in the README.

7. MongoDB is more than a persistence layer: there are schema/index definitions, migrations, and operational scripts. The repo includes historical migrations, a migration runner config, and helper scripts for seeding, housekeeping, reporting, and data repair, which implies ongoing schema evolution and operational maintenance.

8. The frontend is split by audience and deployment. frontend/employee is the internal/admin/customer-service dashboard, while frontend/patient and the brand-specific patient apps (patient-scoreblue, patient-allamericanpharma, patient-duckymd, patient-scorerx) serve customer onboarding and account experiences. These are separate build targets rather than a single SPA.

9. The patient experience is workflow-driven. The README explicitly calls out PatientRouter-style logic that routes users based on onboarding progress, and the patient app contains distinct pages for survey, checkout, treatment selection, identity verification, billing, shipping, subscriptions, order history, and Zendesk redirection. That workflow is the key client-side state machine.

10. frontend/client-libs is the shared UI/domain package used across the frontends. It provides API client wrappers, shared constants, context providers, forms, models, reusable UI components, routing/auth helpers, and a standalone logger implementation. This is the main reuse boundary between the patient and employee apps.

11. The employee app is optimized for operational tasks and back-office tooling. Its pages focus on user lookup, employee management, order management, user detail views, CS notes, SMS blasts, queue reports, and agent checkout/demographic/survey flows. It consumes the same API and shared client-libs but presents a different operational surface.

12. End-to-end verification is a separate subsystem under e2e-tests/, built with Playwright. It includes environment setup, reusable page objects, fixtures, and flows for guest, customer, and agent scenarios, plus webhook and test-data utilities. This acts as the integration boundary across frontend, API, and external mocks.

13. There is also a small scripts/ workspace for build-time utilities, such as injecting client versions and generating lockfile metadata. These are supporting tools rather than runtime services, but they matter for deployment and release consistency.

14. Local development and deployment are shaped by repo-level infrastructure: Docker Compose, Nginx config templates, a Procfile, GitHub Actions workflows for each app, and shared lint/prettier/tooling packages. This suggests a multi-app release pipeline with shared standards and independently built artifacts.