Architectural Patterns Demo 1

Architectural Patterns

Mealchemy follows a layered 4-tier architecture combined with a client-server communication model. The system is separated into presentation, business logic, data access, persistence, and recommendation-processing responsibilities. This separation of concerns improves maintainability, modularity, scalability, and independent development across frontend, backend, database, and recommendation components.

Client-Server Architecture

Mealchemy follows a client-server architecture. The mobile frontend acts as the client and is responsible for presenting the user interface and capturing user interactions. The backend server is responsible for processing requests, enforcing business rules, managing authentication, coordinating recommendation processing, and accessing stored application data.

The frontend does not communicate directly with the database. All requests and data operations are routed through the backend to ensure security, validation, and consistent application behaviour.

Layered 4-Tier Architecture

The backend follows a layered structure where each layer has a specific responsibility:

• Controller Layer: Receives requests from the frontend and returns responses.
• Service Layer: Contains business logic, validation, and application rules.
• Repository Layer: Handles data access and persistence operations.
• Entity/Model Layer: Represents persistent application data.

Mealchemy also applies MVC style separation within this layered architecture. Controllers manage incoming HTTP requests, models/entities represent application data, and services coordinate business logic before data is accessed through repositories.

This structure improves modularity and maintainability by separating request handling, business logic, and database access responsibilities.

Recommendation Sidecar Architecture

Mealchemy includes a modular recommendation sidecar responsible for heuristic-based recommendation processing. The recommendation sidecar supports:

• Preference filtering
• Pantry matching
• Recipe ranking

The recommendation sidecar operates independently from the main backend persistence layer and does not directly access the database. Instead, it communicates with the backend through dedicated API endpoints that provide recommendation context and preference data. The backend remains responsible for data persistence, validation, and ownership checks.

Separating recommendation processing from the core backend improves modularity and allows recommendation functionality to evolve independently while remaining integrated with the main application services.

Repository Pattern

Mealchemy uses the Repository Pattern to separate business logic from persistence operations. Services interact with repositories rather than directly querying the database.

Repositories are responsible for retrieving, storing, and updating persistent application data such as users, recipes, pantry ingredients, shopping lists, and preferences.

This pattern improves maintainability, testability, and separation of concerns by isolating database access logic from application services.

Client-Side State Management

The frontend follows a provider-based state management pattern using Riverpod. Application state is managed through providers rather than directly within UI components.

This approach keeps the frontend modular and improves separation between presentation logic, business logic, and data retrieval. It also supports dependency injection and allows frontend components to switch between mock repositories and backend repositories during development and testing.