▲

LiveStore - 반응형 SQLite 와 내장 동기화 엔진을 사용하는 상태 관리 솔루션

(livestore.dev)
25P by xguru 3일전 | ★ favorite | 댓글 2개
  • 동기화 로직 개발에 대한 부담없이, 고성능 애플리케이션 개발이 가능하도록 설계된 상태 관리 데이터 계층
  • 반응형(reactive) SQLite와 내장 동기화 엔진을 사용하는 것이 특징
  • 로컬 우선(Local-first) 으로 오프라인에서도 높은 성능을 제공하며, 네트워크 복구 시 자동 동기화 지원
    • 모든 상태 관리 연산이 로컬 SQLite 데이터베이스 위에서 빠르게 수행됨
  • 반응형 데이터 스트림: 데이터 변경 시 즉시 UI와 연결된 리스너에 이벤트 발생, 상태 변화에 대한 실시간 반영 가능
  • 다양한 환경(웹, 모바일, 데스크톱 등)에 적용할 수 있음
  • 기존 상태 관리 도구 대비, 네이티브 성능 및 데이터 일관성에서 우수한 결과를 제공
▲
laeyoung 3일전  [-]

홈페이지 메인에 있는 Demo 진짜 잘 만들었네요. Demo 클릭 좀 하다보니, 써보고 싶어질 만큼.

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 안녕하세요, LiveStore의 코파운더임 (이전에는 Prisma를 만들었음).
    지난 4년간 Overtone이라는 네이티브급 고성능 뮤직 클라이언트를 만들면서 스스로 사용하려고 LiveStore를 개발하게 되었음.
    LiveStore는 SQLite에 반응형 신호 레이어를 추가하고, 이벤트 소싱 기반 싱크(Git과 유사)를 결합함

    • 로컬 퍼스트 환경을 다양하게 평가해봤는데, LiveStore만큼 깔끔하게 해결하는 솔루션은 거의 없었음
      유사하게 성숙된 툴로는 tinyBase도 있지만, 그건 구조가 다름(CRDTs vs 이벤트 소싱)
      궁금한 점이 있는데, 왜 데이터 용량을 1GB로 제한했는지, 더 큰 데이터를 SQLite에 저장하고 디스크에 남길 수 있도록 옵션을 둘 순 없는지 묻고 싶음
      단순히 설정만으로 퍼시스턴스 모드를 바꿀 수 있지 않을까?
      멀티 테넌시도 흥미로운 시나리오가 될 수 있다고 생각함 JIRA처럼 각 조직이 별개 네임스페이스를 요구할 때, 각 사용자도 전체 티켓이 아니라 자신의 팀/부서만 받도록 할 수 있으면 좋겠음
      기본적으로 로컬 데이터베이스가 전체 데이터의 서브셋이 되는 구조임 Bun/Node에서 바로 실행 가능한 싱크 서버(Cloudflare 필요 없음)가 박스에 들어있다면 정말 멋질 듯
      현재 내가 검토 중인 프로젝트 아이디어에도 잘 맞을 것 같음 특히 멀티 테넌시가 반드시 필요하기 때문임

    • 지난달에 LiveStore를 취미 프로젝트에 써볼까 해서 확인해봤는데, 베타 프리뷰라 접근이 어려웠음
      곧 더 깊이 살펴볼 수 있기를 희망함 로컬 퍼스트 관련 논의를 적극적으로 이끄는 모습이 인상적임
      오프라인 동기화 가능한 웹앱을 만들어본 사람이라면 싱크 엔진의 유용함을 바로 깨닫게 됨

    • 오늘 Local-First Conf에서 발표 정말 잘 들었음
      이벤트 소싱을 SQLite로 구현하는 구조에 대한 설명이 명확하고 설득력 있었음
      SQLite, 특히 OPFS Wasm SQLite를 웹에서 적극적으로 홍보해 줘서 고마움
      PowerSync도 SQLite를 강력히 지지하는 입장이라, LiveStore 같은 성공사례가 반갑게 느껴짐

    • LiveStore가 이벤트 소싱 모델을 글로벌하게 확장할 때 모든 클라이언트에 보통 중앙 싱크 백엔드를 두고 동기화하는데, 이게 필수 요건인지 궁금함
      혹시 연합형 노드(federated nodes) 또는 완전한 P2P 모드도 가능한지 묻고 싶음 분산 SNS 사례에 대한 적용도 고려 중임

    • React, WASM과 조합해서 LiveStore가 대부분의 뮤직앱들이 쓰는 Juce 프레임워크를 대체할 수 있을지 궁금함
      나는 비트메이커인데, Juce랑 C++ 조합은 항상 어렵고 두려웠음 음악앱 개발에 진입하려는 사람에게 LiveStore가 좋은 대안이 될 수 있을지 알고 싶음

  • Local-first Conf에서 발표를 봤는데, 요즘 정말 다양한 싱크 엔진이 등장하고 있음
    LiveStore는 이벤트 소싱과 싱크 엔진을 조합하는 흥미로운 영역을 깊이 파고드는 중임
    벌써 이렇게 견고한 시스템이 되었다는 점에 놀랐음
    최근 몇 주간 새로운 프로젝트에 직접 써봤는데, 정말 매끄럽게 동작하고 있음

  • 런칭을 축하함! 이 시스템이 여기에 설명된 "1. Serialization" 전략에 들어맞는지 궁금함
    ProseMirror-collab에서 언급된 것처럼, 자주 업데이트하는 저지연 클라이언트가 고지연 클라이언트의 업데이트를 가로막게 되는 문제가 LiveStore에도 나타날지 묻고 싶음

  • LiveStore가 wa-sqlite을 쓰는 것 같음
    오프라인 데이터 영속성 전략을 자세히 듣고 싶음 구체적으로 OPFS(AccessHandlePoolVFS 같은 변종)나 IndexedDB 중 어떤 쪽을 사용하는지, 혹은 둘 다인지 궁금함
    또한 OPFS의 브라우저 간 불안정성과 Safari IndexedDB의 7일 보관 정책에는 어떻게 대응하고 있는지 궁금함
    SQLite에서 공식 WASM 빌드를 제공하는데도 wa-sqlite를 쓴 이유가 있는지 알고 싶음

  • 최근 LocalFirst.fm 팟캐스트에서 LiveStore를 간단히 소개했음 (https://www.localfirst.fm/24 링크 참고)

    • 에피소드 공유 고마움, 곧 LiveStore 단독 에피소드도 준비할 예정임

  • 매우 기대되는 프로젝트로 보임 하지만 과도한 기대감(하이프 트랩) 에 빠지지 않을까 살짝 조심스럽기도 함
    비슷하게 로컬 퍼스트 앱을 커스텀으로 만들면서 멀티 디바이스 지원을 실험 중임
    E2E 암호화를 선택적으로 추가하는 것도 가능할지 궁금함 문서상으로 이벤트 페이로드 단위로 암호화를 추가하면 될 것 같은데, 서버 로그 압축이 어려워지는 점만 빼면 거의 가능할 듯함

    • "하이프 트랩"에 대한 의견에 동의함
      나는 Overtone 작업하면서 생긴 필요를 바탕으로 LiveStore를 직접 만들고 있음
      LiveStore/Overtone 모두 장기적인 지속성을 목표로 제작 중임 E2E 암호화는 이미 구현 가능한 구조임
      내가 직접 해보진 않았지만, 문제 있으면 언제든 도움을 줄 수 있음
      클라이언트 측에서만 압축(log compaction)을 시도하는 것도 하나의 방법이 될 것 같음 엔지니어링하면서 이 유스케이스도 꼭 염두에 둘 예정임

  • 크로스 플랫폼 지원이라는 주장에 회의적임, 가장 처음에 보인 게 안드로이드 웹 미지원임

    • 좋은 지적임 안드로이드/크롬 팀과 기술적 이슈에 대해 계속 소통 중임 3년 전쯤부터 원인을 파악했지만 여전히 해결되지 않고 있어서, LiveStore가 별도 우회책을 마련해야 할 것으로 보임
      진행 상황은 공식 깃허브(https://github.com/livestorejs/livestore/issues/321)에서 확인 가능함
      웹 API 지원이 플랫폼마다 달라서, 이런 야심찬 시스템을 만들려면 굉장히 많은 노력과 시간이 필요함을 이해해주길 바람

  • 데모 영상에서 흥미로운 점 하나! 1분 7초 부분에서 오디오가 좌측으로 몰림 현상이 있었음 사소하지만 참고하면 좋을 것 같아서 알려드림

  • 개발자 도구를 같이 제공하는 게 인상적임, 상당기간 자체 프로젝트에서 테스트해온 것 같음
    궁금한 점은, 장기적으로 실행되는 앱/페이지의 compaction을 어떻게 처리할 생각인지, 그리고 이벤트 소싱은 멋진 개념이지만 애플리케이션 레이어가 발전할수록 코드 관리(구버전 클라이언트, 스키마 마이그레이션 등)가 어려워질 수 있음
    Overtone은 여러 소스를 지원하는 것 같은데, 오프라인 재생도 제공할지 궁금함 특히 Spotify UI가 불편해서 대체제가 절실함

    • 좋은 질문임! compaction에 대해선 많은 문의가 있었고, 곧 해결책을 공개할 예정임
      핵심 아이디어는 각 이벤트에 더 많은 의미 정보를 부여해 이벤트 간 겹침을 정의할 수 있게 만드는 것임
      예를 들어 todo 앱에서는 동일 작업 ID에 대한 "todoCompleted" 이벤트가 해당 작업의 "todoCompleted"/"todoUncompleted" 이벤트들을 압축시킬 수 있다는 원리임
      진행 상황은 깃허브(https://github.com/livestorejs/livestore/issues/254)에서 확인 가능함
      이벤트 소싱은 확실히 규율과 설계가 중요함 데이터에는 "공짜 점심"이 없기 때문에 트레이드오프가 핵심임
      Overtone 등 내 주요 용도에선 이벤트 소싱의 트레이드오프가 더 낫다고 느끼고 있음
      구버전 지원 등은 간단한 방법이 여러 가지 존재함, 결국엔 각 애플리케이션 특성과 트레이드오프에 달려 있음
      Overtone에 흥미 가져줘서 고마움. 나도 Spotify의 불만족 때문에 이 프로젝트를 시작했음 오프라인 재생의 경우 음원 제공처에 따라 달라짐
      예를 들어 Dropbox 등 본인 소장 앨범은 지원할 수 있지만 Spotify 등 스트리밍 서비스는 정책에 따라 다를 수 있음

  • 이 아키텍처가 마음에 듦, 특히 이벤트 소싱이 좋음
    하지만 이벤트 소싱에는 주의가 필요함 원하는 뷰에 따라 머티리얼라이즈(view materialization)가 느릴 수 있고, 데이터가 커질수록 점점 더 느려짐
    이에 대한 해결책은 트리거 등으로 트랜잭션 내에 머티리얼라이즈 갱신을 직접 관리해야 함
    복제 또는 싱크할 때도 고려해야 하고, 충돌 해결에 대해서도 CRDT 개념을 반드시 익혀둘 필요가 있음
    Postgres 언어 기능이 있는 SQLite3 비슷한 데이터베이스가 있으면 local-first와 remote-first를 그냥 설정만 바꿔가며 쓸 수 있어 정말 좋겠음

    • 마지막 의견 관련 pglite.dev(https://pglite.dev)를 참고하면 좋음
      머티리얼라이즈 비용에 대한 본론에서는, compaction은 앞으로 더 개선할 예정이고, LiveStore 전체가 성능 최적화를 목표로 세심하게 설계된 프레임워크임
답변달기