web3 개발자가본 SSR vs CSR

ssr vs csr

SSR vs CSR

검색을 해보면 똑같은 내용이 많이 공유 되는 것을 알 수 있다. 대부분의 내용이 말하는 것은 web2.0기반의 시스템에서는 맞을 수 있지만 , web 3.0기반에서는 조금 다르다.

아래 내용은 hive blockchain client app을 기반으로 설명한다.

서버사이드렌더링(SSR)

처음에 SEO를 고려해 SSR페이지로 제작을 하였다.
고려대상은 SEO와 속도였다.

하지만 여기서 몇가지 문제점이 발생한다.

• 서버가 필요하다. 이것은 web3.0의 서버 분산화 정책에 맞지 않게된다. 서버 유지보수 비용이 나가게 되고, 서버가 사라지면 클라이언트 앱이 동작할수 없게 된다.
• 실제로 빠르지않다. SSR이 빠른경우는 Frontend와 Backend가 같은 서버존 내에서 동작할경우이다. 서버의 로케이션이(국가)가 다를경우, 속도 저하가 발생한다. SSR이 빠르다는 것은 최초 js 로딩에대한 이득 부분이다.
• SEO. 구글은 SPA도 페이지 색인을 생성 할 수 있다. SEO를 위해 따로 서버를두는것은 부담이다.

클라이언트사이드렌더링(CSR)

현재 delog.io는 CSR로 동작한다. SSR로 구현시보다 빠른 로딩 속도를 보여주고있다. SEO또한 문제 없다

• SSR보다 빠르다. js로딩 최적화를 위해 라이브러리를 최소한으로 사용하고, 꼭필요한 경우 사이즈가 작은 라이브러리를 사용하고 있다.
• SEO또한 잘 작동한다. 물론 구글에서. 구글에서 검색창에 site:delog.io 로 검색을 해보면 페이지가 색인된 숫자가 올라가는 것을 볼 수 있다.
• 현재 운용비용은 0원 이다. 서버를 없애 서버 비용을 줄였다. Frontend는 SPA로 cloudflare의 page 서비스를 이용하고 있다.

web3.0은 서버 분산화가 핵심이다. 클라이언트 또한 오픈소스로 어디서든 올라갈 수있어야 한다.

web3.0의 발전과 함께 SPA가 다시한번 발전하게 될것 같다.