Hacker News 의견

• 쓰기 API는 동기식이지만 숨겨진 비동기 대기 기능이 있음. 쓰기가 실패하면 런타임이 응답을 HTTP 실패로 대체하여 자동으로 쓰기를 일괄 처리하고 성공을 가정할 수 있게 함

  • 읽기 트랜잭션이 없어 특정 시점의 스냅샷을 얻기 어려움
  • 각 런타임 인스턴스는 128MB RAM으로 제한됨
  • Websockets는 하이버네이트할 수 있으며, 이때 비용이 발생하지 않음. 이는 클라이언트가 DO가 잠들어 있을 때도 연결을 유지할 수 있게 함
  • 자동 RPC 기능이 있어 다른 DO나 워커와 일반 JS 호출처럼 통신할 수 있음. 런타임이 직렬화 및 구문 분석을 처리함

• 각 DO는 WAL 항목의 시퀀스를 객체 저장소로 스트리밍하며, 이는 16MB마다 또는 10초마다 일괄 처리됨

  • 전 세계적으로 쓰기를 읽기까지 10초가 걸릴 수 있음
  • 지역적으로 배치된 데이터베이스 클러스터를 대체하기 어려움

• Durable Object 디자인을 좋아함. 내부 작동 방식을 이해하기 쉬움

  • DO는 빠르고 저비용의 실시간 경험을 구축하는 데 좋지만, 분석 및 개요 작성이 어려움
  • SQLite에 데이터를 넣으면 여러 작은 SQLite 인스턴스를 쿼리하고 결과를 병합해야 함

• Durable Objects의 물리적 위치가 어디인지 이해하기 어려움

  • API 호출이 발생한 지역에 위치하는지 궁금함
  • DO가 자동으로 다른 위치로 이동할 수 있는지 궁금함

• 새로운 클라우드 기술을 이해하기 어려움

  • 15년 이상의 웹 개발 경험이 있지만, 이러한 기술이 자신에게 맞지 않다고 느낌

• 스키마 마이그레이션을 어떻게 처리할지 궁금함

  • 데이터베이스가 테넌트별로 존재하는 경우, 스키마 변경을 각 DO에 적용하는 것이 어려움

• DO 디자인이 흥미롭지만, 고부하 시스템이나 장난감 프로젝트에만 적합하다고 생각함

  • 실무에서는 검증된 시스템이 필요하며, DO는 아직 성숙하지 않음

• DO 디자인에 감명받음. 복잡한 작업을 낮은 규모로 처리하는 방식이 실제 제품 구조와 유사하다고 생각함

• CF가 개발자들에게 DO 사용을 권장하는 것을 주목함

  • 워커의 웹소켓 연결이 30초 후에 타임아웃되며, DO 사용이 권장됨

• DO가 MVC 아키텍처의 "모델"에 해당하는지 궁금함

  • DO를 테넌트별로 사용하고, 모든 DO를 쿼리하거나 조인하는 방법에 대해 궁금함