웹뷰로 사용할 웹 아키텍처 구성하기

웹뷰 사용 이유

1. 코드 푸시 서비스가 종료된 상태에서, 앱 업데이트를 수월하게 하기 위함 (가장 큰 이유임)

- 별도로 코드 푸시 서버를 운용하는건 배보다 배꼽이 더 커지는 기분

- 수익이 없는 상태라 유료 EAS 기능을 사용하는 것도 굳이..? 싶음

2. 2d 그래픽 렌더링 엔진으로 pixi.js라는 라이브러리를 활용하는데(데모까지 구현해본 상황), rn 버전은 프로덕션용으로 안전한지 확신 X

3. 추후에는 앱 서비스를 데탑에서 활용할 수 있게 웹으로 사용할 수 있게 지원하는 것을 염두하고 있음

 

RN vs WebView 구현 장단점 비교

RN

단점

• 업데이트 할 때마다 앱스토어에 요청하거나 유료 EAS툴 사용해야함
• react보다 렌더링에 많이 신경써야함

장점

• 기능 주요한 부분에 웹뷰보다 적합함 (런타임에 compile하는 과정이 없어서 웹뷰보다 빠름)
• 최근에 Expo 라는 프레임워크를 RN 측에서 제대로 디벨롭하고 있어서, 빠르게 서비스 세팅을 시작하면서도 

 

WebView

단점

• 네트워크로 js 파일 받아오는 시간 필요
  • SSR, SSG 개발 필요 (CSR로는 초기 로딩 속도 느림)
• 생각할 게 좀 더 있음
  • 반응형 웹 개발 필요
  • SSO 관리
  • URL 접근 막기
  • 그 외 찾아봐야함
  • 웹뷰로 하는 상태 관리 (e.g. 인증 상태 유지)

장점

• 업데이트 자주 필요한 부분에 적합
• 웹과 앱을 하나의 코드로 처리 가능
• +) 인앱 결제 등 구현 가능

 

 

웹 아키텍처

프레임워크: Next.js 

- 이유: 웹뷰는 RN과 달리 네트워크로 페이지를 로드하는 시간이 필요하다

 

라우팅 방식: App Router  

- 이유:

- 서버 컴포넌트(RSC)를 기본으로 사용함 

- fetch api 사용할 경우, next.js 가 자동으로 데이터 캐싱해준다 함(원래는 fetch API는 캐싱 기능 제공 안함)

 

렌더링 방식: SSR or ISR + CSR

- 초기 빈화면을 렌더링하지 않기 위해 

- 그치만 인터렉션이 필요한 부분도 관리 필요함

- 그런 부분은 Client Component( 'use client'를 파일에 정의 ) 를 사용할 수 있다

- 사실 Next.js에서는 SSR을 해도 hydrate라는 과정을 거치고 CSR을 수행하게 됨 (일단 pages router 에서는 그랬음)

- Server Component 에서 받아온 데이터를 Client Component의 Property로 전달해주면, Client Component에서는 초기 데이터는 빠르게 보여주면서, useEffect와 이벤트 핸들러를 활용해서 데이터를 업데이트 할 수 있다

- Next.js 는 SSG 를 가장 추천함. 그치만 이는 빌드 시점의 데이터를 포함한 HTML을 보여주게 되므로 변경되는 데이터가 많은 화면에는 활용하기 부적절. 그래서 ISR 을 사용하겠다!

 

데이터 업데이트 구조:

- 클라이언트: SWR 방식 (캐시에서 먼저 데이터를 가져와서 빠르게 유저에게 보여주고, 업데이트가 필요하면 db에 데이터 받아와서 유저에게 보여주겠다) / react query를 활용하자

- 서버: App Router 에서 제공하는 fetch 캐싱을 활용. 내가 할 것은 캐싱 규칙을 설정하는 것

 

디자인 패턴: UI / 데이터 페칭 및 로직 분리 / 자식 컴포넌트는 데이터를 prop으로만 받아서 사용하도록

- 흔히들 MVVM / Container–Presentational 패턴(Smart - Dump Component) / 관심사의 분리 라고 하는 것

- 와이어 프레임 우선 제작으로 UI는 추후 구현하고, 로직부터 구현하는 상황에서, UI / 로직을 분리하여서 서로 영향을 주고받지 않도록 관리하는 구조가 필요함

- 컴포넌트 재사용이 쉬워짐 데이터 신경 안쓰고 주는거 쓰기만 하면 되니까