기존 웹앱 및 SPA(단일 페이지 앱) 중에서 선택
팁
이 콘텐츠는 eBook, Architect Modern Web Applications with ASP.NET Core 및 Azure에서 발췌한 것이며, .NET 문서에서 제공되거나 오프라인에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.
"Atwood의 법칙: JavaScript로 작성할 수 있는 모든 애플리케이션은 결국 JavaScript로 작성됩니다.”
- Jeff Atwood
오늘날 웹 애플리케이션을 빌드하는 방법은 일반적으로 두 가지가 있습니다. 서버에서 대부분의 애플리케이션 논리를 수행하는 기존 웹 애플리케이션과 웹 브라우저에서 대부분의 사용자 인터페이스 논리를 수행하며 기본적으로 웹 API를 사용하여 웹 서버와 통신하는 SPA(단일 페이지 애플리케이션)가 바로 그것입니다. 혼합 방식도 가능합니다. 가장 간단한 방법은 더 큰 기존 웹 애플리케이션 내에서 하나 이상의 풍부한 SPA와 같은 하위 애플리케이션을 호스트하는 것입니다.
다음과 같은 경우 기존 웹 애플리케이션을 사용합니다.
애플리케이션의 클라이언트 쪽 요구 사항이 단순하거나 읽기 전용인 경우
JavaScript를 지원하지 않는 브라우저에서 애플리케이션이 작동해야 하는 경우
애플리케이션은 공용이며 검색 엔진 검색 및 조회의 이점을 누릴 수 있습니다.
다음과 같은 경우 SPA를 사용합니다.
애플리케이션이 다양한 기능을 갖춘 풍부한 사용자 인터페이스를 노출해야 하는 경우
팀이 JavaScript, TypeScript 또는 BlazorWebAssembly 개발에 익숙한 경우
애플리케이션이 다른(내부 또는 공용) 클라이언트용 API를 이미 노출해야 하는 경우
또한 SPA 프레임워크에는 보다 큰 아키텍처 및 보안 전문 지식이 필요합니다. 기존 웹 애플리케이션보다 잦은 업데이트 및 새 클라이언트 프레임워크로 인한 큰 변동이 있을 수 있습니다. 자동화된 빌드 및 배포 프로세스를 구성하고 컨테이너와 같은 배포 옵션을 활용하는 방법은 기존 웹앱보다 SPA 애플리케이션이 더 어려울 수 있습니다.
SPA 접근 방식 덕분에 향상된 사용자 경험을 이러한 고려 사항과 비교해서 검토해야 합니다.
Blazor
ASP.NET Core에는 Blazor라는 풍부하고 구성 가능한 대화형 사용자 인터페이스를 빌드하기 위한 모델이 포함됩니다. Blazor 서버 쪽을 사용하면 개발자가 서버에서 C#과 Razor로 UI를 빌드하고 이를 영구적인 SignalR 연결을 통해 실시간으로 브라우저에 대화형으로 연결할 수 있습니다. BlazorWebAssembly는 WebAssembly를 사용하는 브라우저에서 실행할 수 있도록 Blazor 앱을 위한 다른 옵션도 도입했습니다. 실제 .NET 코드가 WebAssembly에서 실행 중이므로 애플리케이션의 서버 쪽 부분에서 코드와 라이브러리를 다시 사용할 수 있습니다.
Blazor는 순수하게 서버에서 렌더링하는 웹 애플리케이션 또는 SPA를 빌드할지 여부를 평가할 때 고려할 새로운 세 번째 옵션을 제공합니다. 많은 JavaScript 개발 작업을 할 필요 없이 Blazor를 사용하여 SPA와 유사한 풍부한 클라이언트 쪽 동작을 빌드할 수 있습니다. Blazor 애플리케이션은 API를 호출하여 데이터를 요청하거나 서버 쪽 작업을 수행할 수 있습니다. 필요한 경우 JavaScript 라이브러리 및 프레임워크를 이용하기 위해 JavaScript와 상호 운용될 수 있습니다.
다음과 같은 경우에는 Blazor를 사용하여 웹 애플리케이션을 빌드하는 것이 좋습니다.
애플리케이션이 풍부한 사용자 인터페이스를 노출해야 하는 경우
개발 팀이 JavaScript 또는 TypeScript 개발보다 .NET 개발이 더 편안한 경우
.NET Core 또는 최신 .NET으로 마이그레이션을 고려 중인 기존 Web Forms 애플리케이션이 있는 경우 무료 eBook인 Web Forms 개발자를 위한 Blazor를 검토하여 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 앱 중에 하나를 선택할 때 고려해야 할 기본 요소 몇 가지가 요약되어 있습니다.
| 요소 | 기존 웹앱 | 단일 페이지 애플리케이션 | Blazor 앱 |
|---|---|---|---|
| 팀의 JavaScript/TypeScript 숙련도 요구 사항 | 최소 | Required | 최소 |
| 스크립팅 없이 브라우저 지원 | 지원됨 | 지원되지 않음 | 지원됨 |
| 최소한의 클라이언트 쪽 애플리케이션 동작 | 적합 | 과도 | 가능 |
| 다양하고 복잡한 사용자 인터페이스 요구 사항 | 제한적 | 적합 | 적합 |
기타 고려 사항
기존 Web Apps는 SPA 앱보다 더 간단하고 SEO(검색 엔진 최적화) 기준이 더 나은 경향이 있습니다. 검색 엔진 봇은 기존 앱의 콘텐츠를 쉽게 사용할 수 있지만 인덱싱 SPA에 대한 지원이 부족하거나 제한될 수 있습니다. 앱이 검색 엔진에 의한 공개 검색의 이점을 누릴 경우 이는 종종 중요한 고려 사항입니다.
또한 SPA 콘텐츠에 대한 관리 도구를 빌드하지 않은 경우 개발자가 변경해야 할 수 있습니다. 기존 Web Apps는 대부분의 콘텐츠가 단순히 HTML이며 미리 보거나 배포하는 데 빌드 프로세스가 필요하지 않기 때문에 개발자가 아닌 사용자가 종종 더 쉽게 변경할 수 있습니다. 조직의 개발자가 아닌 사용자가 앱의 콘텐츠를 유지 관리해야 하는 경우 기존 웹앱이 더 나은 선택일 수 있습니다.
앱에 복잡한 대화형 양식 또는 기타 사용자 상호 작용 기능이 있는 경우 SPA가 빛을 발합니다. 인증을 사용해야 하므로 공용 검색 엔진 스파이더에서 액세스할 수 없는 복잡한 앱의 경우 대부분의 경우 SPA가 유용한 옵션입니다.
.NET