CareForAll Platform

CareForAll is a modular (polyrepo-oriented) platform composed of multiple domain services and a Next.js frontend, targeting a healthcare / philanthropy scenario (authentication, campaigns, pledges, payments, totals aggregation, and chat). This repository groups service directories (they may be individual repos or submodules) to simplify local orchestration and development.

NOTE: In a true polyrepo setup each service would reside in its own repository. This grouped repo acts as an integration/workspace layer. An API Gateway / Global Load Balancer should be provisioned as a separate dedicated repository (see "API Gateway (Planned)" section).

Architecture Overview

The system is service‑oriented with clear bounded contexts:

• service_auth: User authentication, JWT issuance, account management.
• service_campaign: Campaign creation and management.
• service_pledge: Pledges tied to campaigns, domain logic around commitments.
• service_totalservice: Aggregates totals (likely consumes events or queries other services).
• service_payment: (Placeholder) Will handle payment processing/workflows.
• service_chat: (Placeholder) Real‑time or asynchronous chat/messaging.
• service_frontend: Next.js application (careforall) consuming the above APIs.

Each backend service is a Django project with its own manage.py, settings.py, SQLite dev DB, and Dockerfile. The frontend uses Next.js + TypeScript.

Services Summary

Service	Stack	Purpose	Directory
Auth	Django, DRF, JWT	Authentication & token issuance	service_auth/auth/
Campaign	Django, DRF	Campaign lifecycle & metadata	service_campaign/campaign/
Pledge	Django, DRF	Pledges against campaigns	service_pledge/pledge/
Totals Service	Python (app.py)	Aggregation / summary totals	service_totalservice/totals-service/
Payment	(Planned)	Payment flows & reconciliation	service_payment/
Chat	(Planned)	Realtime or async communication	service_chat/
Frontend	Next.js 14+, TS	Web UI	service_frontend/careforall/

Tech Stack

• Backend: Python 3 + Django + Django REST Framework (per service) + JWT custom logic.
• Frontend: Next.js, React, TypeScript, Tailwind/PostCSS.
• Datastore (dev): SQLite (per service). Production should prefer PostgreSQL.
• Containerization: Docker (each service has a Dockerfile; local compose files per service).
• Event / Aggregation: totals-service Python app (future: message broker integration e.g., Redis, RabbitMQ, Kafka).

Local Development Options

You can develop services in two ways:

1. Run each Django service directly via Python (virtualenv) for quick iteration.
2. Use each service's Dockerfile and local docker-compose.yaml to containerize.

Because compose files are currently inside individual service folders, cross‑service networking requires either:

• A root-level compose file (future improvement), or
• Manually specifying network aliases and ports when running containers.

Prerequisites

• Python 3.11+ (verify version compatibility with existing code).
• Node.js 18+ (for Next.js).
• Docker Desktop (Windows) + WSL2 enabled.

Backend: Running a Service (Auth Example)

# From repo root
cd service_auth/auth
python -m venv .venv; .\.venv\Scripts\activate
pip install -r ..\requirements.txt
python manage.py migrate
python manage.py runserver 0.0.0.0:8001

Repeat similarly for campaign (8002), pledge (8003), etc. (Assign ports uniquely.)

Frontend

cd service_frontend/careforall
npm install
npm run dev

Visit http://localhost:3000.

API Gateway (Planned)

A dedicated repository (e.g., careforall-gateway) will:

• Provide a single public ingress (https://api.careforall.example).
• Perform path-based routing (/auth/*, /campaign/*, /pledge/*, /totals/*).
• Optionally handle load balancing, rate limiting, caching, request logging, and global security headers.

Recommended solutions:

• Simplicity: NGINX or Traefik in Docker.
• Full-featured: Kong, Tyk, OR cloud managed (Azure API Management, AWS API Gateway).

Example path plan:

/auth/ -> Auth Service (8001)
/campaign/ -> Campaign Service (8002)
/pledge/ -> Pledge Service (8003)
/totals/ -> Totals Service (8004)
/payment/ -> Payment Service (future)
/chat/ -> Chat Service (future)

Environment Variables (Suggested Standardization)

Standardize an .env file per service with keys like:

DJANGO_SECRET_KEY=changeme
DJANGO_DEBUG=True
DATABASE_URL=sqlite:///db.sqlite3   # For dev; use postgres in prod
JWT_SECRET=changeme
ALLOWED_HOSTS=*
SERVICE_NAME=auth

For production: rotate secrets, disable debug, set explicit ALLOWED_HOSTS, externalize DATABASE_URL.

Database Strategy

• Dev: SQLite for simplicity.
• Prod: PostgreSQL (shared cluster or per-service DB). Each service should own its schema; avoid cross-service DB coupling.
• Migrations: Keep Django migrations versioned and run via CI/CD.

Testing

Each Django service includes a tests.py (empty or minimal). Expand to cover:

• Serializers validation.
• Views / endpoints (auth flows, pledge creation).
• Permissions & JWT expiry. Run tests example:

cd service_auth/auth
pytest  # If pytest configured, else: python manage.py test

Add pytest & pytest-django to requirements.txt for richer testing.

Suggested Improvements (Roadmap)

• Root-level docker-compose.yml to orchestrate all services with one command.
• Central .env.example for gateway + shared settings.
• Replace SQLite with Postgres + a message broker (for totals aggregation & eventual consistency).
• Add observability: structured logging, metrics (Prometheus), tracing (OpenTelemetry).
• Implement CI pipelines (GitHub Actions) per service + integration tests.
• Harden security: rate limiting, input validation, dependency scanning.

Deployment

Production recommendations:

• Containerize each service; push images to a registry (e.g., GHCR / ACR).
• Use an orchestrator (Kubernetes, Azure Container Apps, ECS) or simpler Compose for small scale.
• Place API Gateway / Ingress Controller in front of services.
• Use HTTPS everywhere; manage certificates via Let's Encrypt / cert-manager.
• Externalize secrets using a vault (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault).

Directory Structure (Condensed)

service_auth/
service_campaign/
service_pledge/
service_totalservice/
service_payment/            # Placeholder
service_chat/               # Placeholder
service_frontend/careforall/

Each service: Dockerfile, docker-compose.yaml, requirements.txt, Django project root.

Contributing

1. Fork or clone the relevant service repository.
2. Create a feature branch: git checkout -b feature/x.
3. Add/modify code & tests.
4. Run linting/tests locally.
5. Open a Pull Request referencing related issue.

Security

• Never commit real secrets. Use .env excluded via .gitignore.
• Keep dependencies updated; run pip list --outdated and npm audit.
• Consider SAST/Dependency scanning (Dependabot, CodeQL).

License

(Choose and add a license file, e.g., MIT, Apache-2.0. Placeholder here.)

Maintainers

• Add team / contact information here.

FAQ

Why separate gateway repo? Maintains clear ownership, independent scaling and deployment pipeline. Why Postgres for prod? Reliability, concurrency, migrations, better scaling than SQLite. Can services share a DB? Prefer separate schemas/databases to preserve boundaries and minimize coupling.

---

Feel free to open issues for missing documentation, enhancement proposals, or architectural discussions.