▲

GN⁺: 데이터베이스 구축 중단

 (sqlsync.dev)
5P by neo 5달전 | favorite | 댓글 1개

데이터 관리의 복잡성

  • 프론트엔드 엔지니어는 API 데이터를 캐시해야 할 필요성을 깨닫게 됨.
  • 초기에는 간단한 데이터 저장으로 시작하지만, 기능 요청이 늘어나면서 데이터 캐시, 수동 인덱스, 낙관적 변이(optimistic mutations), 재귀적 캐시 무효화 등을 구현하게 됨.
  • 이러한 기능들은 데이터베이스의 내부 작동과 유사하며, 복잡한 프론트엔드 애플리케이션에서는 결국 도메인 특화 데이터베이스를 만들게 됨.

캐시의 기본

  • API 요청 결과를 로컬 변수에 저장하는 것으로 시작.
  • 선언적 프레임워크를 사용하는 웹 애플리케이션에서 불필요한 API 요청을 방지하기 위해 데이터를 변수에 저장함.
  • 캐시를 더 높은 계층으로 옮기거나 UI 트리 외부로 이동시키는 것이 다음 단계임.

인덱스를 통한 속도 향상

  • 데이터를 특정 방식으로 조직함으로써 애플리케이션의 작업을 줄이고 사용자 경험을 향상시킬 수 있음.
  • 프론트엔드 데이터 최적화가 데이터베이스 저장소의 내부 작동과 유사함을 발견함.
  • ID별로 데이터를 저장하고, 날짜별로 항목을 빠르게 조회할 수 있는 인덱스를 만들어 데이터 구조를 개선함.

낙관적 변이

  • 서버 응답을 기다리지 않고 로컬에서 특정 작업의 효과를 시뮬레이션하는 것.
  • 사용자 인터페이스가 즉각적으로 반응하는 것처럼 보이게 하지만, 서버와 다른 결과가 나올 경우 UI가 변경 사항을 롤백해야 함.
  • 클라이언트와 서버 간의 논리를 복제하고, 비동기적 오류를 처리하며, 애플리케이션 재시작을 거쳐 변경 사항을 조정하는 등의 도전과제가 있음.

재귀적 캐시 무효화

  • 데이터가 캐시의 여러 곳에 나타나며, 업데이트 후 서버와 일치하도록 캐시를 올바르게 무효화하는 것이 필요함.
  • UI가 캐시의 어떤 부분이 각 변이에 관련되어 있는지 알아야 하며, 이는 규모가 커질수록 취약해질 수 있음.
  • 낙관적 변이와 결합될 때, 클라이언트 측에서 서버 변경을 예측하기 위해 서버 논리를 복제하는 것이 더 어려워짐.

데이터베이스 구축 중?

  • 충분한 복잡성을 가진 프론트엔드 애플리케이션에서는 결국 많은 데이터 관리 기능을 구축하게 되며, 이는 사용자를 기쁘게 하고 비즈니스 문제를 해결하는 데서 시간을 빼앗김.
  • 프론트엔드 최적화된 데이터베이스 스택에 대한 대안을 제시함.

SQLSync 소개

  • SQLite를 기반으로 한 프론트엔드 최적화된 데이터베이스 스택인 SQLSync를 개발함.
  • SQLSync는 데이터 관리 문제를 해결하고 개발자가 애플리케이션의 독특한 기능에 집중할 수 있도록 설계됨.
  • SQLSync는 내구성 있는 캐시, SQLite의 전체 기능, 낙관적 변이, 스마트 캐시 무효화, 반응형 쿼리를 제공함.

GN⁺의 의견

