Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Universal Rendering

2,169 views

Published on

클라이언트와 서버사이드 렌더링을 동시에 지원하는 유니버설 렌더링에 관한 슬라이드입니다. 유니버설 렌더링의 정의 및 장점과 단점을 각각 살펴본 후 개괄적인 구현 방법, 모범 사례를 설명합니다.

Published in: Technology

Universal Rendering

  1. 1. Universal Rendering 김태곤 | https://taegon.kim 1 / 51
  2. 2. 목차 1. 유니버설 렌더링의 정의 2. 장점과 단점 3. 구현 방법 개요 2 / 51
  3. 3. 유니버설 렌더링의 정의 3 / 51
  4. 4. 정의 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 4 / 51
  5. 5. 정의 - 서버측 전통적인 방식의 렌더링으로 사용자의 웹 브라우저에서 표현할 정보를 서버에서 HTML 형태로 작성하여 전송한다. 화면 표현에 관한 로직이 서버측에서 실행된다. 5 / 51
  6. 6. 정의 - 서버측 - 클라이언트측 웹 애플리케이션에서 많이 사용되는 형태로 서버에서는 JSON 또는 HTML 형태의 부분 데이터만 전달받고 사용자의 웹 브라우저에서 자바스크립트를 사용해 화면을 렌더링한다. 6 / 51
  7. 7. 정의 - 서버측 - 클라이언트측 웹 애플리케이션에서 많이 사용되는 형태로 서버에서는 JSON 또는 HTML 형태의 부분 데이터만 전달받고 사용자의 웹 브라우저에서 자바스크립트를 사용해 화면을 렌더링한다. 화면 표현에 관한 로직이 클라이언트측에서 실행된다. 7 / 51
  8. 8. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 8 / 51
  9. 9. 그럼 화면 표현 로직은 어디서? 9 / 51
  10. 10. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 화면 표현 로직은 양쪽 모두에서 실행되어야 한다. 10 / 51
  11. 11. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 화면 표현 로직은 양쪽 모두에서 실행되어야 한다. 서버측과 클라이언트측에 완전히 동일한 로직이 존재해야 한다. (두 언어가 다르면) 변환 또는 재작성이 필요 11 / 51
  12. 12. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 화면 표현 로직은 양쪽 모두에서 실행되어야 한다. 서버측과 클라이언트측에 완전히 동일한 로직이 존재해야 한다. (두 언어가 다르면) 변환 또는 재작성이 필요 (언어가 같으면) 다를 때보다는 훨씬 편리 12 / 51
  13. 13. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 화면 표현 로직은 양쪽 모두에서 실행되어야 한다. 서버측과 클라이언트측에 완전히 동일한 로직이 존재해야 한다. (언어가 같으면) 다를 때보다는 훨씬 편리 (두 언어가 다르면) 변환 또는 재작성이 필요 13 / 51
  14. 14. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 화면 표현 로직은 양쪽 모두에서 실행되어야 한다. 서버측과 클라이언트측에 완전히 동일한 로직이 존재해야 한다. (언어가 같으면) 다를 때보다는 훨씬 편리  → 자바스크립트가 주로 사용됨 (두 언어가 다르면) 변환 또는 재작성이 필요 14 / 51
  15. 15. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 화면 표현 로직은 양쪽 모두에서 실행되어야 한다. 서버측과 클라이언트측에 완전히 동일한 로직이 존재해야 한다. (언어가 같으면) 다를 때보다는 훨씬 편리  → 자바스크립트가 주로 사용됨 클라이언트 라이브러리로 시작한 React의 경우, 단순히 서버사이드 렌더링이라고 부르기도 함 (두 언어가 다르면) 변환 또는 재작성이 필요 15 / 51
  16. 16. 정의 - 서버측 - 클라이언트측 - 유니버설 서버-사이드(server-side) 렌더링과 클라이언트-사이드(client-side) 렌더링을 동시에 지원하는 것. 주로 클라이언트 사이드 렌더링이 위주인 환경에서 출발하여 서버 사이드 렌더링을 추가한다. 화면 표현 로직은 양쪽 모두에서 실행되어야 한다. 서버측과 클라이언트측에 완전히 동일한 로직이 존재해야 한다. (언어가 같으면) 다를 때보다는 훨씬 편리  → 자바스크립트가 주로 사용됨 클라이언트 라이브러리로 시작한 React의 경우, 단순히 서버사이드 렌더링이라고 부르기도 함 (두 언어가 다르면) 변환 또는 재작성이 필요 16 / 51
  17. 17. 장점과 단점 17 / 51
  18. 18. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다. 18 / 51
  19. 19. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  19 / 51
  20. 20. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  20 / 51
  21. 21. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  사용자 경험이 향상될 수 있다. 21 / 51
  22. 22. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  사용자 경험이 향상될 수 있다.  별 차이 없다(goo.gl/Mpi5xI). 22 / 51
  23. 23. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  사용자 경험이 향상될 수 있다.  별 차이 없다(goo.gl/Mpi5xI).. 샘플 데이터 23 / 51
  24. 24. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  사용자 경험이 향상될 수 있다.  별 차이 없다(goo.gl/Mpi5xI). 첫 데이터를 그리는 시간 24 / 51
  25. 25. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  사용자 경험이 향상될 수 있다.  별 차이 없다(goo.gl/Mpi5xI). 마지막 데이터를 그리는 시간 25 / 51
  26. 26. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  사용자 경험이 향상될 수 있다.  별 차이 없다(goo.gl/Mpi5xI).    확실히 서버 렌더링이 빠름(goo.gl/GfXMuK).내가 해봐서 아는데 I'd argue that ... the server rendered app will stay significantly faster than the same app rendered only on the client. - Malte Ubl: Google AMP 프로젝트의 Tech lead 26 / 51
  27. 27. 장점 - 빠르다 페이지를 더 빠르게 읽어들일 수 있다.  사용자 경험이 향상될 수 있다.  별 차이 없다(goo.gl/Mpi5xI).    확실히 서버 렌더링이 빠름(goo.gl/GfXMuK).  페북/인스타그램도 안 쓰고, UX에는 딱히 도움되는지 못찾음(goo.gl/qvMoif). 내가 해봐서 아는데 I'd argue that ... the server rendered app will stay significantly faster than the same app rendered only on the client. - Malte Ubl: Google AMP 프로젝트의 Tech lead We haven't found sr useful for real users. - Crhistoph Pojer: 페이스북 엔지니어 27 / 51
  28. 28. 28 / 51
  29. 29. 장점 - 빠르다 - 옳다 웹의 이념인 "웹 페이지는 문서(A webpage is a document)"라는 생각을 지지한다면 각각의 주소에 해당하는 데이터를 반환해주는 것이 옳다. 29 / 51
  30. 30. 장점 - 빠르다 - 옳다 - SEO 자바스크립트를 실행하지 않아도 콘텐츠를 읽을 수 있으므로 검색 엔진 최적화(SEO: Search Engine Optimization) 측면에서 유리하다(goo.gl/qvMoif). instagram.com uses server rendering for SEO. - Crhistoph Pojer: 페이스북 엔지니어 30 / 51
  31. 31. 장점 - 빠르다 - 옳다 - SEO 자바스크립트를 실행하지 않아도 콘텐츠를 읽을 수 있으므로 검색 엔진 최적화(SEO: Search Engine Optimization) 측면에서 유리하다(goo.gl/qvMoif). 페이스북, 트위터 등 다른 서비스와 연동에 유리하다.  instagram.com uses server rendering for SEO. - Crhistoph Pojer: 페이스북 엔지니어 31 / 51
  32. 32. 단점 - 업무부담 같은 코드를 써도 테스트는 각각 해야한다. 아무래도 고려할 점이 많고 더 수고롭다.  개발자가 넘쳐나면 모를까 페이스북도 안쓰는 걸 굳이...? 유지보수는 점점 어려워진다. 그 시간에 다른 거 하는 게 더 이득이다. 32 / 51
  33. 33. 단점 - 업무부담 - 필요없다 메일이나 업무용 소프트웨어 등 한 번 접속하면 거의 안 끄는 앱에선 초기 로딩 시간이 거의 의미가 없다. 다른 서비스와 연동할 필요없는 사내 인트라넷이나 금융 관련 애플리케이션이라면 굳이 필요없다. 구글에서만 검색되면 된다. 구글의 크롤러는 자바스크립트도 실행한다. 33 / 51
  34. 34. 용도에 맞게 선택 사용하라 34 / 51
  35. 35. 구현 방법 35 / 51
  36. 36. 시간 표시 - HTML 출력 <!doctype html> <html> <head> <title>시간 표시</title> <script src="app.js"></script> </head> <body> <div id="root"> <p>Wed Dec 07 2016 15:00:17 GMT+0900 (KST)</p> </div> </body> </html> 36 / 51
  37. 37. 시간 표시 - React 앱 // app.js import React from 'react'; export default class App extends React.Element { componentDidMount() { this.timeoutId = setInterval( this.tick.bind(this), 1000 ); } componentWillUnmount() { clearTimeout(this.timeoutId); } tick() { const dateStr = new Date().toString(); this.setState({ date: dateStr }); } render() { return <p>{this.state.date}</p> } } 37 / 51
  38. 38. 시간 표시 - 클라이언트 // client.js import React from 'react'; import { render } from 'react-dom'; import App from './app'; render( <App />, document.getElementById('root') ); 38 / 51
  39. 39. Node.js 서버 가장 간편한 경우 39 / 51
  40. 40. Node.js 서버 // server.js import { renderToString } from 'react-dom/server'; import App from './app'; function handleRender(res, res) { const html = renderToString( <App /> ); res.send(`<!doctype html> <html> <head> <title>시간 표시</title> <script src="app.js"></script> </head> <body> <div id="root">${html}</div> </body> </html>`); } 40 / 51
  41. 41. 다른 언어 서버 PHP, Python, Java 41 / 51
  42. 42. 구성1: 다른 언어 웹서버 + Node 렌더링 사용자가 최초에 접속할 때(=서버 렌더링이 필요할 때)만 Node 렌더링 서버를 사용해 HTML 렌더링. 인스타그램에서 Django + Node 구성으로 사용했었던 방식(goo.gl/L9agTw). 간단한 Node 렌더링 서버 소스는 React on Rails의 Node.js for Server Rendering 챕터(goo.gl/Ib8TA4) 참고. 최초 접속시 Node 렌더링 서버 사용 42 / 51
  43. 43. 구성1: 다른 언어 웹서버 + Node 렌더링 최초 렌더링 이후부터는 API를 통해 서버에 데이터를 요청하고 이를 사용해 클라이언트에서 렌더링 클라이언트 렌더링 43 / 51
  44. 44. 구성1: 다른 언어 웹서버 + Node 렌더링 Node 렌더링 서버대신 쉘 스크립트를 사용하는 경우도 있음 Node 쉘 사용 44 / 51
  45. 45. 구성2: Node 웹 서버 + 다른 언어 API 서버 Node 렌더링 서버대신 쉘 스크립트를 사용하는 경우도 있음 최초 접속시 Node 웹 서버가 렌더링 결과 반환 45 / 51
  46. 46. 구성2: Node 웹 서버 + 다른 언어 API 서버 최초 렌더링 이후는 구성 1과 동일하게 API 서버와만 통신 클라이언트 렌더링 46 / 51
  47. 47. 구성3: 다른 언어 웹서버 + 자바스크립트 확장 모듈 최초 렌더링할 때 각 언어에 포함된 자바스크립트 확장 모듈을 사용해서 렌더링 각 언어별 자바스크립트 확장 모듈이 제대로 유지되지 않을 수 있다는 불안 요소가 있음. 일례로 PyV8은 2012년 이후 개발되고 있지 않음. 하지만 페이스북에서 공개한 React-PHP-V8Js(goo.gl/ebIEa6) 라이브러리의 사례도 있음. 자바스크립트 모듈을 활용한 렌더링 47 / 51
  48. 48. 구성3: 다른 언어 웹서버 + 자바스크립트 확장 모듈 최초 렌더링 이후는 구성 1과 동일하게 API 서버와만 통신. 자바스크립트 모듈은 사용되지 않음. 클라이언트 렌더링 48 / 51
  49. 49. Best Practices npm 버전보다는 브라우저에서 사용할 수 있게 제공되는 형태의 성능이 더 낫다. NODE_ENV=production으로 설정 HTML 결과물은 가능하다면 캐시 JS 모듈보다는 Node 서버 사용 49 / 51
  50. 50. Best Practices npm 버전보다는 브라우저에서 사용할 수 있게 제공되는 형태의 성능이 더 낫다. NODE_ENV=production으로 설정 HTML 결과물은 가능하다면 캐시 JS 모듈보다는 Node 서버 사용 50 / 51
  51. 51. 감사합니다. 51 / 51

×