[Architecture/Refactor]: Implement a Centralized Service Layer for Appwrite API Integration

[cannonerd007]

Is your feature request related to a problem?

• Yes, it is related to a problem

Describe the feature you'd like

Problem Description While contributing to AOSSIE-Org/Resonate, I noticed that the current architecture in BabyNest has some technical debt regarding how it interacts with the backend. Currently, Appwrite client initialization and database logic are scattered across various function files and UI components. This leads to:

Tight Coupling: Business logic is mixed with database calls.

Inconsistent Responses: Error handling varies between functions, making it difficult for the frontend to parse errors predictably.

Maintenance Difficulty: Collection IDs and Environment variables are repeated in multiple files.

Proposed Solution I propose to refactor BabyNest to follow the Service-Repository Pattern utilized in other AOSSIE projects like Resonate. This will involve:

Centralized Provider: Create a singleton AppwriteProvider to manage the Client and Database instances.

Domain-Specific Services: Move logic into dedicated service files (e.g., src/services/authService.js, src/services/roomService.js).

Unified Response Wrapper: Implement a standard response format (e.g., { success: boolean, data: any, error: string }) to unify how the Appwrite functions return data.

Constants Management: Move all magic strings (Collection/Database IDs) into a central configuration file.

Expected Impact This refactor will bring BabyNest up to the organizational standard of AOSSIE. It will make the codebase significantly more scalable for the GSoC 2026 cycle and simplify the onboarding process for new contributors.

Record

• I agree to follow this project's Code of Conduct
• I want to work on implementing this feature

[cannonerd007]

Hi @bhavik-mangla and @Zahnentferner, I've worked on the Resonate backend and website before and would like to help bring some of those architectural standards to BabyNest. May I be assigned to this?

[cannonerd007]

Phase 1: Proposed Technical Roadmap
To implement the centralized service pattern, I plan to follow these steps to ensure zero downtime and clean separation of concerns:

1. Create Centralized Configuration

Define a src/config/appwrite.js to store all Project IDs, Database IDs, and Collection IDs in one place.

This eliminates the "magic strings" currently found in the logic files.

2. Implement a Singleton API Client

Create src/services/apiClient.js to initialize the Appwrite Client, Account, and Databases instances once.

3. Domain-Specific Service Migration I will begin by extracting logic into the following structure:

src/services/authService.js: Handling OTP and session management.

src/services/roomService.js: Managing room creation and joining logic.

src/services/healthService.js: Abstracting weight tracking and milestone CRUD operations.

4. Unified Error Handling

Implement a wrapper function to catch Appwrite exceptions and return a standardized JSON object: { success: boolean, data: any, error: string }.

[sharma-sugurthi]

@cannonerd007 Nice initiative on the Service Pattern.

We are currently in the middle of a massive Frontend Refactor in Issue #151 (led by @dheeraj12347) that overlaps with this.

Potential Conflicts:

1. src/services/apiClient.js: Dheeraj is already implementing this file to handle the Python Backend connections (which are required for the AI/RAG features).
2. healthService.js: The weight/milestone logic is currently being routed to the Python backend to support the AI Agent. Moving this to Appwrite might break the RAG system's ability to "see" that data.

Could we rename your client to src/services/appwriteClient.js?
Also, we should sync on which data stays in Appwrite (Auth?) vs which data goes to Python (Health/AI?) to avoid database issues.

[cannonerd007]

Hi @sharma-sugurthi, thank you for the detailed feedback! I completely agree with your points regarding the potential conflicts with the Python backend work in Issue #151.

Updated Plan:

I will rename the core client to src/services/appwriteClient.js to avoid any confusion with the Python service.

I will exclude healthService.js from this refactor to ensure we don't break the AI Agent's RAG system data flow.

I'll focus purely on Auth and Room services as these are strictly Appwrite-dependent.

I'm ready to begin with these adjustments once assigned. @bhavik-mangla, may I proceed with this narrowed scope?

[ambatimaneesha2002]

Hi maintainers
I’ve carefully gone through the discussion and the updated scope
(Appwrite-only services: Auth & Room).

I’m currently learning the BabyNest codebase and would love to help
with smaller refactor tasks or documentation related to this issue
if needed.

Please let me know how I can contribute. Thanks!