구글 I/O Extended 세 번째 세션 - Google’s PRPL Web development Pattern
점차 구글에서는 웹으로 접근하는지에 대하여 의문
- 모질라의 접근
- 구글의 접근
- 애플의 접근
- 페이스북의 접근
최근 10년여간에 대한 충돌이 시작
W3C
HTML 표준안 기구
문서를 강조함. 영속성에 초점을 맞춘다.
WHATWG
웹 어플리케이션 10
프레임워크다라고 강조.
WebGL
WebAssembly
WebPayments
Apple사가 애플페이로 사용하겠다함.
두 집단의 HTML5의 정의가 다르다.
Service Worker는 구글 gears를 그대로 가져왔다고 할 수 있다.
그래서 나온 개념이 미래를 위한 PRPL 개발 패턴이 나온 것이다.
웹 페이지를 구성하는 컨셉의 변경
아래 4가지를 이용하여 패턴을 만듬
- Custom Elements
- Imports
- Service Worker
- HTTP/2
Service Worker
요청을 가로채고 처리함
응답들을 적절하게 캐시
오프라인일때 캐시
백그라운드 단에서도 캐시
Push Render Pre-cache Lazy load = PRPL 개발 패턴
Polymer Demo
실무적 문제
- AWS cloudfront 가 HTTP/2를 지원 하지 않음
CloudFlare는 지원함 - 사파이 ios가 service worker를 지원 안함
강제 매니페스트로 적용 가능함 - 크롬을 제외한 브라우저들이 HTML import를 지원 안함
- WebcomponentsReady 이벤트가 네이티브 웹 컴포넌트를 지원하는 크롬에서는 작동 안함
해결코드를 추가함. - Shadow DOM은 모바일 환경에서는 완전 느림
조만간 containment 나오면 디자인쪽은 해결 됨 - Webcomponent.js는 비동기로 호출 불가능
- App-Storage의 동작을 예측할 수 없음
분기로 해결 - Django와 사용시 고민해야 함
Django-rest-platform으로 갈아타자