• 웹뷰내에서도 CSR을 쓸것인가? 아니면 SSR을 쓸것인가 고민을 해야함.
• 항상 어떤 엔지니어링 측면에서의 결정은 근거가 있어야한다.→ 그것을 왜 어떤 이유로 결정했는가가 핵심 포인트이다.

행복한 상상

• 서비스가 성장하는 것이 부자가 되는 것
• 여러가지 기능들이 더 개발될 것이다.
  • 웹뷰 화면들이 늘어날 것이다. → 그렇게 늘어난다면 어떤 일이 있을까 상상해 보는 것.
• 개발적인 측면에서는 언제나 두 가지 정도를 가지고 미래를 예상하는 걸 즐겨 사용한다.
  1. 갯수가 늘어난다.
  2. 스케일이 커지는 것 → 10000라인의 코드베이스를 갖고 있었던 어플리케이션이 1000000라인이 되고 하는것은 스케일 업이 되는 것
     1. 이 부분은 내가 어떠한 아키텍쳐를 고르는게 좋을까를 충분히 예상 할 수 있다.

CSR을 선택한 이유

1. 독립된 웹뷰가 여러가지 존재한다.

   • 만약 SSR 방식이라고 했을때는 백엔드 서버가 필요하다 → 렌더링 서버
   • 만약 프론트엔드 개발자가 메인터넌스 해야하는 백엔드라고 하면 → 생각만 해도 조금 피곤해지는 그런 부분…..
     • 추가로 백엔드는 돈도 들고, 서비스 안정성이라는 측면에서도 백엔드가 문제가 생기면 당연히 서비스 안정성이 떨어지니깐, 장애가 발생할 수 있는 가능성
     • 백엔드 서버에 대한 부담

2. SSR을 사용하는 가장 핵심적인 이유는 SEO

   1. 웹뷰내에서 작동하는 스크린인데 굳이 SEO를???
   2. 오히려 노출되면안됨… 앱의 특정화면 컨텐츠가 검색 엔진에 노출된다??.. 생각만 해도 깨림직하고 있어서는 안 될 일이다.

   <aside> 💡 결국 SEO고려를 하지 않아도된다. → CSR

   </aside>

3. 기민한 사용자 반응성이 무엇보다 중요하다.

   • 빠른 반응성이 웹뷰에서는 중요함.
   • 웹뷰화면은 하나가 아닐 수 있다. 여러가지 화면이 존재할 수 있다.
   • 빠른 반응성은 CSR이 좋다.

프로젝트 구성

Webview side

• CRA는 기본적으로 Webpack을 래핑해서 복잡한 컨피그레이션들을 보두 다 숨기고 있는 녀석.
• 당연히 내부에는 Webpack으로 되어 있고, 따로 Webpack config파일을 건들 필요가 없었을텐데 왜 Webpack?
• 이제는 다양한 번들러 들이 출현했다. 이제는 번들러 선택지를 선택할 수 있다.
  • 현재는 Webpack이 제공하지 못하는 여러 번들러들이 출현했다.
  • rollup도 괜찮음.