기존 Web Apps와 SPA(단일 페이지 앱) 중에서 선택

"Atwood의 법칙: JavaScript로 작성할 수 있는 모든 애플리케이션은 결국 JavaScript로 작성됩니다."
- 제프 앳우드

현재 웹 애플리케이션을 빌드하는 일반적인 방법은 서버에서 대부분의 애플리케이션 논리를 수행하는 기존 웹 애플리케이션과 웹 브라우저에서 대부분의 사용자 인터페이스 논리를 수행하는 SPA(단일 페이지 애플리케이션)로, 주로 웹 API를 사용하여 웹 서버와 통신하는 두 가지 일반적인 방법이 있습니다. 하이브리드 접근 방식도 가능하며, 가장 간단한 방법은 더 큰 기존 웹 애플리케이션 내에서 하나 이상의 풍부한 SPA와 유사한 하위 애플리케이션을 호스트하는 것입니다.

다음과 같은 경우 기존 웹 애플리케이션을 사용합니다.

• 애플리케이션의 클라이언트 쪽 요구 사항은 간단하거나 읽기 전용입니다.

• 애플리케이션은 JavaScript 지원 없이 브라우저에서 작동해야 합니다.

• 애플리케이션은 공용이며 검색 엔진 검색 및 조회의 이점을 누릴 수 있습니다.

다음과 같은 경우 SPA를 사용합니다.

• 애플리케이션은 많은 기능이 있는 풍부한 사용자 인터페이스를 노출해야 합니다.

• 팀은 JavaScript, TypeScript 또는 BlazorWebAssembly 개발에 익숙합니다.

• 애플리케이션은 이미 다른(내부 또는 공용) 클라이언트에 대한 API를 노출해야 합니다.

또한 SPA 프레임워크에는 더 큰 아키텍처 및 보안 전문 지식이 필요합니다. 기존 웹 애플리케이션보다 자주 업데이트되고 새 클라이언트 프레임워크로 인해 변동이 더 커지게 됩니다. 자동화된 빌드 및 배포 프로세스를 구성하고 컨테이너와 같은 배포 옵션을 활용하는 것은 기존 웹앱보다 SPA 애플리케이션에서 더 어려울 수 있습니다.

SPA 접근 방식에서 가능해진 사용자 환경의 개선 사항은 이러한 고려 사항에 대해 고려해야 합니다.

Blazor

ASP.NET Core에는 다양한 대화형 및 구성 가능한 사용자 인터페이스를 빌드하기 위한 모델이 포함되어 Blazor있습니다. Blazor 서버 쪽을 사용하면 개발자가 서버에서 C# 및 Razor를 사용하여 UI를 빌드하고 영구 SignalR 연결을 사용하여 실시간으로 UI를 브라우저에 대화형으로 연결할 수 있습니다. Blazor WebAssembly는 Blazor 앱의 또 다른 옵션을 소개하며, WebAssembly을 사용하여 브라우저에서 실행할 수 있도록 합니다. 실행 중인 WebAssembly실제 .NET 코드이므로 애플리케이션의 서버 쪽 부분에서 코드와 라이브러리를 다시 사용할 수 있습니다.

Blazor 는 순수하게 서버 렌더링된 웹 애플리케이션 또는 SPA를 빌드할지 여부를 평가할 때 고려할 새로운 세 번째 옵션을 제공합니다. Blazor를 사용하여 상당한 JavaScript 개발 없이도 SPA와 유사한 고급 클라이언트 측 동작을 구축할 수 있습니다. Blazor 애플리케이션은 API를 호출하여 데이터를 요청하거나 서버 쪽 작업을 수행할 수 있습니다. JavaScript 라이브러리 및 프레임워크를 활용하는 데 필요한 경우 JavaScript와 상호 운용할 수 있습니다.

다음과 같은 경우에는 Blazor을 사용하여 웹 애플리케이션을 빌드하는 것이 좋습니다.

• 애플리케이션이 풍부한 사용자 인터페이스를 노출해야 합니다.

• 팀이 JavaScript 또는 TypeScript 개발보다 .NET 개발에 더 익숙합니다.

.NET Core 또는 최신 .NET으로 마이그레이션하려는 기존 웹 양식 애플리케이션이 있는 경우 무료 전자책 Blazor 을 검토하여 Web Forms 개발자 가 마이그레이션을 고려하는 Blazor것이 적합한지 확인할 수 있습니다.

