Blazor Server vs Blazer WebAssembly: Blazor 호스팅 모델의 차이점

 

Blazor 호스팅 모델은 두 가지가 있습니다. 하나는 Blazor Server고 다른 하나는 Blazor WebAssembly입니다. 이 두 호스팅 모델의 차이점에 대해 알아봅니다.

 

 

 

Blazor Server vs Blaser WebAssembly

 

Blazor 서버는 2019년 9월에 dotNet Core 3.0과 함께 출시되었습니다. Blazor WebAssembly는 2020년 5월에 출시되었습니다.

 

이 두 호스팅 모델의 주요한 차이점은 dotNet 코드가 실행되는 위치입니다. Blazor Server의 경우 100% 서버 측에서 실행횝니다. 호스팅 된 Blazor WASM 애플리케이션을 사용하면 dotNet 코드가 서버와 클라이언트 모두에서 실행됩니다. Blazor WASM의 경우 서버 측에서 dotNet이 아닌 원하는 다른 언어를 사용할 수도 있습니다.

 

Blazor Server와 Blazor WebAssembly 모두 서버 측 코드를 갖고 있습니다. 하지만 두 호스팅 모델에서 서버 측 코드의 역할이 다릅니다.

 

Blazor Server의 경우 dotNet 런타임과 함께 100% 서버 측이며 프레임워크 JavaScript 라이브러리는 클라이언트에서 서버와 통신하는 데 사용됩니다. 따라서 Blazor Server를 사용하면 하나의 애플리케이션을 얻게 됩니다.

 

Blazor WASM을 사용하면 클라이언트가 브라우저에서 별도로 dotNet 런타임을 실행합니다. 호스트 된 모델은 별도의 dotNet Web API Server 프로젝트를 생성하지만 클라이언트는 기술에 구애받지 않습니다. 따라서 모든 백엔드를 사용할 수 있게 됩니다.

 

 

 

SignalR

 

SignalR은 Blazor Server에선 서버와 클라이언트가 지속적으로 통신하고 업데이트하기 위해 필요할 수 있습니다.

 

하지만 Blazor WASM에서는 좀 더 유연한 선택지가 있습니다. 이 문서에 따르면 호스팅 된 클라이언트 앱은 웹 API, gRPC-web 및 SignalR과 같은 다양한 메시징 프레임워크 및 프로토콜을 사용하여 네트워크를 통해 백엔드 서버 앱과 상호 작용할 수 있습니다.

 

Blazor WASM은 서버 측 입장에선 실체를 알 수 없습니다. 호스팅 된 모델은 서버 측을 생성하긴 하지만 기술적으로 원하는 아무것이든 사용할 수 있습니다. 

 

정리하자면 Blazor 서버에는 Signal R이 필요하지만 Blazor WASM은 기술에 구애받지 않습니다. Signal R을 사용하도록 만들 수 있지만 표준 HTTP 프로토콜만 있으면 됩니다.

 

 

 

Deploy

 

Blazor Server는 클라이언트 측을 컴파일하지 않습니다. 일단 애플리케이션에 연결되면 Signal R을 활용하여 웹 소켓 또는 다른 기술을 통해 클라이언트에 업데이트를 지속적으로 푸시합니다.

 

Blazor Server의 Publish 결과물

 

Blazor WASM은 클라이언트 측입니다. WASM 프로젝트를 컴파일할 때 React 애플리케이션에 대해 Webpack을 실행하는 것과 유사한 결과를 얻게 됩니다.

 

Blazor WASM의 Publish 결과물

 

Blazor WASM은 프런트엔드 기술이므로 정적 웹 페이지의 종속성으로 제공되거나 호스팅 된 모델과 같이 웹 API에 의해 확장 및 제공될 수 있습니다.

 

 

 

Pros and Cons

 

Blazor Server의 장점

• 다운로드 크기는 Blazor WebAssembly 앱보다 훨씬 작으며 앱이 훨씬 빠르게 로드되며 앱은 dotNET Core API 사용을 포함하여 서버 기능을 최대한 활용합니다.
• 서버의 dotNET Core는 앱을 실행하는 데 사용되므로 디버깅과 같은 기존 dotNET 도구가 예상대로 작동합니다.
• 씬 클라이언트가 지원됩니다. 예를 들어 Blazor Server 앱은 WebAssembly를 지원하지 않는 브라우저 및 리소스가 제한된 장치에서 작동합니다.
• 데이터베이스 또는 클라우드 기반 서비스와 같은 보안 리소스에 대한 액세스가 가능합니다.
• 앱의 구성 요소 코드를 포함한 앱의 dotNET/C# 코드 베이스는 클라이언트에 제공되지 않습니다.
• 신뢰할 수 있는 환경에서 모든 처리 코드를 실행하며 공개 API가 필요하지 않습니다.

Blazor Server의 단점

• 일반적으로 더 긴 대기 시간이 존재합니다. 모든 사용자 상호 작용에는 네트워크 홉이 포함됩니다.
• 오프라인 지원이 없습니다. 클라이언트 연결에 실패하면 앱이 작동을 멈춥니다.
• 사용자가 많은 앱을 확장하려면 여러 클라이언트 연결 및 클라이언트 상태를 처리하기 위한 서버 리소스가 필요합니다.
• 앱을 제공하려면 ASP.NET Core 서버가 필요합니다. CDN(콘텐츠 전송 네트워크)에서 앱을 제공하는 것과 같은 서버리스 배포 시나리오는 불가능합니다.

 

Blazor WASM의 장점

• 앱이 서버에서 다운로드된 후에는 dotNET 서버 쪽 종속성이 없으므로 서버가 오프라인 상태가 되어도 앱은 계속 작동합니다.
• 클라이언트 리소스와 기능이 완전히 활용됩니다.
• 작업이 서버에서 클라이언트로 오프로드 됩니다.
• 앱을 호스팅 하는 데 ASP.NET Core 웹 서버가 필요하지 않습니다. 이는 콘텐츠 전송 네트워크(CDN)에서 앱을 제공하는 것과 같은 서버리스 배포 시나리오가 가능하게 합니다.

Blazor WASM의 단점

• 앱은 브라우저의 기능으로 제한됩니다.
• 가능한 클라이언트 하드웨어 및 소프트웨어(예: WebAssembly 지원)가 필요합니다.
• 다운로드 크기가 더 크고 앱을 로드하는 데 시간이 더 오래 걸립니다.
• 보안 리소스에 액세스 하려면 별도의 API 계층이 필요합니다.
• 디버깅은 여전히 약간 제한적입니다.

 

 

 

References

 

• Blazor Server vs. Blazor WebAssembly
• Blazor Server side vs Blazor WebAssembly Hosted
• What Is Microsoft’s Blazor Web Framework, and Should You Use It?