Blazor란?

Blazor는 JavaScript 대신 C#을 사용하여 대화형 웹 UI를 구축할 수 있는 새로운 프레임워크입니다. 완전히 새로운 언어를 배우지 않고 웹 개발에 활용하려는 .NET 개발자에게 탁월한 옵션입니다. 현재 Blazor를 사용하는 두 가지 방법이 있습니다. 신 클라이언트(thin client)가 있는 ASP.NET Core 서버에서 실행하거나 JavaScript 대신 WebAssembly를 사용하여 클라이언트의 웹 브라우저에서 완전히 실행하는 것입니다.

이 글에서는 Blazor와 WebAssembly를 소개하고 .NET 개발자용 Blazor 생성에 대해 학습한 다음 샘플 Blazor 애플리케이션와 구성 요소를 빌드합니다.

많은 .NET 개발자는 최근까지도 손이 닿지 않는 것처럼 보이는 꿈을 공유하고 있었습니다. 바로 어디에서나 .NET 앱을 실행할 수 있는 능력입니다! 이 꿈의 씨앗은 2001년에 .NET Framework가 1년이 되지 않았고 Mono라는 오픈 소스 프로젝트가 발표되었을 때 심어졌습니다. Ximian 프로젝트 팀은 2004년에 Mono를 출시하고 그 꿈을 Linux 플랫폼에 옮겨 왔습니다. 몇 년 후, 플로그인의 도움으로 인터넷 익스플로러에서 Silverlight가 개발자들에게 C# 및 VB.NET을 실행할 수 있게 함으로써 그 꿈은 더 커졌습니다. 꿈은 추진력을 얻었고, 다른 브라우저에 도달할 뿐만 아니라, 심지어 짧게는 모바일까지 손을 뻗었습니다.

2016년 .NET Core가 출시되면서 꿈은 현실에 가까워졌고 Windows, Linux 및 MacOS를 수용하기 위해 .NET의 범위가 확대되었습니다. 최근에는 개발자가 데스크탑, 랩탑, 태블릿, 전화기, 게임, 센서 및 클라우드에서 .NET을 실행할 수있었습니다.

그러나 한 개척자는어디에서나 .NET을 실행하려는 꿈의 길에 지속적으로 서있었습니다. : 브라우저입니다. ActiveX와 플러그인은 한 쪽으로 치워졌고 개발자들은 JavaScript라는 최신 브라우저에서 실행되는 코드를 작성해야 하는 단일의 선택권과 함께 남겨졌습니다.

JavaScript가 정말 유일한 방법일까요? 정답은: 아니오!

새로운 희망 : WebAssembly

몇 년 전만 해도 자바스크립트에 대한 대안이 출시되어 Chrome, Edge, Firefox 및 Opera를 포함한 최신 주요 브라우저 버전으로 구현되었습니다. 이 대안은 32비트와 64비트 플랫폼 간에운영 체제, 주요 브라우저 브랜드 내부에서 재컴파일없이 일관되게 코드를 실행하는 스택 기반 가상 머신이며 모바일 장치에서도 지원됩니다.

WebAssembly (또는 Wasm)는 바이트코드 명령어를 실행하는 샌드 박스입니다. 지시사항은 미리 정의되어 있고, 강력하게 형식화되어 있으며 JavaScript의 한계를 초월하는 일련의 작업을 포함합니다. 결과적으로 Wasm은 다양한 언어와 런타임에 적합한 컴파일러 대상입니다.

WebAssembly가 출시된 직후, 2001년에 시작된 Mono 프로젝트는 브라우저에서 성공적으로 실행되어 .NET 코드를 가져 왔습니다. 꿈은 거의 실현되었습니다.

브라우저에서 .NET을 실행해야 하는 이유는 무엇입니까?

• .NET은 C#과 같은 최신 언어를 지원합니다.
• 솔루션의 대규모 .NET 생태계가 이미 존재합니다.
• .NET은 성능 향상을 위해 지속적으로 조정되었습니다.
• .NET 솔루션을 구축하기 위한 강력한 도구 모음이 있습니다.
• 프레임워크는 안정적이고 발전됐습니다.