Blazor에 대한 자세한 내용은 Blazor 시작하기를 참조하세요.

기존 웹앱을 선택하는 경우

다음 섹션은 기존 웹 애플리케이션을 선택하는 이전에 설명한 이유에 대한 자세한 설명입니다.

애플리케이션에는 간단한 읽기 전용 클라이언트 쪽 요구 사항이 있습니다.

대부분의 웹 애플리케이션은 주로 대부분의 사용자가 읽기 전용 방식으로 사용합니다. 읽기 전용(또는 대부분 읽기) 애플리케이션은 많은 상태를 유지 관리하고 조작하는 애플리케이션보다 훨씬 간단한 경향이 있습니다. 예를 들어 검색 엔진은 텍스트 상자가 있는 단일 진입점과 검색 결과를 표시하기 위한 두 번째 페이지로 구성될 수 있습니다. 익명 사용자는 쉽게 요청을 수행할 수 있으며 클라이언트 쪽 논리가 거의 필요하지 않습니다. 마찬가지로 블로그 또는 콘텐츠 관리 시스템의 공용 애플리케이션은 일반적으로 클라이언트 쪽 동작이 거의 없는 콘텐츠로 구성됩니다. 이러한 애플리케이션은 웹 서버에서 논리를 수행하고 브라우저에 표시할 HTML을 렌더링하는 기존 서버 기반 웹 애플리케이션으로 쉽게 빌드됩니다. 사이트의 각 고유한 페이지에는 검색 엔진에서 책갈피를 지정하고 인덱싱할 수 있는 고유한 URL이 있다는 사실(기본적으로 이 기능을 애플리케이션의 별도 기능으로 추가할 필요 없음)도 이러한 시나리오에서 분명한 이점이 있습니다.

JavaScript 지원 없이 브라우저에서 애플리케이션이 작동해야 합니다.

JavaScript 지원이 제한되거나 없는 브라우저에서 작동해야 하는 웹 애플리케이션은 기존 웹앱 워크플로를 사용하여 작성해야 합니다(또는 적어도 이러한 동작으로 대체될 수 있음). SPA가 작동하려면 클라이언트 쪽 JavaScript가 필요합니다. 사용할 수 없는 경우 SPA는 좋은 선택이 아닙니다.

팀이 JavaScript 또는 TypeScript 개발 기술에 익숙하지 않습니다.

팀이 JavaScript 또는 TypeScript에 익숙하지 않지만 서버 쪽 웹 애플리케이션 개발에 익숙한 경우 SPA보다 더 빠르게 기존 웹앱을 제공할 수 있습니다. SPA를 프로그래밍하는 것이 목표이거나 SPA에서 제공하는 사용자 환경이 필요한 경우가 아니면 기존 웹앱은 이미 빌드에 익숙한 팀에게 보다 생산적인 선택입니다.

SPA를 선택하는 경우

다음 섹션은 웹앱에 대한 단일 페이지 애플리케이션 개발 스타일을 선택하는 경우에 대한 자세한 설명입니다.

애플리케이션은 다양한 기능을 갖춘 풍부한 사용자 인터페이스를 노출해야 합니다.

SPA는 사용자가 작업을 수행하거나 앱 영역 간을 탐색할 때 페이지를 다시 로드할 필요가 없는 풍부한 클라이언트 쪽 기능을 지원할 수 있습니다. SPA는 더 빠르게 로드할 수 있고, 백그라운드에서 데이터를 가져올 수 있으며, 전체 페이지 다시 로드는 드물기 때문에 개별 사용자 동작의 응답성이 더 높습니다. SPA는 증분 업데이트를 지원하여 사용자가 양식을 제출하는 단추를 클릭하지 않고도 부분적으로 완성된 양식이나 문서를 저장할 수 있습니다. SPA는 기존 애플리케이션보다 훨씬 쉽게 끌어서 놓기와 같은 풍부한 클라이언트 쪽 동작을 지원할 수 있습니다. SPA는 연결이 끊긴 모드에서 실행되도록 설계되어 연결이 다시 설정되면 서버로 다시 동기화되는 클라이언트 쪽 모델을 업데이트할 수 있습니다. 앱의 요구 사항에 일반적인 HTML 양식이 제공하는 것 이상의 다양한 기능이 포함된 경우 SPA 스타일 애플리케이션을 선택합니다.

