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

93 lines
2.8 KiB
Markdown

# 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)