그러나 브라우저 내에서 .NET 자체로는 그림을 완성하지 못합니다. WebAssembly는 브라우저의 DOM (Document Object Model)과 직접적으로 HTML을 렌더링하기 위해 상호 작용할 수 없으며 JavaScript를 "접착제"로 사용해야 합니다. 그리고 .NET에는 HTML용 렌더링 엔진이 포함되어 있지 않습니다.

이러한 격차를 해소하기 위해 마이크로소프트의 수석 소프트웨어 엔지니어인 Steve Sanderson은 Blazor를 만들었습니다. 꿈이 실현됐습니다!

풀 스택 개발에서 Blazor 사용

Blazor는 브라우저에서 .NET으로 실행되는 싱글 페이지 애플리케이션(SPA) 프레임워크입니다. Blazor는 .NET 위에 있으며 전체 스택은 아래 그림에 설명되어 있습니다.

Blazor는 .NET과 브라우저간 격차를 해소하기 위한 다음을 포함한 여러 서비스를 제공합니다.

• 브라우저로 전송되는 페이로드를 줄이기위한 어셈블리 트리밍(Assemly trimming)
• 재사용 가능한 컴포넌트 모델(component model)
• 디버깅(debugging) 경험
• 의존성 주입(Dependency injection)
• 양식 및 검증(Forms and validation)
• IntelliSense 및 툴링(tooling)
• 자바스크립트 상호 운용성(JavaScript interoperability)
• 레이아웃(Layouts)
• 라우팅 서비스(Routing service)
• 서버 사이드 렌더링(Server-side rendering)
• 정적 파일 게시(Static file publishing)
• 단위 테스트(Unit testing)

“Blazor”라는 이름은“browser”와“Razor”에서 파생되었습니다. Razor는 Blazor가 사용자 인터페이스를 정의하고 렌더링하기 위해 사용하는 템플릿 엔진을 말합니다. Blazor는 새로운 것이지만 Razor는 그렇지 않습니다. 실제로 Razor는 2011년 처음 릴리즈된 이후로, ASP.NET MVC 개발자들에게 사용되었던 view 엔진입니다. 또한, ASP. NET Core와 Razor 클래스 라이브러리를 통해 기존 ASP.NET  MVC 애플리케이션 간에 동일한 구성 요소를 공유 할 수 있습니다. Microsoft Docs에서 온라인으로 전체 Blazor 설명서를 읽어보세요.

Razor

Razor는 view를 Razor 마크업 구문, HTML와 C#의 조합으로 정의합니다. View 구성 요소와 페이지는 일반적으로 .cshtml 확장명으로 정의되는 반면 재사용 가능한 Razor 구성 요소는 .razor 확장명을 갖습니다. Razor 파일에는 HTML이 포함되어 있습니다.

코드 파일 내에서 @ 기호는 HTML에서 C# 코드로의 전환을 나타냅니다. C#이 평가되고 결과가 템플릿에 삽입됩니다. Razor는 다음과 같은 간단한 문구로 작성될 수 있습니다.

<h1>@DateTime.Now</h1>  

이것은 다음을 렌더링합니다.

또한 표현식과 루프를 포함하여 더 복잡한 명령문을 작성할 수도 있습니다. 다음 템플릿에는 배열을 초기화하는 구문과 코드가 포함되어 있습니다.

<ul>  
    @foreach(int num in Fibonacci)  
    {  
        <li>@num * 2 = @(num*2)</li>  
    }  
</ul>  
@code {  
    public int[] Fibonacci = new int[] { 1, 1, 2, 3, 5, 8 };  
}

결과는 다음과 같습니다.

Blazor 아키텍처는 ASP.NET MVC 개발자에게 매우 친숙합니다. 더 나아가 Blazor는 Razor 구성 요소를 공유할 수 있을 뿐만 아니라 비슷한 라이프 사이클를 따르고 종속성 주입 및 미들웨어를 지원합니다. Startup 클래스에는 ConfigureServices 함수를 포함하여 MVC 개발자가 기대하는 것과 동일한 메소드가 포함되어 있습니다.

