Think ..
이 책에서는 메신저 웹 서비스를 각각의 프레임워크들로 구현해보는데, 이런 과정에서 각 프레임워크들의 특징과 스타일을 확인할 수 있다.
내가 생각했을때 각 프레임워크들은 서로의 장점들을 흡수하며 점점 단점을 보안하는것이 보이며, 이제는 각각의 장점보다는 스타일로 정의 내릴수 있을 것 같다.
FE에 있어서 가장 트렌드의 정점에있다.
이것은 풀스택 프레임워크가 아니기 때문인데, 다양한 라이브러리의 사용이 새로운 기술이나 메커니즘을 적용하기 쉬운것으로 생각이든다. ( View library , 다른 프레임워크와의 다른점 )
또, 프론트엔드 개발자라면 JS언어가 메인이고 이런 JS를 가지고 HTML과 CSS를 정의할 수 있다는 점에도 장점이라고 할 수 있다.
다른 프레임워크들은 편의를 위해서 특징에 맞는 문법과 툴을 제공해주고있지만, 리액트의 경우 상대적으로 가장 바닐라에 가까운 JS를 사용하기 때문에 개발자 입장에선 통일된 문법과 개념으로 개발이 가능하다보니 많이들 선호하는 것 같다.
앵귤러는 내가 서비스를 만든다면 1순위로 고려할 프레임워크다.
앵귤러의 경우 서비스와 프로젝트의 생산성에있어서 가장 합리적인 프레임워크가 아닌가라는 생각이든다. 프로젝트를 진행다하보면 규모가 커지기 마련이다.
이 경우 커진 큐모를 프로젝트를 잘 이어나가기 위해서는 개발자들이 프로젝트 아키텍처를 잘 지키는것이 중요하다. 이런 점에서 앵규러는 너무나도 체계적인 개발 환경을 제공한다.
구글이라는 거대한 플렛폼을 업고있다보니 구조역시 탄탄하다. 단단한 구조와 설계들이 개발자가 올바른 방향으로 나아갈수 있도록 인도해주고, 그 결과 프로젝트의 오염이 가장 덜 하다고할 수 있다. 프로젝트의 오염, 즉 다양한 철학(메커니즘)들이 도입되면서 가장 쉽게 오염되는데 당장은 편할지 몰라도 나중에는 큰 스너우볼이되어 프로젝트의 정체성을 위협한다.
앵귤러는 잘 정리된 문서와 그들만의 커뮤니티, 기술력을 통해 엘리트 코스를 밟아가는 학생의 느낌이나는 프레임워크라고 생각이든다.
내가 개인적으로 가장 선호하는 프레임워크이다.
리액트와 앵귤러의 장점을 흡수한 프레임워크다보니 사용성에 있어서 엄청 편리하다. 프레임워크도 제품이고 그걸 선택하는 개발자는 고객이다. 제품을 선택할때 있어서 디자인도 중요하지만 결국 편리한쪽으로 기울기마련이다.
그런점에있어서 뷰는 다른 프레임워크들보다 배우기가 쉽고(문서화), 사용하기 쉽고, 읽기 쉽다(SFC). 그러므로 생산성과 접근성에서 뷰가 다른 프레임워크들보다 위라고 생각한다.
아래 내용은 책 내용 정리입니다.
새로 알게되었거나 필기해두고 싶은 내용을 위주로 작성되었으며, 기본적인 내용이라 판단되는 부분은 생략하였습니다.
자바스크립트 ,프론트엔드, 프레임워크의 발전
라이브러리란?
프로그램에서 필요로하는 기능을 제3자가 사용할 수 있는 형태로 모아둔 것.
프레임워크란?
애플리케이션의 전체 혹은 일부분의 형태를 규정 혹은 방침화한 것.
자바스크립트에서… 프레임워크까지…
JS의 표준 사양인 XMLHttpRequest라는 기능을 통해(서버에서 비동기적으로 데이터를 받아올 수 있는 특징), 오늘날 사용중인 Ajax의 핵심 기술이 되었습니다.
Backbone.js 의 등장(SPA의 구조를 갖춘것이 특징)으로 이후 JS의 프레임워크에 큰 영향을 끼쳤습니다.
2009년 Node.js가 발표되고 함께 탑재된 npm 덕분에 JS의 빌드 환경이 개선되었습니다.
이는 html 파일에서 읽어 들여 사용하는 방식에서 많은 수의 파일로 구성된 JS file을 하나로 묶어주는 빌드환경과 복잡한 프로그램 작성을 도와줍니다.
SPA가 만들어낸 3대장 프레임워크
A JavaScript library for buiding user interfaces
•
JSX는 XML 포맷으로 된 템플릿을 직접 JS에 내장시키는 형태로 컴포넌트를 정의할 수 있습니다.
•
적절한 타이밍에 컴포넌트의 화면 표시 및 삭제를 수행하는 이벤트를 컴포넌에 정의 할 수 있습니다.
•
컴포넌트가 화면에 나타난 상태에서 사용자의 조작에 의해 표시 내용이 변화할 때 HTML 렌더링 스타일에서 “가상 DOM(virtual DOM)”을 사용합니다.
•
강력한 명령행 도구, 잘 정돈된 폴더 구조, 프로젝트 생성과 동시에 각종 환경을 한 번에 갖춰지는 등..
필요한 기능을 내장한 풀스택 프레임워크입니다.
•
TS (데코레이터)
•
RxJS를 내부적으로 사용. 이벤트를 배열과 같이 처리하는 것이 특징입니다.
•
“프로그레시브 프레임워크” : 라이브러리적 측면과 프레임워크적인 측면을 동시에 갖는 프레임워크
•
SFC(단일 파일 컴포넌트) : 가상 돔을 이용하지만 React처럼 템플릿을 JS와 결합하지 않음 (물론 JSX 지원), 웹 디자이너가 보아도 템플릿 구조 파악하기 쉽습니다.
•
참고 문서가 충실하게 지역화되어있습니다. ⇒ 접근성
프론트엔드 구현 기술의 최신 동향
컴포넌트 지향
컴포넌트 간의 상호작용 형태로 프로그램을 작성하는 것.
컴포넌트 지향 애플리케이션을 구현할 때는 컴포넌트 각각이 단독으로 필요한 기능을 수행할 수 있는 스타일과 스크립트를 포함하는 독립된 존재여야 하는 것이 중요합니다. 이런 조건을 지키기위해서 외양과 행동을 컴포넌트 내부에 감추어 두는 “캡슐화”가 필요합니다.
CSR (Clinent-side Rendering)
대표적인 기술로 SPA가있습니다. (사실 이것말곤 … )
)사용자가 URL을 요청하면 html에 하나에 라우팅을 통해 클라이언트에서 그려내는 방식입니다.
SSR (Server-side Rendering)
[그림 3] 서버 사이드 렌더링 (SSR)
[그림 4] 프리 렌더링
일반적인 HTTP 응답 방식입니다. 사용자 요청에따른 페이지를 서버측에서 넘겨주는 것으로 SPA보다 화면 전환은 느리지만 이미 완성된 html 페이지를 받아온다는 점에서 검색 엔진에 최적화되어있습니다.
그러나 구글 검색엔진은 자바스크립트로 렌더링된 페이지 역시 정상적으로 수집해 주고있으므로 SPA 컨텐츠도 검색 대상에 해당 되었습니다. 하지만 여전히 SNS와 관련된 무제는 쉽게 해결되지 않았고, 크롤러나 wget이나 curl 같은 명령행 도구로 접근시 정보 수집의 어려움이있습니다.
결국 이 검색엔진최적화(Search Engine Optimization, SEO) 문제를 해결하기 위해선 SSR을 사용 해야했고 각 프레임워크들은 서버측에서 SPA를 실행해 렌더링 결과를 완성하는 경우가생겼습니다. (React : ReactDOMServer, Vue.js : vue-server-renderer, Angular : Angular Universal)
프리 렌더링
[그림 4, 프리 렌더링] 프리 렌더링은 말 그대로 “미리 렌더링 해놓는다”는 뜻입니다. 서버 사이드 렌더링과는 달리 서버에 렌더링 로직이 존재하지 않습니다. 요청이 들어왔을때 대상이 크롤러인지 판단하여 크롤러인 경우 가상 브라우저로 접근하는 방식으로, 생성 후 저장해둔 렌더링 결과를 제공하는 방식입니다.
하이브리드 서비스
두 방식을 함께 사용하는 하이브리드 서비스도 존재합니다.
예를들어 커머스의 경우 상품의 상세 정보는 검색 엔진에 노출되어야하고, 상품을 검색했을때 나오는 리스트는 검색 엔진의 노출보단 화면전환에 신경을 써야합니다. 이처럼 같은 도메인에서도 페이지마다 역할마다 사용기술을 달리적용해서 효율을 높일 수 있습니다.
웹 애플리케이션의 MVC
MVC (Model - View - Controller)의 약자입니다.
•
모델 : 데이터와 데이터에 접근하기 위한 기능, 여기에 다양한 로직을 보탠 것.
•
뷰 : 컨텐츠를 어떻게 외부에 노출시킬지 정의하는 부분.
•
컨트롤러 : 특정 URL을 요청받았을 때(라우팅), 필요에 따라 컨트롤러가 모델과 정보를 주고받은 다음 적절한 뷰를 골라 사용자에게 반환합니다.
MVP 패턴
MVP의 MV 역시 (Model - View)를 의미합니다.
여기서 P는 프리젠터(Presenter)가 추가된 패턴입니다. 모델과 뷰 사이에 프리젠터가 위치하여 양자 간의 입출력 인터페이스 역할을 맡습니다. 사용자가 모델의 정보를 수정하거나 읽으려면 반드시 뷰를 거쳐 프리젠터가 제공하는 인터페이스를 통해야만합니다.
프론트엔드 애플리케이션에서의 MV
프론트엔드 애플리케이션에서 말하는 MV(Model-View) 는 MVC 애플리케이션의 뷰 부분에 해당합니다.
웹 애플리케이션은 본래 콘텐츠가 HTML에 포함된 채로 사용자에게 응답으로 전달되기 때문에 “뷰”안에 MV와 같은 구성을 할 필요가 없었습니다.
그러나 SPA에서는 “뷰” 안에서도 Ajax 등을 통한 데이터 접근 계층이 추가되거나 필요에 따라 URL을 교체하는 처리 등이 끼어들기 때문에 MV 구조가 필요하게 되었습니다.
MVVM 패턴
VM이 V와 M사이에 위치한다는 점에서 프리젠터와 비슷하지만, 그 역할이 뷰와 모델간의 인터페이스 대신 양방향 데이터 바인딩을 담당한다는 점에서 다릅니다.
Flux
React가 유명해진 뒤로 MVP, MVVM과도 다른 또 다른 아키텍처인 Flux가 주목을 받았습니다.
Flux는 페이스북에서 주창한 웹 애플리케이션용 아키텍처 패턴입니다. Action, Dispatcher, Store, View 단계를 반복하는 형태로 웹 애플리케이션이 구성됩니다.
위 그림으로 알수있는 내용으론 “Flux는 디스페처만이 스토어의 내용을 변경할 수 있다”라고 정의되어있습니다. 그리고 Flux에서 애플리케이션의 처리과정은 항상 단방향이라는 점을 알수있습니다.
PWA
PWA는 프로그레시브 웹 애플리케이션(Progressive Web Apps) 의 약자
구글이 주창하였으며, 이름에도 프로그레시브라는 말이 붙은 연유는 단계적으로 적용이 가능하다는 뜻을 가지고있습니다. 최신 브라우저에는 최신 기술을 적용하고 그렇지 못한 환경에서도 컨텐츠를 열람할 수 있도록 하는 “프로그레시브 인핸스먼트(Progressive Enhancement, 단계적 개선)”의 사상을 따르고 있습니다.
기술적으로 사용되는 부분은 아래와 같습니다.
•
서비스 워크(Service Worker)를 통한 콘텐츠 제어
•
애플리케이션 쉘(App Shell, 이하 앱 쉡) 을 이용한 애플리케이션화
•
웹 노티피케이션(Web Notification)과 웹 푸시(Web Push)를 이용한 푸시 노티피케이션
서비스 워커를 통한 콘텐츠 제어
서비스 워커(Service Worker)는 PWA의 기술적 핵심으로, 백그라운드에서 동작하는 스크립트이다. 사용자가 웹 애플리케이션을 사용할 때 뒤편에서 다양한 처리를 담당합니다. PWA의 특징 중 하나는 “네트워크 접속에 의존하지 않는다”는 점입니다. 네트워크가 오프라인일 때도 서비스 워커가 콘텐츠를 캐싱해 두어서 사용이 가능합니다.
재참여 가능(re-engageable) 이라는 특징도 있는데, 이것은 푸시 기능이 브라우저에 탑재되면서 구현가능해진 것이며 이 역시 서비스워커가 필요합니다.
앱 쉘을 이용한 애플리케이션화
PWA의 특징 중 사용자에게 크게 체감되는 것은 “(웹 사이트를) 애플맄케이션처럼 사용할 수 있다”는 점입니다. 앱 쉘 모델이란 애플리케이션을 구성하는 최소한의 HTML, CSS, JS를 로컬에 캐시해둬서 애플리케이션 본체와 그 밖의 부분을 따로 읽어 들일 수 있도록 한 구현기법입니다. 여기다 웹 애플리케이션 매니페스트를 추가해주면 브라우저에서 주소바를 제거하거나 홈 화면에 단축 아이콘을 추가하는 등 어플과 같은 외양을 갖도록 할 수 있습니다.
웹 노티피케이션과 웹 푸시를 이용한 푸시 노티피케이션
푸시 노티피케이션은 웹 노티피케이션과 Push API 두 가지 표준 기술로 구현됩니다.
현재 웹 노티피케이션은 이미 W3C의 권고사항에 포함되지만, Push API는 아직 드래프트 단계에 있습니다.