▲
neo 8달전 | parent | favorite | on: GN⁺: 라이브뷰, 스벨트와 가장 잘 어울리는 기술(blog.sequin.io)
Hacker News 의견

  • 멀티플레이어 비디오 게임에서 사용되는 패턴 중 하나는 클라이언트와 서버 모두에서 기본적으로 실행되는 코드가 있다는 것임.

    • 클라이언트 코드는 서버 상태의 예측으로 실행됨.
    • 서버 상태가 수신되면 클라이언트 상태를 강제로 적용함.
    • 게임에서 "예측"은 적절한 표현이며, 클라이언트는 입력의 결과를 잘 추측할 수 있지만 다른 플레이어의 입력을 알 수 없기 때문에 확실하지 않음.
    • 이 패러다임은 공식 서버 상태를 기다리는 동안 클라이언트 입력에 즉각적으로 반응하기 위해 사용될 수도 있음(예: 드롭다운 활성화/비활성화, 로딩 스피너 표시).
    • 서버에서 실행되지 않는 클라이언트 상태도 많이 있음(예: 파티클 시스템, 래그돌 - 모든 클라이언트에서 정확히 같을 필요가 없고 다른 플레이어 입력/물리와 상호작용하지 않는 것들).

  • LiveView와 Svelte를 결합하는 방법에 대한 ElixirConf 2022에서 발표를 했으며, live_svelte 기여자들이 이를 현실로 만드는 데 기여함.

    • 클라이언트 측 상태는 특히 풍부한 UX를 가진 앱에 항상 필요함.
    • 뉴욕시에서는 특히 이동 중에 네트워크 연결이 보장되지 않음.
    • Phoenix의 pubsub을 사용하여 다른 서버에서 발생한 서버 측 상태 변경 사항을 클라이언트에 반응적으로 푸시하는 기능은 매우 강력함.

  • 새로운 행이 들어오면 LiveView가 클라이언트를 업데이트하므로 테이블에 푸시하기만 하면 됨.

    • 대화형 행이 있는 비즈니스 앱에서는 이 방법을 사용하지 말 것을 권장함.
    • 사용자가 잘못된 것을 클릭하거나 잘못된 고객에게 이메일을 보내거나 잘못된 거래를 환불하는 등의 인지 지연이 발생할 수 있음.
    • 데이터가 변경되었다는 메시지를 전달하는 스티커 배너를 사용하거나, 급할 때는 스크롤 위치 변경 없이 새 행을 추가만 하는 것이 좋은 UX임.

  • BeaconCMS에서 Svelte와 LiveView를 함께 사용함.

    • 클라이언트에서 UI를 더 세밀하게 제어하고 싶은 경우에는 좋은 사용 사례가 있음.
    • Phoenix를 사용하더라도 항상 LiveView가 답은 아니며, 때로는 정적인 렌더링 페이지가 완벽히 괜찮음.
    • 모든 것에 대해 전부 또는 전무로 접근하지 말 것을 조언함.
    • 기사에서 지적한 것처럼 'LiveView 방식'에서 벗어나는 몇 가지 좋은 사용 사례가 있음.
    • 만약 1000ms의 라운드 트립이 있다면 다른 고려 사항이 있을 수 있지만, 지리적으로 위치한 서버가 비용 등의 이유로 사용할 수 없을 수 있으므로 클라이언트 측 상태 관리를 추가하는 것이 해결책이 될 수 있음.

  • 클라이언트에서 상태를 관리하는 대신 클라이언트와 서버 모두에서 상태를 관리함.

    • 이것이 개선이라고 보기 어려우며, 또 다른 API를 구축할 필요를 없애주긴 하지만 그렇다고 해서 개선된 것은 아님.

  • 이 접근 방식의 한계는 빛의 속도에 있다는 것임: 서버는 사용자에게 얼마나 가까울 수 있는지에 한계가 있음.

    • 다음 단계는 서버를 WebAssembly로 컴파일하고 클라이언트에게 전송하여 실제 서버가 반환될 때까지 낙관적으로 응답을 렌더링하는 것임.
    • 조금 미친 듯 들릴 수 있지만 실제로 프로젝트에서 이를 성공적으로 수행했으며 마법과 같은 경험임.

  • LiveSvelte를 만든 사람으로, 질문이 있다면 알려달라고 함.

  • 일반적으로 이 모델로 앱을 만들고 싶었음: 이벤트 지향적, 양방향 실시간 업데이트와 서버, 순서 있는 이벤트, 로컬 및 원격 상태...

    • LiveView에 대해 알지 못했고, 에를랑 계열 언어를 사용해본 적이 없지만 분명히 그들은 무언가를 발견함.
    • 전통적인 요청-응답 모델은 일관성과 오래된 데이터 문제를 많이 일으킴.
    • 희망적이지만 아마도 논란의 여지가 있는 생각: 지난 10년이 주류 언어에 FP 개념을 통합하는 데에 관한 것이었다면, 다음 10년은 상태를 가진 메시지 지향적(반응형?) 프로그래밍을 주류 전체 스택에 통합하는 데에 관한 것이 되기를 바람.

  • 앱에서 LiveView와 함께 재사용 가능한 Stimulus 컨트롤러를 사용하고 있으며, 이 또한 매끄럽게 작동함.

    • 일반적으로 LiveView로 빌드하는 것은 즐거움이지만, 실제 시나리오에서 사용할수록 상태가 없는 HTTP 프레임워크의 이점을 더 깨닫게 됨.
    • Hotwire와 같은 프레임워크는 더 뛰어난 성능과 재연결에 대한 회복력을 제공하며, 사용자에게 더 가까운 서버를 배치하는 필요성을 피함.

  • 멋진 프로젝트임! 이에 대한 Svelte Radio 에피소드를 방금 발표함.