public void ConfigureServices(IServiceCollection services)  
{  
    services.AddRazorPages();  
    services.AddServerSideBlazor();  
    services.AddSingleton<WeatherForecastService>();  
}  
…and a Configure method:  
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)  
{  
    if (env.IsDevelopment())  
    {  
        app.UseDeveloperExceptionPage();  
    }  
    else  
    {  
        app.UseExceptionHandler("/Error");  
        app.UseHsts();  
    }

    app.UseHttpsRedirection();  
    app.UseStaticFiles();

    app.UseRouting();

    app.UseEndpoints(endpoints =>  
    {  
        endpoints.MapBlazorHub();  
        endpoints.MapFallbackToPage("/_Host");  
    });  
}

앞의 예는 "ServerSideBlazor"구현을 나타냅니다. 이 부분은 좀 더 설명이 필요합니다.

서버 사이드와 클라이언트 사이드 Blazor

2017년에 소개된 Blazor는 빠르게 추진력을 얻었습니다. “실험적인 프로젝트”로 출시된 Blazor는 ASP.NET 팀에 의해 공식적인 채택 이전까지는 미래가 불확실했습니다. Blazor가 ASP.NET Core로 인수된 후, 클라이언트 사이드(Blazor WebAssembly)가 제작을 준비하기 전에 많은 작업이 필요하다고 신속하게 결정되었습니다.

성능 최적화, 어셈블리 트리밍, 디버그 경험 등을 위해서는 여전히 작업이 필요합니다. 따라서 클라이언트 사이드 Blazor는 미리 공개된 기능으로 출시되었습니다. Visual Studio 2019의 미리 공개된 버전 (또는 미리 공개된 버전이 아니라면 설정에서 "미리 고갱 사용" 옵션을 설정한 경우) 에서만 사용할 수 있습니다.

다행히도 Blazor의 아키텍처는 Blazor 로직과 실제 렌더링 엔진을 분리합니다. 왜냐하면 클라이언뿐만 아니라 서버에서 실행되고 참조될 수 있는 .NET 기준 라이브러리이기 때문에 팀은 서버 사이드 버전으로 만들기로 결정합니다. Microsoft Docs 에서 Blazor 호스팅 모델에 대해 자세히 알아보도록 합니다.

서버 사이드 버전은 동일한 규칙과 Razor 템플릿을 사용하며 클라이언트 사이드와 동일한 지원을 갖습니다. 차이점은 코드가 클라이언트의 WebAssembly가 아니라 서버에서 완전히 실행된다는 것입니다.

서버 측 Blazor가 실행되면 서버와 실시간 통신을 설정하는 브라우저로 경량 JavaScript 클라이언트가 전송됩니다. 서버는 렌더링을 포함하여 로직을 처리한 다음 결과를 클라이언트로 전송합니다. 결과는 경량 또는 작업을 서버에 사용하는 "씬 클라이언트"(thin client)로 만들어집니다. Blazor의 이 버전은 생산 준비가 완료되었으며 ASP.NET Core 3.0의 일부로 제공됩니다.

중요한 것은 Blazor 엔진을 사용하기 때문에 대부분의 경우 서버 측 코드는 구성 설정으로 간단하게 전환되어 클라이언트에서 "있는 그대로" 실행됩니다. “생산 준비(production-ready)”와“미리 공개(preview)”의 차이점 외에도 두 버전을 볼 때 고려해야 할 몇 가지 장단점이 있습니다.

장단점을 기반으로 클라이언트 측 Blazor에 중점을 둔 많은 개발자는 WebAssembly와 서버 사이드 프로젝트간에 공유되는 구성 요소를 갖춘 구현을 사용하고 있으며 서버 사이드는 생산과 디버깅에 사용됩니다. 클라이언트 측은 프로덕션으로 제공되며 클라이언트가 미리보기를 종료할 때 서버 사이드를 대체하는 데 사용됩니다.

기본 Blazor UI 컨트롤 vs. 랩핑된 JavaScript

UI 구성 요소 라이브러리는 Blazor보다 훨씬 이전에 생성되었습니다. 웹 애플리케이션을 대상으로 하는 대부분의 기존 프레임워크는 JavaScript를 기반으로합니다. JavaScript와의 상호 운용성으로 인해 여전히 Blazor와 호환됩니다. 기본적으로 JavaScript를 기반으로 하는 구성 요소는 Blazor 컨트롤 이라고하는 Blazor로 작성된 구성 요소와 달리 랩핑된 JavaScript 컨트롤 이라고 합니다 .

