Server Driven UI, Tom Lokhorst (English)
시간: 0초 소개 및 주제 소개
섹션 개요: 이 토크는 서버 주도 UI에 대한 경험을 중심으로, 프라임 포닉스 브랜드를 위해 사용하고 구축하는 방법에 대해 다룹니다.
Swift 앱과 서버 주도 UI
- 프라임 포닉스 앱은 클래식 음악 스트리밍 서비스로, Android, iPhone, iPad용 앱 및 웹 플레이어를 제공합니다.
- 서버 주도 UI는 화면을 구성하는 여러 구성 요소로 이루어져 있으며, 이러한 구성 요소의 순서와 내용은 모두 서버에서 제어됩니다.
- 변경 사항을 즉시 반영할 수 있는 유연성을 제공하며, 예를 들어 전기보다 앨범을 보여주고 싶다면 서버에서 변경하여 클라이언트의 새 버전 배포 없이 업데이트할 수 있습니다.
서버 주도 UI의 역사와 비교
섹션 개요: 다양한 회사들이 채택한 서버 주도 UI 접근 방식과 관련된 사례들을 살펴보며, 전통적인 아키텍처와의 차이점을 탐구합니다.
기업별 접근 방식 비교
- Airbnb의 Lona, Spotify의 App Framework, Apple의 WWDC 발표 등 다양한 기업들이 서버 주도 UI를 도입하거나 연구한 사례가 있음.
- 전통적인 아키텍처와의 차이는 클라이언트가 요청을 보내면 서버가 JSON으로 응답하여 클라이언트가 렌더링하는 것에 반해, 서버 주도 UI에서는 클라이언트가 요청 후 JSON 응답을 받아 렌더링함.
세부 내용과 다섯 가지 토픽 소개
섹션 개요: 화면 및 컴포넌트 구축부터 API 디자인 및 통합까지 다섯 가지 핵심 토픽에 대해 설명하고 언제 이 접근 방식을 사용하지 말아야 할지에 대해 논의합니다.
다섯 가지 핵심 토픽
- 화면 및 컴포넌트 구축 방법
- 네비게이션 처리 방법
- 로컬 및 원격 작업 수행 방법
- API 디자인 및 애플리케이션 통합 방법
- 이 접근 방식 사용 시 부적절한 경우와 대체할만 한 것에 대한 고려
마무리
UI TableView Cell 및 네비게이션 최적화
섹션 개요: 이 섹션에서는 UI TableView Cell을 렌더링하는 데 필요한 모든 것이 원본 JSON에 포함되어 있으며, 데이터를 서버에서 가져오는 앱에서 언제 데이터를 가져와야 하는지, 네비게이션을 어떻게 처리해야 하는지에 대해 논의됩니다.
UI TableView Cell 및 네비게이션 최적화
- 사용자가 화면을 탭할 때 API 호출을 언제 해야 할지에 대한 접근 방식:
- 첫 번째 접근 방식은 화면을 탭하면 두 번째 뷰 컨트롤러로 이동하여 데이터를 로드하기 시작합니다.
- 두 번째 접근 방식은 화면을 탭하면 즉시 API 호출을 수행하고 완료될 때까지 기다렸다가 두 번째 화면으로 이동합니다.
- 문제 해결 방법:
- 웹 브라우저 효과나 네비게이션이 지연되는 것을 피하기 위해 첫 번째 화면에 두 번째 화면의 헤더를 포함시켜 해결합니다.
- 상태:
- 첫 번째 화면: 두 번째 화면의 헤더를 포함한 링크가 있는 상태
- 두 번째 상태: 로딩 중인 상태로 이미지와 제목 등의 큰 헤더가 보여짐
- 세 번째 상태: API 호출 결과 반환 및 모든 데이터 fade in
작업 및 액션 관리
섹션 개요: 작업 및 액션 관리에 대한 설명과 의미있는 인사이트들이 다루어집니다.
작업 및 액션 관리
- Jason 분석:
- 작곡가 부분의 Mozart 항목에는 제목, 이미지, 페이지 유형 등의 정보가 포함되어 있음.
- 이미지 URL:
- 이미지 URL은 낮은 해상도 URL도 함께 포함되어 있어 캐시에 이미지가 있는 경우 큰 이미지 다운로드 전에 낮은 해상도 이미지를 보여줌.
- 캐싱:
- 이전 페이지에서 사용된 낮은 해상도 URL과 동일한 URL을 아이템의 URL로 사용하여 캐싱된 아이템인 경우 placeholder로 보여줌.
음악 재생 및 원격 명령 조작
섹션 개요: 음악 재생과 원격 명령 조작 기능에 대한 설명과 서버 주도 UI 구현 방법 등이 다루어집니다.
음악 재생 및 원격 명령 조작
- Track 구성 요소:
- Track 구성 요소는 제목, 부제목, 지속 시간뿐만 아니라 재생 유형의 액션이 포함되어 있음.
- Action 유형:
서버 주도 UI 및 API 디자인
섹션 개요: 이 섹션에서는 서버 주도 UI와 API 디자인에 대해 논의됩니다.
서버 주도 UI
- 클라이언트 앱에서 수행할 수 없는 작업들이 있습니다. 예를 들어, 재생 작업과 공유가 그 중 하나입니다.
- 클라이언트 측 로직이 필요한 경우, 서버는 매우 기본적인 정보만을 전송합니다. 예를 들어, iPhone 앱의 경우 URL을 사용하여 Apple 기기 간에 핸드오프를 구현합니다.
API 디자인
- API 설계와 통합에 대한 구체적인 내용을 살펴봅니다. 15가지 다른 API 버전을 사용하고 있으며, 새로운 컴포넌트 유형을 추가할 때마다 새로운 API 버전을 도입합니다.
- 서버는 클라이언트 요청 시 해당 API 버전을 확인하고 응답 방식을 결정합니다. 예를 들어, 오래된 버전의 앱에서 요청이 온 경우 새로운 컴포넌트를 처리하는 방법을 결정해야 합니다.
JSON 파싱 및 에러 처리
- JSON 파싱은 Swift의 Codable을 사용하여 수행되며, 서버는 다양한 API 버전을 지원해야 합니다.
- 값 또는 디코딩 오류가 발생하는 경우 프로그램 오류를 방지하기 위해 값을 래핑하는 enum이 사용됩니다.
오프라인 경험 및 서버 수익
섹션 개요: 오프라인 경험과 서버 수익에 대한 내용입니다.
오프라인 경험
- 앱은 온라인으로 클릭하면서 오프라인 경험도 구축할 수 있습니다. 데이터를 오프라인으로 다운로드하여 오프라인 앨범 탐색 및 데이터 열람이 가능합니다.
서버 주도 UI 및 구현 사례
섹션 개요: 이 섹션에서는 서버 주도 UI의 개념과 구현 사례에 대해 설명합니다.
전통적 API로 전환
- 서비스 수익이 적합한 접근 방식이 아닌 경우가 있음
- 음악 플레이어와 구독 플로우는 딥 OS 통합을 사용하여 클라이언트 측 로직으로 처리됨
맵 앱을 통한 서버 주도 UI 부적절성
- 맵 앱 예시: 랙 박물관 관광용, 대부분의 로직은 클라이언트 측에서 처리됨
- 클라이언트가 JSON 파일 다운로드 후 비콘을 활용하여 위치 파악
서버 주도 UI의 유연성과 호환성
섹션 개요: 이 섹션에서는 서버 주도 UI의 유연성과 호환성에 대해 논의합니다.
백엔드 for 프론트엔드 구축
- 클래식 음악 데이터베이스를 위한 백엔드 for 프론트엔드 구축
- 기존 API를 활용하거나 새로운 API를 추가하는 유연한 접근 방식
호환성 전략
- 서버가 지원하지 않는 항목 타입에 대한 오류 처리 방법
- 역호환 변경 시, 서버 측에서 처리하고 오래된 앱은 원본 버전 사용 가능
서버 주도 UI 변화와 영향
섹션 개요: 이 섹션에서는 서버 주도 UI 변화와 영향에 대해 다룹니다.
ThreeFUI 도입 여부
- ThreeFUI 도입 시 전체 접근 방식 변경 여부 검토
- 컴포넌트 재사용을 고려하여 ThreeFUI 도입 가능성 평가
앱 사용성 및 상호작용
섹션 개요: 이 섹션에서는 앱의 사용성과 상호작용에 대해 논의합니다.
서버와의 상호작용
- 액션을 취하면 서버로 돌아가는 지연이 발생하고 스피너나 로더 등이 표시됩니다.
- 에피소드 소비 앱으로, 음악 재생 및 탐색이 주된 기능입니다.
상호작용 가능한 기능
- 플레이리스트 생성 및 편집과 같은 기능은 자주 사용되지 않습니다.
- 원격 명령을 사용하여 UI를 조정하지만, 체계적인 로컬 작업에는 적합하지 않습니다.
디자이너와 개발자 협업
섹션 개요: 디자이너와 개발자 간의 협력 방식에 대해 설명합니다.
협업 방식
- 디자이너는 일반 아이디어를 제공하고, 개발자들과 함께 모든 것을 공동으로 구축합니다.
- 디자인 작업 중간 단계를 전달하여 세부 사항을 함께 논의하고 구현합니다.
비즈니스 로직 분리
섹션 개요: iOS 측 비즈니스 로직을 백엔드로 분리하는 방법에 대해 다룹니다.
도메인 지식 관리
- 앱 자체는 도메인에 대해 매우 제한적으로 인식하며, 서버가 모든 도메인 지식을 보유합니다.