오프라인 캐시를 가진 서버 소유 CRUD

"서버가 매크로 목록을 소유하고; 기기는 캐시를 쥐어. 하나는 진실, 다른 하나는 자기가 복사본인 걸 아는 빠르고 오프라인 친화적 복사본."

매크로가 사는 곳

매크로는 대화랑 같은 소유 이야기야, 한 스케일 작은. canonical 매크로 세트는 서버 소유야: 생성, 읽기, 수정, 삭제 전부 백엔드에 대해 해소돼서, 매크로가 기기들을 넘어 따라오고 권위 있는 목록이 하나야. 근데 즉시, 오프라인에서도 쓰고 싶기도 해 — 신호 끊겼다고 저장한 프롬프트에 접근을 잃으면 안 되니까. 그래서 기기가 매크로 목록의 오프라인 캐시 랑, 오프라인 중 만든 편집의 pending-sync 마커를 쥐어. 캐시는 명시적으로 자기가 복사본인 걸 아는 복사본이야: 빠르고 쓸 수 있지만, 절대 진실의 출처가 아냐.

캐시는 자기 자리를 안다

이 분리는 역할이 모호하지 않아야만 작동해. 서버 목록은 권위 있고; 기기 캐시는 거기 따르는 편의 층이야:

읽기: 캐시에서 즉시 렌더(오프라인 친화적), 닿을 때 서버에서 새로고침.
오프라인 쓰기: 캐시에 적용, pending-sync 표시, 재연결에 서버랑 화해.
충돌: 서버 목록이 권위로 이겨; 캐시가 거기서 다시 도출. 캐시는 로컬이라는 이유만으로 진실을 절대 override 안 해.

퀘스트 전체의 메아리를 봐: 반응성을 위해 로컬에서 캡처/행동, 근데 canonical 저장소가 진실을 소유. 매크로는 대화 패턴의 축소판이야 — 속도랑 오프라인 위한 로컬 층, 권위 위한 서버 층.

첫 sync 는 흡수하지 짓밟지 않는다

훔칠 만한 우아한 디테일 하나: 서버 쪽 매크로 저장소가 이미 로컬 생성 매크로를 가진 기기를 만나면, 첫 sync 는 기기의 기존 목록을 흡수해야지, 지우면 안 돼. 새 백엔드 저장소가 도착했다고 오프라인으로 시작한 사용자를 벌하면 안 돼. 첫-sync-흡수는, 클라이언트 전체를 관통하는 사용자 입력에 대한 같은 존중을 비추는 작은 다정함이야: 사용자의 작업 — 서버가 알기 전에 만든 매크로조차 — 이 보존되고, 접혀 들어가고, 절대 버려지지 않아. 캐시는 복사본이지만, 그 안의 사용자 의도는 여전히 소중하게 다뤄져.

Code

속도/오프라인 위한 캐시; 권위 위한 서버·typescript

// 읽기: 캐시에서 즉시, 권위 있는 서버 목록에서 새로고침.
async function listMacros(): Promise<PromptMacro[]> {
  const cached = await cache.getMacros();      // 즉시, 오프라인에서 작동
  refreshFromServerInBackground();             // 닿을 때 화해
  return cached;
}

// 오프라인 쓰기: 캐시에 적용, pending 표시, 재연결에 화해.
async function saveMacro(m: PromptMacro) {
  await cache.upsert(m, { pendingSync: true }); // 즉시 사용 가능
  if (navigator.onLine) await syncMacro(m);     // 서버가 권위
}

// 첫 sync 는 기기 로컬 매크로를 짓밟는 대신 흡수해 —
// 새 서버 저장소가 자기 존재 전에 사용자가 만든 작업을 접어 넣어.

Exercise

오프라인에서 편집된 매크로 하나의 sync 상태를 설계해: 캐시-적용됨, pending-sync, synced, conflicted. 그다음 첫-sync-가-기존-로컬-매크로를-만남 케이스를 처리해: 기기 목록을 새 서버 저장소로 하나도 안 잃고 접는 규칙을 써. 마지막으로, 같은 매크로가 두 기기에서 오프라인 편집됐을 때 뭐가 되는지 정해 — 어느 권위가 해소하고, 각 캐시는 어떻게 다시 도출해?

Hint

기기 캐시는 항상 종속: pending 편집을 쥘 순 있지만, 서버 목록이 충돌을 해소하고 두 캐시가 승자에서 다시 도출해. 첫 sync 는 기기가 서버를 seed 하는 유일한 순간이야 — 덮어쓰지 말고 흡수해 — 그 뒤론 서버가 상시 권위야.