Native Blazor 컨트롤은 Razor 구문을 분석하여 해당 컨트롤의 UI 및 동작을 나타내는 렌더링 트리를 생성합니다. 렌더 트리는 서버 사이드 Blazor를 실행할 수 있는 이유입니다. 트리는 분석되어 렌더링을 위해 클라이언트로 전송되는 서버에서 HTML을 생성하는 데 사용됩니다. Blazor WebAssembly의 경우, 클라이언트에서 렌더 트리는 분석되고 렌더링됩니다. 어느 쪽이든 Blazor는 컨트롤을 구성하는 요소에 대한 내부 참조를 유지하고 필요할 때 다시 렌더링하여 UI 새로고침을 처리합니다.

랩핑된 JavaScript 컨트롤에는 다음과 같은 주의사항이 있습니다.

• 랩핑된 컨트롤은 필요할 때 JavaScript를 호출하여 UI 새로고침을 작동시키는 것을 주의해야합니다.
• 내부 Blazor 렌더 트리가 없으므로 요소를 참조하려면 종종 DOM을 통과해야 합니다.
• 중첩 및 동적 컨트롤에 대한 지원이 제한될 수 있습니다.
• JavaScript는 Blazor 폼 및 유효성 검사 시스템에 직접 바인딩되지 않으므로 사용자 지정 유효성 검사 또는 Blazor와 JavaScript 간 브리지를 구축해야 합니다.

반면에 랩핑된 컨트롤의 이점은 다음과 같습니다.

• HTML, CSS 및 JavaScript를 기반으로 기존 구성 요소를 완벽하게 지원합니다.
• 기본 JavaScript 렌더링 덕분에 대부분은 더 좋은 퍼포먼스를 보여줍니다. 
• 참조 또는 패키지를 업데이트하고 앱을 재컴파일하지 않고 제어 라이브러리를 업데이트하는 것처럼 업데이트로 유지 관리가 향상될 수 있습니다.

랩핑된 JavaScript 컨트롤에 대한 자세한 내용은 Blazor 구성 요소 내부에서 JavaScript Interop을 사용하는 방법을 참조합니다.

Visual Studio에서 Blazor WebAssembly 시작하기

Blazor는 짧은 기간에 불구하고 매우 발전된 툴링과 지원을 받았습니다. Visual Studio 2019의 최신 안정화된 버전은 즉시 사용할 수 있는 완전한 서버 사이드 Blazor를 완벽하게 지원합니다. 여기에는 프로젝트 및 구성 요소 생성과 IntelliSense 사용, 빌드, 디버그, 게시 및 배포 기능이 포함됩니다.

Visual Studio에서 Blazor WebAssembly에 대한 미리 공개 지원은 설정(Settings) → 환경(Environment) → 미리 공개 기능(Preview Features)으로 이동하여 ".NET Core SDK의 미리보기 사용(Use previews of the .NET Core SDK)"을 체크하여 사용할 수 있습니다. 대부분의 주요 구성 요소 공급 업체도 Blazor를 지원합니다.

예를 들어 GrapeCity는 기본 및 랩핑된 JavaScript Blazor 컨트롤을 모두 제공합니다. 차이점은 랩핑한 프로세스가 더 빠르기 때문에 랩핑된 컨트롤이 더 완벽하다는 점이며, 회사는 수년간의 개발을 통해 전체 컨트롤 제품군을 활용할 수있었습니다. GrapeCity의 JavaScript UI 컨트롤 전체 제품군인 Wijmo는 WijmoBlazor를 통해 사용할 수 있습니다. 기본 컨트롤 제품군은 크기는 작지만 향후 몇 년 동안 빠르게 확장할 수 있습니다. ComponentOne Blazor Edition을 다운로드하여 베타 버전을 사용해 볼 수 있습니다 .

크로스 플랫폼, 오픈 소스 편집기인 Visual Studio Code를 사용하여 Blazor 프로젝트를 작업 할 수도 있습니다. Blazor 프로젝트를 열면 IntelliSense와 Blazor 앱 빌드, 디버깅 및 Blazor 앱 게시에 필요한 지원을 설치하라는 메시지가 표시됩니다. 단 3줄의 스크립트만으로 .NET Core command-line interface(CLI)로부터 Blazor 앱을 만들고 실행할 수 있습니다. 소스 디렉토리에서 다음을 입력합니다.