이 글에서 가장 중요한 것은 프론트엔드 애플리케이션의 복잡성이 증가함에 따라 개발자들이 데이터베이스와 유사한 기능을 자체적으로 구현하게 되는 현상입니다. 이러한 작업은 개발자의 시간을 소모하고, 실제로 사용자에게 가치를 제공하는 기능 개발에서 벗어나게 만듭니다. SQLSync와 같은 프론트엔드 최적화된 데이터베이스 스택은 이러한 문제를 해결하고자 하는 혁신적인 접근 방식을 제시합니다. 이 글이 흥미로운 이유는 기존의 데이터 관리 방식에 대한 근본적인 문제를 지적하고, 개발자가 더 효율적으로 작업할 수 있는 새로운 해결책을 모색하고 있기 때문입니다.

▲
neo 5달전  [-]
Hacker News 의견

  • 프로젝트 창작자인 친구에 대한 이해

    • SQLsync는 프론트엔드 개발자들이 브라우저 내에서 원격 데이터베이스를 질의하고 업데이트할 수 있게 해주는 도구임.
    • WASM의 힘을 이용해 SQLite 데이터베이스를 브라우저로 전송하는 방식으로 작동함.
    • 여러 클라이언트 간의 동기화를 위해 반응형 알고리즘을 사용함.
    • 개발자들의 데이터 동기화 작업을 혁신적으로 해결하는 접근법임.

  • 과거 회사의 프로젝트 관리 소프트웨어 경험

    • 체크인/아웃 메커니즘을 사용해 데이터를 동기화했으나, 실시간 업데이트 앱이 등장하면서 구식으로 여겨짐.
    • SPA 웹 앱을 10년간 구축한 경험에서, 이러한 데이터 동기화 메커니즘이 시대를 앞서간 것으로 느껴짐.

  • SPA를 버리면 사라지는 문제

    • Hotwire나 htmx와 같은 솔루션을 사용하면 서버 쿼리가 단순화되고, 이를 빠르게 만드는 문제가 더 잘 이해됨.

  • SQLSync 창작자의 의견

    • 많은 질문에 답변하고, 놓친 질문을 주기적으로 확인할 예정임.
    • SQLSync를 만든 동기에 초점을 맞춘 첫 게시물에 대한 토론이 기쁨.
    • 다음 게시물에서 SQLSync의 작동 방식에 대해 설명할 예정임.

  • 사용자에게 현실과 다른 정신 모델을 주지 말 것

    • 데이터베이스 동기화는 클라이언트-서버 모델보다 복잡할 수 있음.
    • 빠른 UI가 필요할 때 CRDT 기본 요소를 사용하는 것이 더 안전하다고 느낌.

  • 측정 가능한 것이 관리되는 원칙과 침몰 비용의 오류

    • 데이터베이스의 복잡성이 문제임.
    • SQL의 문법이 문제이며, 기본적인 관계형 데이터베이스 사용이 즐거운 경험이라면, 자체 데이터베이스를 만드는 대신 DB를 사용할 유혹이 커질 것임.
    • 좋은 데이터베이스는 SQL을 사용하며, 효율성을 위해서는 데이터베이스 언어를 사용해야 함.

  • 클라이언트와 서버 간 상태 동기화의 문제

    • PHP/SSR 모델로 돌아가면 UX 희생을 통해 문제를 우회할 수 있음.
    • SPA는 좋지만, 멀티파트 폼 게시도 여전히 작동함.
    • 모든 상태를 서버에 두고 클라이언트를 단순한 터미널로 취급하는 것이 개발 경험을 향상시킴.

  • ORM 라이브러리와의 비교

    • 브라우저에서 지원하는 TypeORM과 SQL.js를 직접 사용하는 것과 SQLsync를 비교하는 질문.

  • 프론트엔드와 백엔드 데이터베이스의 차이

    • 프론트엔드 데이터베이스는 백엔드와 다를 수 있으며, 클라이언트에서 실시간 상태를 더 잘 관리할 필요가 있음.
    • react query와 웹소켓을 사용하여 캐시 무효화를 고려 중임.
    • SQLsync 아이디어도 고려할 가치가 있음.

  • SignalDB를 통한 유사한 시도

    • SignalDB는 신호를 이용한 반응성과 프레임워크에 구애받지 않는 mongodb와 유사한 쿼리 구문을 사용함.
답변달기