# Feasibility Report: Custom Backend Sync Logic

## 🏷 Status
🟢 POSSIBLE

## 📌 Idea Summary
Implement a dual-write mechanism in the Cuccu Note extension that pushes saved memos/notes to an additional, custom endpoint (`http://172.16.2.210:5230/`) using the existing auth token (fresh token or access token).

## ⚙️ Constraint Profile Used
- Hardware: Standard extension compute (minimal overhead).
- Budget: Free (local API routing).
- Integration: Additive, low disruption.
- Timeline: Short runway.

---

## 📊 Dimension Analysis

### 1. Hardware & Compute
| Factor | Requirement | Our Capacity | Result |
|--------|-------------|--------------|--------|
| RAM    | Minimal     | Sufficient   | ✅ |
| CPU    | Minimal     | Sufficient   | ✅ |
| Network| 1 extra req | Sufficient   | ✅ |

The hardware footprint is practically zero. It only involves a secondary asynchronous `fetch` call within the service worker whenever a note is saved.

### 2. API & External Services
| Service | Free Tier | Cost at Scale | Alternative | Result |
|---------|-----------|---------------|-------------|--------|
| Custom Backend | Local | $0 | — | ✅ |

The user owns the backend endpoint (`172.16.2.210:5230`), so there are no third-party API costs or rate limits beyond local infrastructure capacity.

### 3. Integration Effort
- **Level**: Additive
- **Affected files/services**: `src/background/service-worker.ts`, `src/shared/api-client.ts`, and optionally `src/components/Settings.tsx`.
- **Breaking changes**: No.
- **Reversible**: Yes, via feature flag or setting.

The extension already retrieves the token properly and handles API calls. We just need to add a "fire-and-forget" secondary API call to the specified endpoint with the same payload and Authorization headers.

### 4. Risk & Maintenance
- **Dependency maturity**: N/A (Standard `fetch` API)
- **Team familiarity**: High
- **Maintenance burden**: Low
- **Failure impact**: Isolated (if the secondary API goes down, the primary note save should still succeed).

We must ensure the second request runs asynchronously so it doesn't block the UI from closing/confirming the primary save if the secondary endpoint is offline or times out.

---

## 🧾 Verdict

**🟢 POSSIBLE**

The integration is very straightforward and only involves duplicating an existing POST request to a new URL, reusing the exact same JWT authentication mechanism and payload.

---

## 🛣 Action Plan

### If 🟢 POSSIBLE:
- [ ] Determine the exact JSON schema and endpoint path expected by `http://172.16.2.210:5230/`.
- [ ] Create an asynchronous sync function in `api-client.ts` to push to the new endpoint.
- [ ] Invoke the sync function in the `SAVE_NOTE` handler in `service-worker.ts` without blocking the main response.
- [ ] Implement robust error logging so failures on the secondary API don't crash the extension worker.

---

## 🔗 Linked Idea
`plan/ideas/09_custom_backend_sync_logic.md`

---
_Evaluated: 2026-04-28 | Constraint Profile: Default_