자주 SPA는 현재 작업을 반영하는 의미 있는 URL을 주소 표시줄에 표시하고 사용자가 이 URL에 대한 책갈피 또는 딥 링크를 사용하여 반환할 수 있도록 하는 등 기존 웹앱에 기본 제공되는 기능을 구현해야 합니다. 또한 SPA는 사용자가 브라우저의 뒤로 및 앞으로 단추를 놀라게 하지 않는 결과와 함께 사용할 수 있도록 허용해야 합니다.

팀이 JavaScript 및/또는 TypeScript 개발에 익숙합니다.

SPA를 작성하려면 JavaScript 및/또는 TypeScript 및 클라이언트 쪽 프로그래밍 기술 및 라이브러리를 숙지해야 합니다. 팀은 Angular와 같은 SPA 프레임워크를 사용하여 최신 JavaScript를 작성하는 데 능숙해야 합니다.

참조 – SPA 프레임워크

• Angular: https://angular.io
• React: https://reactjs.org/
• Vue.js: https://vuejs.org/

애플리케이션은 이미 다른(내부 또는 공용) 클라이언트에 대한 API를 노출해야 합니다.

다른 클라이언트에서 사용하기 위해 웹 API를 이미 지원하는 경우 서버 쪽 형식으로 논리를 재현하는 대신 이러한 API를 활용하는 SPA 구현을 만드는 데 더 적은 노력이 필요할 수 있습니다. SPA는 웹 API를 광범위하게 사용하여 사용자가 애플리케이션과 상호 작용할 때 데이터를 쿼리하고 업데이트합니다.

선택 시기 Blazor

다음 섹션은 웹앱에 대해 선택할 Blazor 시기에 대한 자세한 설명입니다.

애플리케이션이 풍부한 사용자 인터페이스를 노출해야 합니다.

JavaScript 기반 SPA Blazor 와 마찬가지로 애플리케이션은 페이지 다시 로드 없이 풍부한 클라이언트 동작을 지원할 수 있습니다. 이러한 애플리케이션은 사용자에게 더 반응하여 지정된 사용자 상호 작용에 응답하는 데 필요한 데이터(또는 HTML)만 가져옵니다. 제대로 설계된 서버 쪽 Blazor 앱은 이 기능이 지원되면 최소한의 변경으로 클라이언트 쪽 Blazor 앱으로 실행되도록 구성할 수 있습니다.

팀이 JavaScript 또는 TypeScript 개발보다 .NET 개발에 더 익숙합니다.

많은 개발자가 JavaScript 또는 TypeScript와 같은 클라이언트 쪽 언어보다 .NET 및 Razor에서 생산성이 더 높습니다. 애플리케이션의 서버 쪽은 이미 .NET을 사용하여 Blazor 개발 중이므로 팀의 모든 .NET 개발자가 애플리케이션의 프런트 엔드 동작을 이해하고 빌드할 수 있습니다.

의사 결정 테이블

다음 의사 결정 표에서는 기존 웹 애플리케이션, SPA 또는 앱 중에서 선택할 때 고려해야 할 몇 가지 기본 요소를 요약합니다 Blazor .

기타 고려 사항

기존 Web Apps는 SPA 앱보다 더 간단하고 SEO(검색 엔진 최적화) 기준이 더 나은 경향이 있습니다. 검색 엔진 봇은 기존 앱의 콘텐츠를 쉽게 사용할 수 있지만 인덱싱 SPA에 대한 지원이 부족하거나 제한될 수 있습니다. 앱이 검색 엔진에 의한 공개 검색의 이점을 누릴 경우 이는 종종 중요한 고려 사항입니다.

또한 SPA 콘텐츠에 대한 관리 도구를 빌드하지 않은 경우 개발자가 변경해야 할 수 있습니다. 기존 Web Apps는 대부분의 콘텐츠가 단순히 HTML이며 빌드 프로세스를 미리 보거나 배포할 필요가 없으므로 개발자가 아닌 사용자가 쉽게 변경할 수 있습니다. 조직의 비 개발자가 앱의 콘텐츠를 유지 관리해야 하는 경우 기존 웹앱이 더 나은 선택일 수 있습니다.

앱에 복잡한 대화형 양식 또는 기타 사용자 상호 작용 기능이 있는 경우 SPA가 빛납니다. 인증을 사용해야 하므로 공용 검색 엔진 스파이더에서 액세스할 수 없는 복잡한 앱의 경우 대부분의 경우 SPA가 유용한 옵션입니다.