server-side rendering without server

나는 백엔드 스택을 빡세게 쌓지 않았다. 그 결과, 퓨어 리액트로만 프론트엔드를 구현해서 프로덕션에서 돌리다보니 여러가지 문제가 생겼는데, 그 중 하나가 페이스북에 홈페이지링크를 공유하려고 하니 내가 정성스럽게 react-helmet으로 정성스레 넣어준 html > head 안의 태그들이 나오질 않다는 것.

조금 검색해보니, 구글은 크롤러가 자바스크립트 엔진을 돌리면서 퓨어 프론트엔드 자바스크립트로만 짜여있는 페이지라도 렌더링해서 리액트 돔트리를 렌더링 해주는 것 같았는데, 다른 검색엔진들과 트위터-페이스북과 같은 SNS는 그냥 curl 날려서 나오는 그 html text를 가져가더라고.

그래서 해결방법은 두 가지였다. node에서 raect-dom/server 라이브러리를 임포트해서 서버사이드 렌더링을 구현하거나. 아니면 user-agent를 보고 bot인 경우에는 렌더링된 html를 기억하고 있다가 그것을 리턴하는 서비스로 리다이렉트해주거나. 후자의 경우는 코드레벨에서 수정은 전혀 없고, nginx 또는 apache 웹서버단에서 아주 조금의 리다이렉팅 설정만 해주면 된다는 장점이 있었다.

13725712_147924158967372_179637912_n.jpg
백엔드 코드가 없는 게 최고야!

그럼 그런 서비스를 만들어아하냐? 그래도 되긴하는데, 페이지 수가 많지 않은 우리 서비스의 경우에는 공짜로도 커버되는 서비스가 있었고, 그게 바로 https://prerender.io/ 이다. 서버사이드 렌더링을 굳이 구현하기 귀찮은 경우에 쓰기 아주 좋은 녀석. 덕분에 SEO, OpenGraph등을 자유롭게 세팅할 수 있었다. 서버단에서의 환경설정도 엄청 간략해지는 부수적인 효과도 있었는데, webpack으로 컴파일된 파일들만 nginx의 static file serving으로 보내기만 하면 되기 때문.

노드를 깔아서 npm 돌려서 빌드하고 웹팩서버 돌리는 그런 번잡한 일은 안해도 된다는 강점이 생겨버리게 됐는데, 이 아이디어가 너무나도 심플하다는 것과 시너지를 일으키는 부분이 바로 AWS S3인 것 같다. 왜냐하면 webpack 플러그인 중에 AWS S3에 파일 올려버리는 녀석도 있거든. cloudfront와 섞어쓰면 파일도 엄청나게 빠르게 배포할 수 있고, 서버사이드 렌더링도 어느 정도 커버할 수 있는 이 방법이 너무나 섹시하다고 느껴서 간단하게 공유한다.


ps. 물론 게시글이 마구마구 생겨나는 커뮤니티/SNS 같은 서비스를 돌리고 있다면 저 서비스를 사용하는 대신 자체적으로 이 아이디어를 구현하는 것도 나쁘지 않다고 본다. 워닉 간단하니까 ㄷ_ㄷ

Leave a Reply