.Net 8.0 블레이저의 정적 SSR

닷넷 8.0의 발표와 함께 블레이저 서버는 새로운 구조로 재편이 되었습니다.

“블레이저 서버” 라고 꼭 집어서 말씀드린 이유는 우리가 기존에 알고 있는 프론트 앱으로서의 블레이저는 이번 버전업에 크게 영향을 받지 않기 때문입니다.

이번 재편의 핵심은 정적인 서버 측 렌더링(Static Server Side Rendering) 이라고 볼 수 있을 것 같습니다.

그런데, 이 용어가 많은 혼선을 주고 있는 것 같아, 조금 정리해봤습니다.

서버 측 렌더링 (SSR)

흔히들 말하는 서버측 렌더링은 매 요청 시마다 페이지를 렌더링하는 것입니다.
Asp.Net Core MVC 와 Asp.Net Core Web App 이 여기에 해당됩니다.

이 렌더링 모델에서는 서버는 렌더링에 많은 자원을 소모하게 됩니다.

클라이언트 측 렌더링(CSR)

SSR과 대비되는 렌더링 모델에는 클라이언트 측 렌더링(CSR) 이 있습니다.
블레이저 웹 어셈블리를 포함한 많은 프론트 앤드 앱이 여기에 해당됩니다.

정적 사이트 생성(Static Site Generation)

정적 사이트 생성 모델은 웹앱이 보유한 웹 페이지를 빌드 타임에 미리 생성해놓고, 런타임에 생성된 파일을 정적으로 서빙하는 것을 가리킵니다.

SSG 방식의 최대 장점은 서버의 부담이 매우 적어 빠르다는 점이고, 최대 단점은 사용자와의 상호작용을 하지 못한다는 점입니다.

정적인 서버측 렌더링(Static Servier Side Rendering)

.Net 8.0 의 Static SSR 은 SSG와 CSR, SSR을 섞어 놓은 의미로 사용됩니다.

8.0 블레이저 앱은 초기 페이지는 SSG 방식으로 제공하고, 부족한 "상호 작용성(Interactivity)"은 SPA 기술로 보충하는 것인데, 이 방식을 SSG, SSR과 구분하기 위해 "정적인 서버 측 렌더링(Static Server Side Rendering)"이라고 합니다.

Composite 렌더링이라고 불렀으면 오히려 더 좋았을 것 같다는 생각이 듭니다.

SPA 기술로 상호작용성을 보충하기에, 렌더링 모드의 이름이 InteractivityServer, InteractivityWebassembly 인 것입니다.

만약 렌더링 모드를 None 으로 설정하면, 상호 작용을 하지 않겠다는 의미이기에, SSG로만 렌더링하는데, 이는 정적 페이지 미들웨어를 통해 wwwroot 폴더의 파일을 제공하는 것과 동일하게 됩니다.

즉, 레이저 요소에 상호작용을 위한 코드가 있다 하더라도 아무런 역할을 하지 않게 됩니다.

렌더링 모드의 범위 (Global vs Per-Component)

블레이저 8.0 이전엔 렌더링 모드를 전역적으로 한 번만 설정할 수 있었습니다.
즉, SSR과 CSR 중에 하나를 선택하면, 전자는 블레이저 서버가 되는 것이고, 후자는 블레이저 와즘이 되는 것이죠.

8.0 에서는 이러한 방식을 global 이라는 설정으로 여전히 사용 가능하고, 여기에 더해 특성을 통해 페이지 별 혹은 요소 별 렌더링 모드를 결정할 수 있게 만들었습니다.

풀스택

한 가지 명심해야 할 것은 와즘 기술이 사용되었다 하더라도 8.0 블레이저 앱은 프론트 엔드 앱이 될 수 없다는 점입니다.

이 모든 기능은 Asp.Net Core 앱이 제공하는 것으로, 앱이 완성되면 웹 서버로서 호스팅을 해야 합니다.

다들 아시다시피, Asp.Net Core 앱을 클라우드에서 서비스하려면, Azure/AWS 말고는 마땅한 대안이 없습니다. 특히 국내 호스팅 업체는 거의 전무하다시피 합니다.
공급이 적으니 상대적으로 운영비가 높을 수 밖에 없습니다. 리눅스 서버나, 도커 서비스를 이용한다 해도, 이를 설치/운영하려면 인력과 시간이 투입되어야 하기에 보이지 않는 비용이 됩니다.
할많하않…

Blazor Webassembly Standalone App

3 티어 기준의 프론트 앱을 위해 여전히 블레이저 웹 어셈블리 앱을 만들 수 있는데, 프로젝트 템플릿 이름은 Blazor Webassembly Standalone App 입니다.

애매한 프로젝트 구조

8.0 블레이저 앱에서 상호작용을 와즘으로 선택하면, Program.cs 가 포함된 블레이저 와즘 프로젝트가 하나 더 추가되는데, 자체적으로는 실행이 안됩니다.

그저 단순히 CSR로 렌더링될 요소를 제공하는 프로젝트로 보여지는데, 왜 이런 방식을 채택했는지 아직은 잘 모르겠네요.

10개의 좋아요

사실 이 출발은 나쁘지가 않은건데 각 컨셉의 장점을 살리지 못하고 있는 것 같아요…
어줍잖게 하나의 틀 안에서 wasm도 구현하고, “완전한” SSR도 구현하려는 욕심…
blazor의 메커니즘 자체가 다른 언어와는 다른데… 뭔가 설계부터 어긋나버린 느낌입니다;;;

과연 어떤 방향으로 나아갈지 정말 궁금하네요…ㅠㅠ

4개의 좋아요

동의합니다.

백엔드 코드를 CSR 요소에 넣으면 안되기 때문에 오토 모드, InteractiveWebassembly 모드가 적용된 요소의 사용이 줄 것이고, 결국에는 InteractiveServer 모드 만 사용될 확률이 높습니다.

그래서, 블레이저 서버의 개편이라는 표현을 썼습니다.

4개의 좋아요

WASM 컴포넌트 그려질때 WASM의 Program.cs가 실행되더라구요.

3개의 좋아요

오히려 aws에서 ssr돌리기가 매우 어렵죠. signalr을 웹소켓 통신을 세션 반으로 유지하는건 현재로써 거의 불가능

2개의 좋아요