선용 - "C# SPA의 Blazer 및

"C#에서 SPA를 만들 수 있다니, 어떻게 된 일입니까?"
C#로 스파 하면 뭐가 좋아?
"Blazor에는 클라이언트 버전과 서버 버전이 있다고 들었습니다."
이 화제에 관해서 나는 아래의 슬라이드를 참고할 수 있다고 생각한다.

Blazor를 다시 추천한 사람은 누구입니까?

C#로 SPA의 Blazer를 구현할 수 있지만 "은폭탄".에는 전혀 없습니다.
그럼 도대체 어떤 사람들이 Blazor를 추천할 수 있을까요? 생각해 봤어요.

조건C#로 쓰고 싶은 사람/쓰기 좋은 사람

우선 원래부터 C#로 프로그램을 쓰는 것을 좋아하는 사람을 대상으로 했다.
ASP는 서버 측 웹 응용 프로그램에 이미 설치되어 있습니다.NET를 사용하는 사람은 물론 Xamarin, UWP, Unity, WPF, Windows Forms 등에 C#를 설치한 사람도 추천할 수 있습니다.
'프로그래밍 언어는 C#의'뿐만 아니라 익숙한 IDE와 기존 누겟 포장 친환경 시스템 등을 사용해 블라조어 앱 개발에서도 그대로 활용할 수 있다는 점도 매력이다.
"JavaScript 쓰기 싫다고 우기네요".이런 층은 부정적인 이유지만 블라조르를 추천하는 층이 될 수도 있다.
그럼에도 불구하고 블라조어 앱을 써도 조금 신경 쓰는 일을 하고 자바스크립트를 쓰지 않으면 의사소통이 안 되는 장면이 나온다.
그래서 이런 계층에 추천하는 게 어떨까 싶어요.
(참고로 C#이 아닌 Elixir라면 LiveView 선택 항목으로 사용할 수 있습니다.)

조건SPA 또는 동등한 사용자 환경이 필요한 사용자

설령 조건 1이 된다 하더라도 SPA(즉 Single Page Application)처럼 서버 측과 페이지를 하나씩 왕복하지 않고 브라우저에서 사용자와 상호작용을 할 필요가 없다. 이런 웹 응용 프로그램이 필요한지블라조르가 변하는 걸 추천해줄 수 있을까 해서요.
이러한 사용자 체험이 필요하지 않은 상황에서 예를 들어 기업의 소개 공식 사이트처럼 사용자와 상호작용이 거의 없는 상황에서 C#로 실현을 요구하더라도 Blazor가 아니라 일반적인 ASP이다.NET 서버 측면 설치(ASP.NET Core MVC, Razor Pages 등)도 충분하다고 볼 수 있다.
또한 학습 비용에서 새로운 ASP가 제공됩니다.NET Core MVC와 Razor Pages를 배우는 것은 Blazor를 배우는 것과 크게 다르지 않다.
그러나 Blazer는 학습 비용에 문제가 없더라도 다른 일반적인 JavaScript SPA 프레임워크에 비해 절충이 발생할 수 있다(자세한 내용은 뒤에 서술할 것이다).
요약하면 위 사용자와 대화가 거의 없는 웹사이트를 구축해 블라조르가 아닌 ASP로 만들었다.NET Core MVC와 Razor Pages 등 서버 측의 웹 애플리케이션을 설치하는 것이 더 좋지 않을까 싶습니다.
(더 따지면 정적 사이트Generation도 선택항으로 뽑히지만 사랑받지 못한다)

조건 3-1.항상 접속할 수 있습니까?

조건에 맞는 1, 2는 블레이저를 추천할 수 있는 사람이다.
그러나 다음에는'서버 측의 Blazor'와'클라이언트 측의 Blazor'가 어떤 호스트 모델을 선택해야 하는지 판단해야 한다.
여기서 서버 측과 클라이언트 측이 자주 연결해야 한다면 서버 측의 Blazor를 추천합니다.
서버 측 블라조르는 2019년 9월 공식 출시됐으며, 비주얼스튜디오와 비주얼스튜디오코드도 디바가 지원에 협조할 예정이다.
또한 클라이언트와 서버 측을 웹 API로 연결할 필요가 없고 위에 서버 측의 설치를 적으면 SPA처럼 민첩한 사용자 상호작용을 실현할 수 있다는 점도 흥미로운 부분이다.

조건 3-1-1.서버측.NET Core 실행 환경을 준비할 수 있습니까?

조건 3-1에 부합한다면 서버 측의 Blazor로 하세요. 글에서 보듯이'서버 측의 이동'Blazor, 즉 본질적인 ASP입니다.NET Core의 서버 측 웹 응용 프로그램 설치이기 때문에 서버 측에 있습니다.NET Core 실행 환경이 필요합니다.
뭐, 오늘부터 Docker 컨테이너가 서버로 이동하면.NET Core 실행 환경에 대한 준비는 어렵지 않을 것입니다(참조: ".NET Core - Docker Hub - Official images for .NET Core and ASP.NET Core".
물론 PaaSAzure Web Apps로 구성해도 될 것 같은데'롤리 유행 요소'도 좋아요.NET Core를 선택할 수 있습니다..
그럼에도 스스로 스크래치로 서버 측을 설치하는 대신 Firebase로 이동하거나 Netlify로 이동하는 경우도 있다.
이 경우 서버의 실행 환경으로서NET Core를 사용할 수 없기 때문에 결과적으로 서버 측 Blazor가 선택 항목에서 누락됩니다.

조건 3-2.사이트의 내용 사이즈가 커지는 것을 허락할 수 있습니까?

조건 3-1이 항상 연결되어야 하는 경우, 예를 들어 PWA와 같은 오프라인 동작이 필요한 경우 다음 옵션은 고객측 Blazor입니다.
그러나 고객 측의 Blazor는 적어도 지금은 내용 사이즈가 커지기 쉽다.
실제 사이즈가 어떻게 되는지 참고로 GiitHub"Blazor 애플리케이션 구축 워크숍"(아래 그림)에 공개됐는데 이걸 봤어요.

트위터 인증을 통해 피자 주문을 받고 지도를 통해 배송 상황을 보여주는 그나마 양이 많은 온라인 애플리케이션이다.
손 옆에 git clone이 실행을 시도한 곳에서 브라우저가 읽은 내용의 사이즈는 6.3MB(통신은 gzip이 압축되어 통신상의 전송 용량은 3.2MB)이었다.
이미지 클래스를 빼면 5.4MB(전송 용량 2.4MB) 정도다.
그나저나 휴대전화 버전의 트위터는 약 3MB 정도다.
이 클라이언트 Blazor의 컨텐츠 크기가 허용되지 않을 경우 Bluetooth, React, Anglar 등 JavaScript를 사용하여 SPA를 구현하는 것이 좋습니다.

조건 3-2-1.처리 속도를 구하지 않았습니까?

그 전까지는 1, 2, 3-1을 충족해도 계속됐다.
오늘 고객사 Blazor는 MSIL(IL, C# 완성된 중간 언어 컴파일링)을 해석기로 수행했습니다.
따라서 컴퓨터의 처리 속도는 JavaScript보다 못하다고 여겨진다.
처리 속도를 요구하는 상황에서 고객측 Blazor는 불리하다고 할 수 있다.
그러나 스스로 스파 실장을 시도한 범위 내에서는 몸이 무겁거나 느린 정도는 느끼지 못했다.
또 해석기 방식이 아니라 로컬의 웹 어셈블리 코드로 사전 컴파일하는 방식도 시도하고 있는 것 같다.

GitHub - aspnet/AspNetCore - Issue #5466 - "AoT compilation"

총결산

이상

조건 1.C#로 쓰기/쓰기 좋은 사람

조건 2.SPA 또는 동등한 사용자 환경이 필요한 사람

조건 3-1.항상 접속할 수 있습니까?

조건 3-1-1.서버측.NET Core 실행 환경을 준비할 수 있습니까?

조건 3-2.사이트의 내용 사이즈가 커지는 것을 허락할 수 있습니까?

조건 3-2-1.처리 속도를 구하지 않았습니까?

조건부 사람, 블라조르를 추천할 수 있는 사람 아닌가.
겸사겸사 말씀드리지만 저는...

서버 측면을 ASP로 설정합니다.NET Core에 작성된 것이기 때문에 클라이언트/서버 간에 모델 유형을 공유하거나 모델의 속성에 대한 제약을 지정하여 입력을 검증하는 등 장점이 많음(조건1 제거)

사용자 상호작용이 많이 적힌 업무용 웹 응용 프로그램(조건2 삭제)

필요조건 하에서는 항상 접속해야 함(조건 3-1NG)

하지만 사이즈가 커서 소비자를 위한 것이 아니기 때문에 문제가 없을 것이다

(사이즈가 조금 크더라도 업무용이기 때문에 w를 사용할 수밖에 없다) (조건 3-2 제거)

비즈니스 응용프로그램이므로 빠른 처리 속도가 필요하지 않음(3-2-1 정리 조건)

이렇게 되면 고객사인 블라조르가 추천할 수 있는 사람이 된다.
참고로 우리측은 Azure 웹 앱을 사용하기 때문에 자주 연결해야 하는 것을 허락할 수 있다면 서버 측의 Blazor도 선택항으로 할 수 있다(조건 3-1 제거)
Happy Coding :)