▲

GN⁺: 라이브뷰, 스벨트와 가장 잘 어울리는 기술

 (blog.sequin.io)
2P by neo 8달전 | favorite | 댓글 1개

LiveView와 Svelte의 조합

  • LiveView는 웹 애플리케이션을 구축하는 독특한 방법 제공.
  • 서버가 상태를 가지고 있으며, 프론트엔드의 동작을 백엔드에서 처리하고 DOM을 점진적으로 업데이트.
  • SPA의 복잡성은 분산 시스템의 복잡성 때문이며, LiveView는 프론트엔드 마이크로서비스 없이 풍부한 클라이언트 경험을 제공.

LiveView가 어려운 점들

  • 클라이언트 측 상태는 불가피하며, 서버와 사용자 간의 지연 시간은 피할 수 없음.
  • LiveView는 서버가 많은 DOM 변경을 담당하지만 모든 것을 제어할 수는 없음.
  • LiveView는 LiveViews, LiveComponents, Components의 세 가지 컴포넌트 유형을 가짐.
  • LiveView와 LiveComponents 간의 리팩토링은 예상보다 번거로움.

LiveView의 애매한 방향성

  • LiveView는 종종 무언가를 놓치고 있다는 느낌을 줌.
  • LiveView는 현대 프론트엔드 프레임워크와 많은 공통점을 가지고 있지만, 차이점을 인식하고 문제를 다르게 접근해야 함.

LiveView + Svelte

  • LiveSvelte는 LiveView에서 Svelte 컴포넌트를 렌더링할 수 있게 함.
  • 백엔드가 프론트엔드 컴포넌트의 props를 제어하고, 프론트엔드와 백엔드 모두 상태를 가짐.
  • 프론트엔드와 백엔드 간의 개인적이고 양방향 통신 채널이 있음.

LiveSvelte의 혁신적인 특성

  • 백엔드와 프론트엔드의 책임 분담이 명확하고, 복잡성이 서버 측에 집중되어 있음.
  • LiveView는 백엔드를 위한 프론트엔드로 가장 빛나며, 프론트엔드 컴포넌트를 렌더링하고 상태를 유지하는 백엔드 프로세스를 제공함.

GN⁺의 의견

  • LiveView와 Svelte의 조합은 서버와 클라이언트 간의 상태 관리를 효율적으로 분리하고, 개발자가 더 빠르고 직관적으로 애플리케이션을 구축할 수 있게 해줌.
  • 이 기술은 특히 실시간 상호작용이 중요한 웹 애플리케이션에 유용할 수 있으며, 사용자 경험을 향상시키는 데 기여할 수 있음.
  • 그러나 서버와의 지연 시간이 사용자 경험에 영향을 줄 수 있으므로, 성능 최적화와 지역적 서버 배치가 중요한 고려 사항이 될 수 있음.
  • LiveView와 Svelte의 조합은 기존의 SPA 개발 방식에 익숙한 개발자들에게 새로운 패러다임을 제시하며, 이는 학습 곡선을 낮추고 개발 효율성을 높일 수 있는 잠재력을 가짐.
  • 이 기술이 제공하는 실시간 상태 동기화와 양방향 통신은 특히 협업 도구, 대시보드, 또는 실시간 데이터를 다루는 애플리케이션에 매력적인 선택이 될 수 있음.
▲
neo 8달전  [-]
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 에피소드를 방금 발표함.

답변달기