dotnet new blazorserver -o MyFirstBlazorApp  
cd MyFirstBlazorApp  
dotnet run  

내장된 샘플 앱은 ASP.NET MVC 템플릿과 동일한 예를 사용하여 쉽게 비교합니다.

첫 Blazor 앱

Blazor가 어떤 도움을 주는지 보여줄 수 있는 실제 앱을 만들어 보겠습니다.

이 예에서는 웹 개발 워크 플로우와 함께 Visual Studio 2019 16.3 이상이 설치되어 있어야 합니다. 새로운 프로젝트를 만들고 “Blazor App”을 선택합니다. 이름과 코드의 위치를 ​​지정한 다음 작성을 클릭합니다. 모든 기본값을 유지합니다. 대화 상자는 다음과 유사해야 합니다. : 

프로젝트가 초기화 될 때까지 기다린 다음, CTRL + F5를 눌러 빌드 및 실행을 확인하십시오.

첫 번째 Blazor 프로젝트 생성을 한 후, 첫 번째 컴포넌트를 만듭니다. 공유 폴더에 마우스 오른쪽 버튼으로 클릭하고 추가(Add)를 클릭한 다음 새 항목(New Item)을 선택하거나 Ctrl + Shift + A를 누릅니다. 대화 상자에서 Razor Component를 선택하고 이름을 "Info.razor"로 지정합니다.

기본 템플릿을 다음 마크업과 코드로 바꿉니다.

<h3>@TheDate: @Environment</h3>  
<button **@onclick**="RefreshDate">Refresh</button>

@code {  
    public string Environment { get; set; }  
    public DateTime TheDate { get; set; }

    protected override void OnInitialized()  
    {  
        Environment = System.Environment.OSVersion.VersionString;  
        RefreshDate();  
    }

    public void RefreshDate()  
    {  
        TheDate = DateTime.Now;  
    }  
}

@code 블록에는 구성 요소 클래스의 일부로 작성된 속성 및 메소드가 포함되어 있습니다. @TheDate 규칙은 구성 요소의 관련 속성에 바인딩됩니다. 버튼 요소는 어떻게 JavaScript 이벤트에 바인딩하는지에 대한 방법을 보여줍니다. 이벤트 앞에 @를 붙이면 대상이 JavaScript가 아닌 C# 방식으로 해석됩니다. 코드 본문에서 구성 요소가 초기화될 때 라이프 사이클 이벤트가 유발되고 OS 버전이 서버에서 실행 중임을 표시하도록 설정됩니다.

@code 태그 앞에 마크업을 추가하여 구성 요소를 Pages 폴더의 Counter.razor 페이지에 놓습니다.

<Info></Info> 

애플리케이션을 실행하고 디버깅 콘솔 (F12)을 열어 네트워크(Network) 탭으로 이동합니다. 앱 (F5)을 새로 고치고 다음과 같이 WebSocket 연결을 찾습니다.

그런 다음 WebSocket을 클릭하여 메시지를 표시합니다. 카운터(Counter) 페이지로 이동하여 새로 고침 버튼을 클릭합니다. 서버 발송 업데이트를 볼 수 있습니다.

축하합니다! Blazor 앱을 만들고 구성 요소를 구축하고 첫 번째 라이프 사이클 및 데이터 바인딩 코드를 작성했습니다.

Blazor와 WebAssembly : 미래

Blazor는 .NET을 어디에서나 실행하려는 꿈을 실현하고 마침내 C#을 사용하여 싱글 페이지 애플리케이션을 작성할 수 있게 되었습니다. Blazor 아키텍처는 종속성 주입, 미들웨어 구성과 같은 서버 측 ASP.NET MVC와 Blazor 기능과 유사하고 Razor 구성 요소는 숙달된 개발자들에게 이미 친숙합니다. Blazor WebAssembly는 2020년 5월에 출시되었으며 개발자는 지금 시작하여 다른 프로젝트에서 사용하는 것과 동일한 웹 구성 요소를 즉시 활용할 수 있습니다.