Building the Hymnal 1982 Web App: A Look at the Tech Stack
As I work on developing the Hymnal 1982 web app for Episcopal church musicians, I’ve chosen a tech stack that emphasizes scalability, maintainability, and flexibility. This article provides a detailed breakdown of the technologies I’m using and why they’re the right fit for this project.
The Problem the Tech Stack Solves
My goal for the Hymnal 1982 web app is to streamline access to the hymnal’s contents, help musicians and clergy easily search for hymns, and simplify the planning and collaboration process for worship services. To achieve this, I need a tech stack that:
Scales well to support multiple churches and users.
Processes data efficiently, allowing quick access to hymn metadata, lyrics, and recordings.
Supports collaboration between musicians and clergy.
Ensures reliability while maintaining the flexibility to add new features over time.
With these goals in mind, I’ve selected the following technologies to form the foundation of the application.
Frontend: React + TypeScript
For the user interface, I’m using React paired with TypeScript.
Why React?
Component-Based Architecture: React’s component-based architecture allows me to break down the app’s interface into reusable pieces, like hymn lists, search bars, and planning tools. This makes the code more modular, maintainable, and scalable.
Interactive UI: React is optimized for creating dynamic, responsive interfaces, which is essential for providing users with real-time feedback when they search for hymns or plan services.
React Hooks: With React Hooks, I can manage state and side effects in a clean, declarative way. This simplifies the complexity of managing data flow in the app.
Why TypeScript?
Static Typing: TypeScript’s static typing catches errors early in development and provides better autocompletion and documentation as I work with the codebase. This is especially useful for complex apps with many components and interactions.
Scalability: As the app grows, TypeScript will help maintain the stability and predictability of the code, making it easier to onboard collaborators or contribute new features.
Backend: AWS Lambda, Entity Framework Core, and SQL Database
The backend of the Hymnal 1982 app is built using AWS Lambda for serverless compute, Entity Framework Core for database interactions, and a SQL database for structured hymn data storage.
Why AWS Lambda?
Serverless and Cost-Effective: AWS Lambda is a serverless compute service that scales automatically. This means I don’t need to worry about provisioning or managing servers. I only pay for the compute time I actually use, making it a cost-effective solution for handling traffic spikes during busy church seasons.
Event-Driven: Lambda functions are triggered by events, such as API requests. This aligns perfectly with the app’s workflow, where each user action (e.g., searching for a hymn) triggers a function to fetch data or perform some logic.
Why Entity Framework Core (EF Core)?
ORM for SQL: EF Core is a powerful object-relational mapper (ORM) that simplifies database access and operations. It allows me to interact with the SQL database using C# objects, reducing the need for writing complex SQL queries manually.
Database Migrations: With EF Core, I can easily manage and apply database schema changes as the app evolves, ensuring that the SQL database remains in sync with the app’s requirements.
Strong Typing and LINQ: EF Core supports LINQ, which lets me query the database using strongly-typed C# syntax. This provides a more intuitive and error-resistant way to handle data retrieval, such as finding hymns by title or composer.
Why SQL Database?
Structured and Relational Data: Since hymns, composers, and liturgical seasons have structured relationships, a relational database like PostgreSQL or MySQL (both supported by Amazon RDS) is the best fit. For example, I need to ensure that each hymn is correctly linked to its composer and associated seasons.
ACID Transactions: For critical operations, such as saving hymn plans for services, having ACID-compliant transactions ensures data consistency and integrity. This is crucial for maintaining an accurate record of hymn selections and service planning.
API Layer: AWS API Gateway + GraphQL
Why AWS API Gateway?
Routing and Integration: AWS API Gateway acts as the interface between the frontend and backend. It handles incoming API requests from the frontend and routes them to the appropriate AWS Lambda functions.
Security: API Gateway can be configured to handle authentication, authorization, and rate limiting, which will help ensure that the app is secure and able to handle varying traffic loads.
Why GraphQL?
Flexible Querying: While I’m still considering whether to use GraphQL or REST, GraphQL is a strong contender because it allows clients (the frontend) to request exactly the data they need. This is particularly useful for complex entities like hymns, where users might need to query specific fields (e.g., title, composer, lyrics) without loading unnecessary data.
Efficient Data Fetching: GraphQL reduces over-fetching and under-fetching by allowing clients to specify the structure of the response. This means faster load times and a more efficient use of Lambda resources.
Data Storage: Amazon RDS for PostgreSQL or MySQL
For the relational database, I’m considering Amazon RDS with either PostgreSQL or MySQL.
Why Amazon RDS?
Managed Service: Amazon RDS provides automated backups, patching, and scaling, so I can focus on building features without worrying about the underlying infrastructure. This also ensures high availability and reliability.
Security and Compliance: RDS provides features like encryption at rest, multi-AZ (availability zones) deployment, and automated backups, which are essential for maintaining data integrity and security for church-related information.
PostgreSQL vs. MySQL:
PostgreSQL is known for its advanced features like JSON support, complex queries, and extensibility. It’s ideal for scenarios where data integrity and complex querying are essential.
MySQL is a robust and fast relational database that may offer simpler integration and more familiar features depending on the specific requirements of the app.
CQRS and Mediator Pattern: MediatR
To implement CQRS (Command Query Responsibility Segregation) and decouple the app’s logic, I’m using MediatR in the backend.
Why MediatR?
Separation of Concerns: MediatR allows me to separate the logic that handles data retrieval (queries) from the logic that performs actions (commands). This is useful for organizing the codebase and making it easier to scale the backend over time.
Clean Architecture: MediatR promotes clean architecture by keeping each component focused on a single responsibility. Queries and commands are sent through the mediator, which handles the orchestration of the business logic and ensures that the database and API are kept separate from the domain logic.
Deployment and CI/CD: Vercel (Frontend) + AWS CodeBuild (Backend)
For the deployment and CI/CD process, I use Vercel for deploying the frontend of my Hymnal 1982 web app, and AWS CodeBuild for automating the deployment of the backend infrastructure.
Why Vercel for Frontend Deployment?
Seamless Integration with React: Vercel is optimized for frontend frameworks like React, providing an easy and efficient way to deploy static sites and server-rendered applications.
Automatic Deployments: Vercel automatically deploys the frontend whenever I push changes to the repository, providing an out-of-the-box continuous integration workflow. It handles everything from preview deployments to production builds.
Performance and Scalability: Vercel’s global content delivery network (CDN) ensures that my frontend is fast and accessible from anywhere in the world, providing a seamless user experience for musicians and clergy.
Why AWS CodeBuild for Backend Deployment?
Serverless Backend Deployment: AWS CodeBuild integrates smoothly with my backend infrastructure on AWS, making it easy to build, test, and deploy the serverless backend components (like AWS Lambda and API Gateway).
Automated Builds and Deployments: Whenever I push changes to the backend code repository, AWS CodeBuild triggers an automated pipeline that builds the project, runs tests, and deploys the latest version to AWS Lambda.
Seamless Integration with AWS SAM: AWS CodeBuild works hand-in-hand with the AWS Serverless Application Model (SAM), allowing me to define the entire backend infrastructure as code. SAM simplifies the packaging and deployment of AWS Lambda functions, API Gateway routes, and other resources in a reproducible and manageable way.
Conclusion: A Scalable, Flexible Stack for a Church Music App
By leveraging a mix of serverless architecture, scalable databases, and modern web frameworks, I’m building a web app that will make accessing the Hymnal 1982 easier and more efficient for church musicians and clergy. The tech stack was chosen with scalability, maintainability, and ease of use in mind, ensuring that the app can grow alongside the needs of Episcopal church musicians.
Stay tuned for more updates as I continue to develop the app and refine the technology behind it!
Contact Info: For any questions or insights about the project, feel free to contact me at garrett@garrettjohnlaw.com.
