mukimovd/turash
1
0
Fork 0
mirror of https://github.com/SamyRai/turash.git synced 2025-12-26 23:01:33 +00:00
Code Issues 1 Actions Packages Projects Releases Wiki Activity
60848459f3
turash/bugulma/frontend/BACKEND_ALIGNMENT_STATUS.md
Damir Mukimov 6347f42e20
Consolidate repositories: Remove nested frontend .git and merge into main repository 
- Remove nested git repository from bugulma/frontend/.git
- Add all frontend files to main repository tracking
- Convert from separate frontend/backend repos to unified monorepo
- Preserve all frontend code and development history as tracked files
- Eliminate nested repository complexity for simpler development workflow

This creates a proper monorepo structure with frontend and backend
coexisting in the same repository for easier development and deployment.
2025-11-25 06:02:57 +01:00

2.8 KiB
Raw Blame History

Backend Alignment Status

Current State

The frontend is fully aligned with the organization-based architecture. All schemas and API calls use organization terminology. The backend database will be updated directly, so no legacy field support is needed.

Frontend Alignment

✅ Schemas (Clean - No Legacy Fields)

Site Schema (schemas/backend/site.ts):

  • Request field: owner_organization_id ✅
  • Response field: OwnerOrganizationID ✅
  • No legacy fields - clean schema

Resource Flow Schema (schemas/backend/resource-flow.ts):

  • Request field: organization_id ✅
  • Response field: OrganizationID ✅
  • No legacy fields - clean schema

✅ API Endpoints (Clean - No Fallbacks)

Sites API (services/sites-api.ts):

  • Endpoint: /api/sites/organization/:organizationId ✅
  • No fallback - expects backend to be updated

Resources API (services/resources-api.ts):

  • Endpoint: /api/resources/organization/:organizationId ✅
  • No fallback - expects backend to be updated

✅ Request Payloads

Create Site (components/add-organization/AddOrganizationWizard.tsx):

  • Uses: owner_organization_id ✅
  • Ready for backend refactoring

Create Resource Flow (lib/resource-flow-mapper.ts):

  • Uses: organization_id ✅
  • Ready for backend refactoring

Backend Refactoring Checklist

When backend is updated, verify:

API Endpoints

  • /api/sites/organization/:organizationId exists
  • /api/resources/organization/:organizationId exists
  • Old /business/ endpoints can be removed (or kept for backward compatibility)

Request Fields

  • owner_organization_id accepted in site creation
  • organization_id accepted in resource flow creation

Response Fields

  • Sites return OwnerOrganizationID (not OwnerBusinessID)
  • Resource flows return OrganizationID (not BusinessID)

Backend Requirements

For the frontend to work correctly, the backend must:

  1. Database Migration: Update database columns:

    • sites.owner_business_id → sites.owner_organization_id
    • resource_flows.business_id → resource_flows.organization_id

  2. API Endpoints: Implement new endpoints:

    • /api/sites/organization/:organizationId
    • /api/resources/organization/:organizationId

  3. Request Fields: Accept new field names:

    • owner_organization_id in site creation
    • organization_id in resource flow creation

  4. Response Fields: Return new field names:

    • OwnerOrganizationID in site responses
    • OrganizationID in resource flow responses

Notes

  • Frontend schemas use only organization terminology (no legacy support)
  • All frontend code expects the new field names
  • No fallback logic - backend must be updated for frontend to work
  • Database migration can be done directly (as mentioned by user)