Api
Modular monolith API for core church data with CI/CD pipelines, automated testing, and multi-environment deployment support.
Ficha actualizada 22 sept 2026, 18:30 · upstream 22 sept 2026, 18:05 · release sin release detectada
Qué es Api
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
This repository contains the complete source code for a modular monolithic API designed to manage core church data including membership records, attendance tracking, content management, giving/tithing systems, and messaging. The architecture is built on Node.js with TypeScript as the primary language, featuring a layered microservices approach where each domain (membership, attendance, content, giving) operates as an independent service that communicates through a centralized API gateway. The system includes comprehensive CI/CD pipelines using GitHub Actions for automated testing, deployment to demo/staging/prod environments, database migrations, and health monitoring. Security is prioritized with secret scanning, dependency vulnerability checks, IAM role separation by environment, and production-grade smoke tests before any live deployment.
- Manage church membership records including registration, updates, and lifecycle management
- Track attendance patterns for members and events through configurable calendar systems
- Store and manage church content such as sermons, articles, and multimedia materials
- Process giving and tithing transactions with multi-currency support and reconciliation
- Communicate with members via email templates, SMS notifications, and web portals
- Monitor system health through automated health checks and performance metrics
- Implement security measures including role-based access control and data encryption at rest
- Automated database migrations for schema evolution across different environments
- Fully modular monolith architecture with independent services communicating via a centralized API gateway
- Comprehensive CI/CD pipeline using GitHub Actions supporting automated testing, security scanning, and multi-environment deployment
- Supports MySQL for relational data storage with comprehensive test coverage including integration tests and database connectivity validation
- Uses Node.js runtime with TypeScript for type safety across the entire codebase
- Includes automated weekly maintenance workflows including demo environment cleanup and dependency updates
- Provides health check endpoints that run every 15 minutes to monitor API availability, database connections, and performance metrics
- Supports AWS Lambda functions for serverless deployment with configurable timeouts and memory limits per service
- The demo environment is not fully isolated from production in terms of security configuration; it requires manual approval before any changes can be deployed to production
- Database migrations are run manually via workflow dispatch rather than through a declarative schema evolution tool, which may increase operational overhead for teams unfamiliar with the process
- No explicit rate limiting or throttling is documented on the API endpoints, though this may be handled by the underlying Lambda function configuration
- The system relies heavily on external dependencies (AWS S3/MinIO for storage, Slack for notifications) which introduce points of failure if those services are unavailable
- Security scanning via Snaky is optional and not enabled by default in all environments, meaning vulnerabilities may exist that are only discovered after deployment
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Deploy to demo environment using `gh workflow run deploy-demo.yml` for automatic deployment with database setup. Deploy to staging using `deploy-staging.yml` which includes integration testing and performance monitoring. For production deployments, use `deploy-prod.yml` which requires manual confirmation via the `-f confirm_production=<value>` flag before triggering the workflow. Always test in staging first. Use environment-specific secrets for AWS credentials (stored in AWS Parameter Store) and external service tokens. Database URLs are managed via environment variables or AWS Parameter Store to prevent hardcoding. Monitor health checks every 15 minutes using `gh workflow run health-check.yml`. For database operations, use `database-migration.yml` with options: init all databases, reset with fresh data, migrate specific modules, or select an environment. Keep dependencies updated weekl
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.