렌더링 모드 선택 전
블레이저는 실제로 무엇인가 Blazor
Blazor는 .NET 웹앱을 위한 Microsoft의 구성 요소 프레임워크입니다. Razor 구성 요소에서 UI를 빌드하고, 대부분의 상호 작용 논리를 C#으로 작성하고, ASP.NET Core가 해당 구성 요소를 서버, WebAssembly 또는 기본 앱 셸 내부에서 렌더링하도록 합니다.
이는 오래된 ASP.NET 아이디어에서 발전했습니다. Web Forms는 서버 컨트롤 뒤에 웹을 숨기려고 했습니다. MVC 및 Razor Pages는 요청-응답 HTML 클리너를 만들었습니다. Blazor는 재사용 가능한 대화형 구성 요소를 추가하지만 간단한 콘텐츠 페이지 및 양식에 대해 MVC 또는 Razor Pages를 쓸모 없게 만들지는 않습니다.
Web Forms, MVC 및 Razor Pages는 다양한 문제를 해결했습니다.
Web Forms는 생산적이었지만 무겁고 상태가 저장되었습니다. MVC 및 Razor Pages는 더 깔끔한 HTML과 더 간단한 요청 처리 기능을 제공했습니다. 페이지가 주로 데이터를 읽고, 양식을 게시하고, HTML을 반환하는 경우에는 여전히 좋습니다.
구성요소는 UI 로직을 마크업에 가깝게 유지합니다.
Razor 구성 요소에는 마크업, 매개 변수, 이벤트, 유효성 검사, 삽입된 서비스 및 로컬 상태가 포함될 수 있습니다. 이는 전체를 다시 로드하지 않고도 페이지가 변경되는 대시보드, 편집기, 마법사, 그리드 및 도구에 유용합니다.
최신 .NET을 사용하면 렌더링 모드를 혼합할 수 있습니다
최신 Blazor 앱은 정적 서버 렌더링 HTML을 대화형 구성 요소와 결합할 수 있습니다. 한 페이지에는 크롤링 가능한 콘텐츠가 필요할 수 있고 다른 부분에는 라이브 구성 요소가 필요할 수 있으므로 이는 중요합니다.
목차
여기서 시작하세요
유용한 짧은 버전
Blazor는 하나의 아키텍처가 아닙니다. 여러 렌더링 모드가 있는 하나의 구성 요소 모델입니다. 올바른 선택은 구문보다는 상태, 대기 시간, 메모리 및 크롤링 가능한 링크가 어디에 있는지에 따라 달라집니다.
Blazor 서버는 상태 저장형입니다.
첫 번째 로드에서는 빠르게 느껴질 수 있지만 서버는 라이브 회로를 유지합니다. 트래픽이 증가하기 전에 메모리를 계획하고 동작을 다시 연결하고 확장하세요.
WebAssembly는 선불로 지불합니다.
라이브 서버 회로는 제거되지만 첫 번째 방문에서는 런타임과 앱이 다운로드됩니다. 캐시, 트리밍 및 사전 렌더링 문제.
하이브리드는 제품 결정입니다
앱에 실제로 데스크톱 또는 모바일 셸이 필요한 경우 하이브리드를 사용하세요. 공개 콘텐츠의 경우 웹 렌더링과 실제 URL을 사용하세요.
Blazor 서버
Blazor Server는 클릭 사이에도 작업을 계속 유지합니다.
Blazor Server는 일반적인 상태 비저장 요청-응답 페이지가 아닙니다. 연결된 브라우저 탭은 회로를 얻습니다. 서버는 사용자가 연결되어 있는 동안, 그리고 종종 연결이 끊긴 후 짧은 재연결 기간 동안 해당 회로에 대한 구성 요소 상태와 범위 서비스를 유지합니다.
활성 회로를 통해 메모리가 증가합니다.
연결된 각 탭에는 회로가 있습니다. 구성 요소 상태, 범위가 지정된 서비스, 유효성 검사 상태 및 보류 중인 UI 작업은 회로가 끝날 때까지 메모리에 유지될 수 있습니다. 부하 테스트에서는 초당 요청 수뿐만 아니라 활성 사용자 수도 계산해야 합니다.
지연 시간이 UI의 일부가 됨
버튼 클릭, 입력 이벤트 또는 그리드 상호 작용은 서버로 이동했다가 다시 돌아올 수 있습니다. 사용자와 가까운 곳에서 호스팅하고 청중이 여러 지역에 분산되어 있으면 수다스러운 구성 요소를 피하십시오.
수평 확장에는 계획이 필요합니다
여러 앱 인스턴스에는 고정 세션, SignalR 백플레인, Azure SignalR Service 또는 신중한 상태 설계가 필요한 경우가 많습니다. 그렇지 않으면 다시 연결되고 활성 회로가 잘못된 인스턴스에 연결될 수 있습니다.
좋은 적합성: 통제된 사용자
Blazor Server는 사용자, 대기 시간 및 호스팅 용량이 알려진 인증된 도구, 관리 화면, 대시보드 및 내부 앱에 가장 강력합니다.
Blazor WebAssembly
WebAssembly는 비용을 첫 번째 로드로 이동합니다.
Blazor WebAssembly는 서버 회로를 제거하지만 비용은 제거하지 않습니다. 경험이 빠르다고 느끼기 전에 브라우저는 .NET 런타임, 어셈블리, 지역화 리소스 및 앱 자산을 다운로드해야 합니다. 캐싱이 도움이 되므로 반복 방문이 좋을 수 있습니다. 첫 방문에는 관리가 필요합니다.
첫 번째 부담은 세금입니다.
브라우저는 .NET 런타임, 앱 어셈블리, 리소스 및 정적 자산을 다운로드합니다. 트리밍이 도움이 됩니다. 사전 컴파일은 CPU 사용량이 많은 작업을 개선할 수 있지만 종종 다운로드 크기가 증가합니다.
비밀은 클라이언트에 존재할 수 없습니다
WebAssembly 앱은 사용자의 브라우저에서 실행됩니다. 공개 프런트엔드처럼 취급하세요. 서버에 비밀을 유지하고, API를 보호하고, 클라이언트 코드를 검사할 수 있다고 가정합니다.
SEO에는 렌더링된 콘텐츠가 필요합니다
공개 기사, 제품 페이지, 랜딩 페이지의 경우 WebAssembly가 시작된 후에만 유용해지는 빈 셸에 의존하지 마세요. 서버측 렌더링, 사전 렌더링, 정적 렌더링 또는 별도의 콘텐츠 경로를 사용하세요.
적합성: 오프라인 또는 클라이언트 사용량이 많은 앱
WebAssembly는 사용자가 자주 돌아오거나 오프라인 동작이 필요하거나 서버 왕복이 더 나쁜 클라이언트 측 작업을 많이 수행할 때 잘 작동합니다.
하이브리드 및 WebView
하이브리드는 공개 랜딩 페이지가 아닌 앱을 위한 것입니다.
Blazor Hybrid는 .NET 팀이 데스크톱 또는 모바일 앱 내부의 구성 요소를 재사용하려는 경우에 유용합니다. WebView를 통해 기본 셸에서 실행되므로 로컬 파일, 장치 API 및 엔터프라이즈 배포에 근접할 수 있습니다. SEO 중심 웹사이트의 지름길은 아닙니다.
- 로컬 파일, 장치 API, 데스크톱 배포 또는 모바일 패키징에 액세스해야 하는 경우 하이브리드를 사용하세요.
- 웹 구성요소를 재사용하기 위해서만 하이브리드를 선택하지 마십시오. 기본 셸은 업데이트, 저장, 서명 및 지원 작업을 추가합니다.
- SEO 및 공유 가능한 공개 URL의 경우 일반적으로 하이브리드가 잘못된 표면입니다.
다국어 라우팅
문화 인식 링크는 실제 링크여야 합니다.
다국어 Blazor 사이트는 페이지가 대화형으로 전환된 후 클릭 처리기 또는 JavaScript에서만 언어 탐색을 빌드해서는 안 됩니다. 검색 엔진과 사용자에게는 초기 HTML에 안정적인 href 값, 표준 URL 및 hreflang 데이터가 포함된 실제 앵커 태그가 필요합니다.
- 슬래시 문화 슬래시 경로와 같이 직접 작성한 문자열 대신 중앙 페이지 링크와 도우미를 사용하세요.
- 초기 HTML 렌더링 중에 href 값이 있는 앵커 태그로 언어 링크를 렌더링합니다.
- 표준 URL, hreflang URL 및 표시되는 언어 탐색을 동기화 상태로 유지하세요.
- onclick 처리기, 지연된 JavaScript 또는 대화형 전용 Blazor 상태 뒤에 중요한 링크를 숨기지 마십시오.
선택 가이드
허용되는 병목 현상을 기준으로 선택하세요.
모든 렌더링 모드는 압력을 다른 위치로 이동합니다. 측정하고 주최하고 팀에 설명할 수 있는 압력을 선택하세요.
첫 번째 로드와 .NET 백엔드 통합이 가장 중요한 경우
서버 메모리, 라이브 연결 및 지역 대기 시간이 운영 비용으로 허용되는 제어되고 인증된 앱의 경우 Blazor Server를 선택하세요.
고객의 업무와 오프라인 행동이 가장 중요한 경우
반복 방문, 캐싱, 오프라인 사용 또는 로컬 CPU 작업이 가장 작은 첫 번째 로드보다 더 중요한 경우 WebAssembly를 선택하세요.
제품이 실제로 네이티브 앱인 경우
애플리케이션이 데스크톱이나 모바일에 속하고 공개 웹 연결보다 로컬 통합이 더 필요한 경우 하이브리드를 선택하세요.
사이트가 대부분 문서와 양식인 경우
클래식 ASP.NET Core MVC 또는 Razor Pages는 콘텐츠가 많은 사이트, 공개 문서 및 상호 작용이 제한된 양식에 대해 더 간단한 경우가 많습니다.
참고 섹션
실제로 구축할 때 다음 내용을 읽어보세요.
이러한 참조는 메타데이터, 언어 링크, 호스팅, 재사용 가능한 UI 등 프로덕션에서 Blazor 페이지를 안정적으로 만드는 부분을 다루기 때문에 아키텍처 결정 후에 유용합니다.
모든 페이지에 일관된 제목, 설명, 오픈 그래프, 표준 및 JSON-LD 출력이 필요한 경우 이 기능을 사용하세요.
SEO 친화적 로케일 링크다국어 라우팅에 실제 크롤링 가능한 링크, 안정적인 문화 경로 및 올바른 hreflang 출력이 필요한 경우 이 기능을 사용하세요.
UpCloud에 Blazor 호스팅Blazor Server 앱에 소규모 VPS, Nginx, TLS, systemd, 로그, 백업 및 반복 가능한 배포가 필요한 경우 이 기능을 사용하세요.
TablerForNet값이 마케팅 페이지 대신 관리 인터페이스, 데이터 테이블, 양식 및 대시보드 화면인 경우 이를 사용하십시오.
Blazor다음 구현 세부 사항을 선택하기 전에 관련 가이드를 한 곳에서 확인하려면 Blazor 허브를 사용하세요.
자주 묻는 질문
Blazor Server에 MVC보다 더 많은 메모리가 필요한 이유는 무엇입니까?
MVC는 요청을 완료하고 대부분의 요청 상태를 해제할 수 있습니다. Blazor Server는 연결된 각 브라우저 탭에 대한 회로를 유지하므로 구성 요소 상태와 범위가 지정된 서비스는 클릭 간에 유지될 수 있습니다.
여러 앱 인스턴스에서 Blazor Server를 실행할 수 있나요?
예, 하지만 의도적으로 계획하세요. 라이브 회로 및 SignalR 연결에는 안정적인 라우팅, 백플레인 또는 관리되는 SignalR 서비스 및 재연결이 올바르게 유지되는 애플리케이션 상태가 필요합니다.
Blazor WebAssembly는 SEO 친화적일 수 있나요?
예. 하지만 빈 셸을 배송하고 크롤러가 기다리기를 바라면 안 됩니다. 공개 페이지에는 첫 번째 응답 전이나 도중에 렌더링된 HTML, 메타데이터, 표준 링크 및 구조화된 데이터가 필요합니다.
다국어 Blazor 링크는 어떻게 구축해야 합니까?
중앙 경로 정의를 사용하고 각 문화권에 대한 실제 앵커 태그를 렌더링합니다. 사용자와 크롤러가 동일한 언어 구조를 볼 수 있도록 표시되는 링크, 표준 URL 및 hreflang 데이터를 정렬하세요.