- 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.
6.2 KiB
Frontend to Backend Migration Review
This document identifies frontend logic that should be moved to the backend, as the app transitions from a frontend-only to a backend-driven architecture.
🔴 Critical - Must Move to Backend
1. Chat/LLM Direct Calls
File: hooks/useChat.ts
Issue: Still directly calling GoogleGenAI API with API keys in frontend.
Current:
const ai = new GoogleGenAI({ apiKey: process.env.API_KEY });
chatRef.current = ai.chats.create({ ... });
Should be:
- Backend endpoint:
POST /api/ai/chat(with streaming support) - Backend endpoint:
POST /api/ai/chat/stream(for streaming responses) - Frontend should only call backend API
Priority: 🔴 HIGH - Security issue (API keys exposed)
2. Proposal Management
File: contexts/PartnershipContext.tsx, data/proposals.ts
Issue: Proposals stored in frontend state and localStorage, not persisted in backend.
Current:
- Proposals stored in React state
- Initial data from
data/proposals.ts - No backend persistence
Should be:
- Backend endpoints:
GET /api/proposals- List proposals (with filters)GET /api/proposals/:id- Get proposal by IDPOST /api/proposals- Create proposalPUT /api/proposals/:id/status- Update proposal statusGET /api/proposals/organization/:orgId- Get proposals for organization
- Frontend should use API hooks
Priority: 🔴 HIGH - Data persistence issue
3. Direct Symbiosis Matching
File: hooks/useDirectSymbiosis.ts
Issue: Business logic for matching needs/offers is in frontend.
Current:
// Frontend loops through organizations and matches needs/offers
for (const otherOrg of otherOrgs) {
for (const need of myNeeds) {
const matchingOffer = otherOrg.offers.find(...);
// ...
}
}
Should be:
- Backend endpoint:
GET /api/matching/organization/:orgId/direct - Returns:
{ providers: [...], consumers: [...] } - Backend uses ResourceFlows for accurate matching
Priority: 🔴 HIGH - Business logic should be on backend
4. Analytics Calculations
File: lib/analytics.ts
Issue: Business analytics calculated in frontend.
Functions:
calculateSymbioticConnections()- Calculates total connectionsanalyzeSupplyAndDemand()- Analyzes top needs/offers
Should be:
- Backend endpoints:
GET /api/analytics/connections- Get connection statisticsGET /api/analytics/supply-demand- Get supply/demand analysisGET /api/analytics/dashboard- Get dashboard statistics
Priority: 🟡 MEDIUM - Performance and consistency
🟡 Medium Priority - Should Move
5. Organization Search/Filtering
File: hooks/useOrganizationFilter.ts
Issue: Search scoring logic (with weights +50, +25, etc.) is in frontend.
Current:
- Client-side filtering and scoring
- Search relevance scoring with custom weights
Should be:
- Backend endpoint:
GET /api/organizations/search?q=...§ors=...&sort=... - Backend handles search indexing and relevance scoring
- Frontend can still do basic client-side filtering for UX (debouncing, etc.)
Priority: 🟡 MEDIUM - Better performance and consistency
6. Similar Organizations
File: lib/organizationUtils.ts, hooks/pages/useOrganizationData.ts
Issue: Finding similar organizations by sector is done in frontend.
Current:
return organizations
.filter((org) => org.ID !== organization.ID && org.Sector === organization.Sector)
.slice(0, 5);
Should be:
- Backend endpoint:
GET /api/organizations/:id/similar?limit=5 - Backend can use more sophisticated similarity algorithms
- Could consider: sector, location, resource flows, etc.
Priority: 🟡 MEDIUM - Could be enhanced on backend
🟢 Low Priority - Optional
7. Client-Side Filtering/Sorting
File: hooks/useOrganizationFilter.ts (sorting part)
Current: Client-side sorting by name, sector, etc.
Note: This is acceptable for small datasets. For large datasets, should use backend pagination and sorting.
Priority: 🟢 LOW - Acceptable for MVP, optimize later
Summary
Immediate Actions Required
- ✅ Move Chat to Backend API - Security issue
- ✅ Move Proposals to Backend - Data persistence
- ✅ Move Direct Symbiosis to Backend - Business logic
- ✅ Move Analytics to Backend - Performance
Backend Endpoints Needed
Chat
POST /api/ai/chat- Send messagePOST /api/ai/chat/stream- Streaming chat (SSE or WebSocket)
Proposals
GET /api/proposals- List proposalsGET /api/proposals/:id- Get proposalPOST /api/proposals- Create proposalPUT /api/proposals/:id/status- Update statusGET /api/proposals/organization/:orgId- Get by organization
Matching
GET /api/matching/organization/:orgId/direct- Direct symbiosis matches
Analytics
GET /api/analytics/connections- Connection statisticsGET /api/analytics/supply-demand- Supply/demand analysisGET /api/analytics/dashboard- Dashboard stats
Organizations
GET /api/organizations/search- Search with filtersGET /api/organizations/:id/similar- Similar organizations
Migration Checklist
- Create backend chat endpoints
- Update
useChat.tsto use backend API - Create backend proposal endpoints
- Update
PartnershipContext.tsxto use API hooks - Create backend direct symbiosis endpoint
- Update
useDirectSymbiosis.tsto use backend API - Create backend analytics endpoints
- Update analytics usage to use backend API
- Create backend organization search endpoint
- Update
useOrganizationFilter.tsto use backend search - Create backend similar organizations endpoint
- Update
useOrganizationData.tsto use backend API
Notes
- Some client-side filtering/sorting is acceptable for UX (debouncing, instant feedback)
- Backend should handle all business logic, calculations, and data persistence
- Frontend should be "dumb" - just display data and call APIs
- Consider caching strategies for frequently accessed data
- Use React Query for all data fetching (already in place)