Session 1 - 김득중 쇼핑검색 React 전환 경험 공유
2019년 9월 6일 네이버 쇼핑 개발자 meet up 행사인 'SHOWROOM' 에 발표된 자료입니다.
보다 자세한 내용은 http://nshop-developer.github.io 을 참고해주세요.
(2019년 9월 30일 오후 오픈 예정)
8. 1
2 3
왜? Node/React ← Java/JSP
코드의 순서는 1,2,3 으로 개발 되나 `검색결과 더보기`는 2 영역
의 데이터를 참조해야 합니다.
2영역의 `선택된` 쿼리 데이터는 계속 바뀝니다.
`검색결과 더보기 ` 클릭 이벤트에서 2번 영역의 데이터를 찾아서 처리 해야 합니다.
9. 왜? Node/React ← Java/JSP
더이상 DOM조작은 싫어요 ㅠㅠ
비지니스 로직에 더 신경 쓰고 싶어요.집에도 좀 일찍 가고 싶구요.
그래! 우리도 React 한번 써보자!!!!
10. 그래서... 바꿔 보기로 했습니다.
ES6 문법을 열심히 익혔습니다.
React도 열심히 배웠습니다.
작업시작전 우리팀에 React 경험자는 없었습니다.
TypeScript도 열심히 배웠습니다.
12. 그런데... 서버 로직 구현도 괜찮네?
기존 Spring으로 작성된 Controller, Service 메
소드에서 서로 연관성이 없는 데이터를 순차적
으로 호출하고 있었습니다.
API, DB를 호출하는 메소드에서 걸리는 시간이 곧 서버 응답
시간이 됩니다.
thread / future 등을 쓰기는 좀 그랬었나 봅니다..
Promise.all 이라는 문법은 굉장히 쉽게 동시처
리를 가능케 합니다.
14. 그전에 ... 다음과 같은 고민을 미리 하면 좋습
니다.
SPA / SSR / CSR ?
사용자가 브라우저에 URI을 입력하는 행위가 어떤
경로를 통해 처리되는지 잘 파악해야 합니다.
사용자가 마우스 클릭으로 요청한 페이지가 어떤 경
로를 통해 처리되는지 잘 파악해야 합니다.
우리의 경우 다음과 같이 처리됩니다.
SSR
15. 그전에 ... 다음과 같은 고민을 미리 하면 좋습니다.
컴포넌트는 어떻게 나눌까?
실제 개발전에 정리를 해두면 좋습니다.
컨테이너 컴포넌트와 프레젠테이션 컴포넌트를 잘
분리해야 합니다.
컴포넌트 재사용성이 결정 됩니다.
컴포넌트에서 사용하는 데이터는 무엇인지 고민 합
니다.
props / state 를 고민 합니다.
상태 관리를 위한 툴을 고민하게 됩니다.
18. 어디서 부터 성능을 확인해야 할까?
API로 부터 검색 결과를 받는데 xml 포멧으로
되어 있습니다.
서버사이드 성능의 주범은 xml 파서 였습니다.
xml2js, xml2json, fast-xml-parser 도...느림
심지어 빠르다고 자랑하는 node-expat도 느림
원하는 타입으로 파싱이 안되고...
문서의 일부만 파싱이 안되고...
19. 어디서 부터 성능을 확인해야 할까
?
XML 파서를 찾는 여정이 시작되었습니다.
20. 어디서 부터 성능을 확인해야 할까
?
EASYSAX를 사용한 파서
https://github.com/vflash/easysax
엄청 빠릅니다.
easysax를 사용한 파서 유틸을 제작 했습니다.
21. 그래도 느립니다.
서버에서 클라이언트에 전달되는 데이터 사이즈
가 JSP 보다 3~4배 많습니다.
SSR시 서버에서 전달되는 데이터는 html + store(json) data
입니다.
스토어 데이터를 최소화 합니다.
CSS 클래스명 단축
API나 DB에서 갖고온 데이터중 사용하지 않는 프로퍼티를 모
두 삭제해 줍니다.
어디서 부터 성능을 확인해야 할까
?
22. 여전히 느립니다.
클릭을 했는데 한참후에 UI가 바뀝니다.
불필요한 컴포넌트 리렌더링을 막아야 합니다.
redux를 쓴다면 불필요한 스토어 데이터를 connect 하고 있는
지 살펴봐야 합니다.
어디서 부터 성능을 확인해야 할까
?
23. 이제 오픈을 하나 싶었는데..
서버 프로세스 모니터링 툴에서 프로세스 알람은 왜 이렇게 많이
오지?
프로세스가 갑자기 죽는 현상이 발생 합니다.
알고보니 로그 전송중 발생한 이슈 였고 비동기 코드
exception handling 과 연관된 문제였습니다.
그리고 Pinpoint 못쓰잖아?
ES-APM을 통한 모니터링이 가능 합니다.
24. 이제 오픈을 하나 싶었는데..
클라이언트 로딩 속도가 느려요.
클라이언트 로딩 속도 지표가 느려졌습니다.
Onload 타이밍은 React 버전이 더 느릴수 있어요.
FMP라는 지표를 보기로 했습니다.
https://developers.google.com/web/tools/lighthouse/audits/first-
meaningful-paint
25. 어디서 부터 성능을 확인해야 할까
?
EASYSAX를 사용한 파서
https://github.com/vflash/easysax
엄청 빠릅니다.
easysax를 사용한 파서 유틸을 제작 했습니다.
26. 우여곡절 끝에 ... 오픈을 했습니다.
서버사이드, 서버-클라이언트, 클라언트 성능을 잘 살펴 봅시다.
기존 Java/JSP 보다 성능이 쪼~~끔 더 잘나오네요.
27. 알아두면 좋은 깨알팁
민감한 코드가 client 번들에 들어가지 않도록 주의하세요.
Isomorphic javascript code 때문에 이런일이 생기기도 합니다.
민감한 데이터가 client에 전달되지 않도록 주의하세요.
API, DB로 부터 넘어온 Object는 유저에게 전달이 되어서는 안되는 property를 포
함할수도 있어요.
그래서 graphql을 쓰는지도...
gzip/keep-alive를 활성화 시켜 주세요.
axios를 사용한 코드중에 생각보다 keep-alive를 활성화한 코드가 많지 않더라구
요.
SSR시 BFF self call의 경우 TPS가 눈에 띄게 좋아 집니다.
28. 플렛폼만 변경할 꺼니?
PR로 시작 하는 개발문화 바꾸기
PR을 두려워 하지 마세요.
자주자주 짧은 코드일수록 리뷰하기 좋습니다.
PR로 배웁니다.
내가 사용하지 않는 코드/구현방법이 눈에 띈다구요? 근데 누구나 다 알것 같아서
코멘트 안했다구요?
생각보다 남들도 모르는 경우도 많습니다. 엄지척 해주세요.
말로하는 리뷰 보다는 변경되는 코드가 더 명확합니다.
개발은 말로 하지 않듯이 코드 리뷰도 내가 생각하는 코드를 직접 적어 주
시면 의견 전달이 더 명확 합니다.
리뷰어의 의견을 존중해 주세요.