쓸데없는 것에 대한 강박

며칠전에 완성한 메모장 memoj 의 동기화 로직을 오늘 좀 더 다듬었습니다

memoJ https://stockmental.duckdns.org/

각 oauth2를 통한 로그인 사용자ID별로

메모가 입력되면 로컬DB(IndexedDB) 저장 후

wss로 100ms 간격으로 go gin API 에 메모를 넘겨주고

go 는 이 메모들을 500ms 배치 프로세서를 통해서 클라우드DB에 저장되는 동기화 구조인데요

로컬DB와 클라우드DB의 저장 시간을 비교해서 최신 것으로 저장하는거구요

로그인 사용자의 다양한 창(같은 기기의 다른 웹브라우저탭/PWA, 다른 기기의 다른 웹브라우저탭/PWA)의 메모들도 다같이 동기화가 되어야 되는데 이건 어려우면서도 쉬운 문제였습니다

여러명이 쓰는게 아니라 혼자 쓰는 단독 단일 메모장이라서 한사람이 두개의 PWA에 동시 입력하는 것은 불가능하며 무의미한 것이기 때문에 최종 동기화의 허브인 클라우드DB에 변경된 메모가 100~500ms 이내에 저장되도록 했습니다

문제는 천재지변이나 사용자의 성질급함으로 메모작성후 100ms 이내에 프로그램에서 빠져나와 버리면 메모장 창이 여러개 열려있을때 창들간에 메모내용이 분리가 된다는 점이었습니다

사실 구글의 클라우드 메모장,todo 앱들도 메모작성후 100ms 이내 빠져나오면 내용의 저장을 꼭 담보하지는 않는 것 같긴 한데

왜 이런 부분에 대해서 저는 강박이 있을까요

serviceworker로 로컬DB, 클라우드DB 저장 및 동기화 기능을 싹 다 옮기다가 이건 아니다 싶어서 로컬DB에는 저장이 됐는데 클라우드DB에서는 3000ms 가 지나도 새롭게 저장이 안될 경우에만 serviceworker가 클라우드DB 저장 시도를 하도록 했습니다

근데 잘 안되더군요. 웹브라우저가 100ms 이하로 닫혀버리면 serviceworker가 백그라운드에서 웹브라우저 닫힌 이후에도 열심히 일할 줄 알았는데 그건 아니더군요. 웹브라우저 마음이라고 하더군요

그래서 이런 응급상황에 대처하기 위해서 beacon api, fetch api도 고려하다가

그냥 100ms 참았다가 창 닫는걸로 스스로 타협했습니다

그정도는 참을 수 있을 것 같습니다