Hacker News 의견

• k8s, kubernetes, cloud native, self-hosted, edge-enabled 기술을 저렴하게 사용할 수 있는 아이디어가 훌륭함

  • rq와 minio를 k8s에서 몇 년간 사용했으며, 최근에는 SQLite를 대체제로 주목하고 있음
  • 개인 클라우드의 중요성을 강조하며, 공공 클라우드에서 많은 것을 처리하는 것이 적절하지 않다고 생각함
  • BTLE 센서가 Apple Watch와 직접 통신하는 것이 충분히 가능함
  • 클라우드를 거치는 것이 이득이 아니었으며, 차세대 도구에서는 이를 수정해야 한다고 주장함

• SQLite는 단일 서버에서 실행되며, 대부분의 경우에는 작동하지만 100% 신뢰할 수는 없음을 지적함

  • 큐 서버가 충돌할 경우 SQS는 계속 작동할 가능성이 높음
  • 최상의 경우에는 작동할 수 있지만, SQS만큼의 신뢰성을 제공하지는 않을 것임

• 규모와 벤치마크를 제외하고, SQS를 사용하는 기능/단위 테스트 모듈에 유용한 도구임

• 호스팅된 큐 시스템을 목표로 하며, SQS보다 저렴하면서도 성능을 희생하지 않는 것을 목표로 함

  • Backblaze와 Minio가 S3 공간에서 성공한 것처럼 큐 시스템에서도 성공을 목표로 함

• AWS API 호환 서비스를 작성하는 것을 좋아하며, Dyna53 프로젝트를 언급함

• LocalStack을 사용하면 SQS와 많은 AWS 서비스를 테스트/개발에 사용할 수 있으며, 문서화가 잘 되어 있고 오픈 소스임

• 인기 있는 서비스에 대한 간단한 자체 호스팅 대안을 만드는 프로젝트를 좋아함

  • Litestream과 큰 문제 없이 작동할 것으로 예상되며, 백엔드 스토리지 조정 없이 일시적인 큐 시스템으로 훌륭할 것임

• 프로젝트 구조에 대한 빠른 제안:

  • models/ 디렉토리에서 모든 구조체를 루트 디렉토리로 이동할 것을 제안함
  • 이를 통해 패키지 사용자가 q.Message와 q.Queue 같은 짧고 깔끔한 이름을 사용할 수 있으며, 사용자가 자체 "models" 패키지를 가지고 있을 경우의 이름 충돌을 피할 수 있음

• ElasticMQ를 언급하며, Docker 환경에서 SQS를 시뮬레이션하는 데 사용함

• 외래 키 지원을 비활성화하고 데이터베이스 스키마에서 여전히 사용하는 이유에 대해 질문함

  • "TODO: check for errors" 주석과 외래 키 제약 조건 검사를 비활성화하는 것처럼 보이는 부분이 시도해보는 것을 주저하게 만듦