웹 개발에서 프런트 엔드, 백엔드 및 미들웨어의 차이점
나는 누구든지 프론트 엔드, 백엔드, 미들웨어 ( "중단"?)의 차이점을 간결하게 비교 / 대조 할 수 있는지 궁금합니다.
중복되는 경우가 있습니까? 중복되어야하고 프런트 엔드 / 백엔드를 분리 할 수없는 경우가 있습니까? 병목 현상과 관련하여 어느 쪽이 어떤 유형의 병목 현상과 관련이 있습니까?
다음은 한 가지 분류입니다.
프런트 엔드 계층-> 사용자 인터페이스 계층은 일반적으로 HTML, Javascript, CSS, Flash 및 ASP.Net, 클래식 ASP, PHP 등과 같은 다양한 서버 측 코드의 조합으로 구성됩니다. 사용자에게 가장 가까운 것으로 생각하십시오. 코드 측면에서.
미들웨어, 중간 계층-> 일반적으로 시스템의 "배관"부분이라고하는 하나의 계층 백. Java 및 C #은 UI와 데이터 사이의 접착제로 볼 수있는이 부분을 작성하기위한 공통 언어이며, 웹 서비스 또는 WCF 구성 요소 또는 기타 SOA 구성 요소 일 수 있습니다.
백엔드 계층-> 데이터베이스 및 기타 데이터 저장소는 일반적으로이 수준에 있습니다. Oracle, MS-SQL, MySQL, SAP 및 다양한 기성 소프트웨어가 데이터의 최종 처리 인이 소프트웨어에 대해 떠 오릅니다.
자바 스크립트를 생성하는 내장 AJAX 기능을 사용하는 ASP.Net 웹 사이트와 같은 하나의 레이어에 모든 것을 부을 수 있기 때문에 이들 사이에 겹침이 존재할 수 있으며, 뒤에있는 코드에는 데이터베이스 명령이 포함되어있어 코드가 중간과 뒷면을 모두 포함 할 수 있습니다. -엔드 계층. 또는 VBScript를 사용하여 ADO 개체를 사용하는 모든 계층으로 작동하고 세 계층을 모두 하나로 병합 할 수 있습니다.
마찬가지로 미들웨어와 프런트 엔드 또는 백 엔드를 결합 할 수있는 경우도 있습니다.
병목 현상에는 일반적으로 몇 가지 수준이 있습니다.
1) 데이터베이스 또는 백엔드 처리-> 이것은 급여 나 판매 또는 데이터베이스 처리량이 문제가되는 기타 작업과 다를 수 있습니다.
2) 미들웨어 병목-> 일부 웹 서비스가 용량에 도달 할 수 있지만 프런트 엔드와 백 엔드에 더 많은 트래픽을 처리 할 수있는 대역폭이있는 경우입니다. 또는 UI 부분이 아닌 시스템의 일부인 서버 나 Biztalk 또는 MSMQ와 같은 것을 사용하여 병목 현상을 일으킬 수있는 원시 데이터가있을 수 있습니다.
3) 프런트 엔드 병목 현상-> 클라이언트 또는 서버 측 문제 일 수 있습니다. 예를 들어, 저가형 PC를 사용하고 다운로드되는 많은 데이터로 구성된 웹 페이지를로드하게했다면 클라이언트는 병목 현상이있는 곳일 수 있습니다. 마찬가지로 서버가 Amazon.com 또는 기타 트래픽이 많은 웹 사이트가 때때로 수신 할 수있는 것과 같은 요청으로 엉망이되는 경우 요청을 대기열에 넣을 수 있습니다.
이 중 일부는 해석의 대상이되므로 YMMV와는 전혀 완벽하지 않습니다.
편집 : 고려해야 할 점은 일부 시스템에 여러 프런트 엔드 또는 백 엔드가있을 수 있다는 것입니다. 예를 들어 콘텐츠 관리 시스템은 사이트 방문자가 프런트 엔드 콘텐츠를 볼 수있는 방법을 제공 할 수 있지만 콘텐츠 편집자가 사이트의 데이터를 어떻게 변경할 수 있습니까? 이 데이터를 가져 오는 기능은 UI 구성 요소이기 때문에 프런트 엔드로 보거나 사이트를 보는 일반 대중이 아닌 내부 사용자가 사용하기 때문에 백엔드로 볼 수 있습니다. 따라서 여기서 문맥에 대해 말할 것이 있습니다.
일반적으로 사람들은 애플리케이션의 프레젠테이션 레이어를 프런트 엔드 , 지속성 레이어 (일반적으로 데이터베이스)를 백 엔드 , 중간 계층이라고 합니다. 이 아이디어 세트를 종종 3 계층 아키텍처라고합니다. 이를 통해 응용 프로그램을보다 쉽게 이해하고 테스트 할 수있는 청크로 분리 할 수 있습니다. 또한 상위 계층에서 하위 계층 코드를 더 쉽게 재사용 할 수 있습니다.
어느 코드가 어느 계층의 일부인지는 다소 주관적입니다. 그래픽 디자이너는 프리젠 테이션이 아닌 모든 것을 백엔드로 생각하는 경향이 있고, 데이터베이스 사람들은 데이터베이스 앞에있는 모든 것을 프론트 엔드로 생각하는 식입니다.
그러나 모든 응용 프로그램을 이러한 방식으로 분리 할 필요는 없습니다. index.php를 열고 크래킹하는 것보다 3 개의 개별 하위 프로젝트를 갖는 것이 확실히 더 많은 작업입니다. (1) 앱을 유지해야하는 기간에 따라 (2) 앱이 얼마나 복잡해질 것으로 예상하는지에 따라 복잡성을 포기할 수 있습니다.
실제로 귀하의 질문에는 3 개의 질문이 있습니다.
- 프런트 엔드, 중간 및 백엔드 정의
- 언제 어떻게 중복됩니까?
- 관련된 일반적인 병목 현상.
JB King이 설명한 내용은 정확하지만 실제로는 front, middle 및 bacn을 MVC 레이어에 매핑 한 특별하고 간단한 버전입니다. 그는 M을 뒤쪽에, V를 앞쪽에, C를 중간에 매핑했습니다.
많은 사람들에게 MVC조차 적용되지 않은 추악한 세상에서 왔기 때문에 괜찮습니다. 뷰에서 직접 DB 호출을 할 수 있습니다.
그러나 실제 복잡한 웹 응용 프로그램에서는 실제로 전면, 중간 및 후면이라고하는 2 ~ 3 개의 서로 다른 레이어가 있습니다. 그들 각각은 연관된 데이터베이스와 컨트롤러를 가질 수 있습니다.
최종 사용자는 프런트 엔드를 볼 수 있습니다. 프론트 오피스의 매개 변수와 관리를위한 UI 인 프론트 오피스와 혼동해서는 안됩니다. 프런트 엔드는 일반적으로 일종의 CMS 또는 전자 상거래 플랫폼 (Magento 등)입니다.
중급은 필수가 아니며 비즈니스 로직이있는 곳입니다. PIM, MDM 도구 또는 제품이나 기사 (CMS 용)를 보강하는 일종의 사용자 지정 데이터베이스를 기반으로합니다. 또한 서로 다른 프런트 엔드 (예 : PC 프런트 엔드와 API 기반 모바일 애플리케이션 사이)간에 공유해야하는 비즈니스 기능을 코딩하는 곳이 될 것입니다. 때로는 ESB 또는 ActiveMQ와 같은 도구가 중간 엔드가 될 것입니다.
백엔드는 소스 데이터베이스 또는 ERP를 둘러싸는 세 번째 계층이됩니다. ERP에서 API를 작성하고 읽을 수 있습니다. 전자 상거래를하는 경우 공급자 DB 일 수 있습니다. 실제로 웹 프로젝트에 따라 다르지만 항상 중앙 저장소입니다. DB 호출, API, Hibernate 레이어 또는 모든 기능을 갖춘 백엔드 애플리케이션을 통해 액세스됩니다.
이 설명은 병목 현상이 3 개의 끝이 무엇을 포함하는지에 따라 실제로 달라지기 때문에이 스레드에서는 다른 두 가지 질문에 답할 수 없음을 의미합니다. JB King이 작성한 내용은 단순한 MVC 아키텍처에 적용됩니다.
질문이 제기되었을 때 (5 년 전) MVC 패턴이 아직 널리 채택되지 않았을 수 있습니다. 이제 MVC 패턴을 따르지 않고 뷰가 DB 호출에 연결될 이유가 전혀 없습니다. "겹쳐 야하고 프런트 엔드 / 백엔드를 분리 할 수없는 경우가 있습니까?"라는 질문을 읽은 경우 넓은 의미에서 3 개의 다른 구성 요소를 사용하면 3 계층 아키텍처가 당연히 쓸모없는 경우가 있습니다. 간단한 개인 블로그를 생각하면 외부 데이터를 가져 오거나 RabbitMQ 대기열을 폴링 할 필요가 없습니다.
다음은 프런트 / 미드 / 백 엔드를 보여주는 실제 사례입니다.
일반적인 설명:
- 프런트 엔드는 사용자에게 데이터를 제공하는 역할을합니다. 단일 백엔드와 관련된 두 개의 서로 다른 프런트 엔드가있을 수 있다는 흥미로운 점에 유의하십시오.
- 백엔드는 비즈니스 로직 / 데이터 지속성을 제공합니다.
- 미들웨어 (그림에서 activemq)는 시스템 대 시스템을 담당합니다. 백엔드 간의 통합. 일반적으로 별도의 애플리케이션으로 설치됩니다.
겹침 :
프론트 엔드와 백엔드가 겹칠 수 있습니다. 이는 일반적으로 응용 프로그램 유지 관리 및 확장 성과 관련된 장기적인 문제로 이어집니다. 레거시 응용 프로그램에서 상당히 일반적입니다.
대부분의 최신 기술 스택은 개발자에게 엄격한 분리를 권장합니다. 예를 들어 그림에서 첫 번째 시스템의 백엔드에는 명확한 구분선 인 나머지 웹 서비스가 있음을 알 수 있습니다.
병목 현상
Most bottlenecks in large are caused by database/network. Databases are located in backend. As for network issues every connection goes through netowrk, so every connection has potential for being slow. With good application design these issues are avoidable to large extend.
In terms of networking and security, the Backend is by far the most (should be) secure node.
The middle-end portion, usually being a web server, will be somewhat in the wild and cut off in many respects from a company's network. The middle-end node is usually placed in the DMZ and segmented from the network with firewall settings. Most of the server-side code parsing of web pages is handled on the middle-end web server.
백엔드에 도달한다는 것은 데이터베이스 (백엔드) 서버에 저장된 중요한 숫자에 대한 액세스를 허용 / 금지하는 신중하게 만들어진 규칙 세트가있는 중간 엔드를 통과하는 것을 의미합니다.
프론트 엔드는 클라이언트 측을, 백엔드는 애플리케이션의 서버 측을 나타냅니다. 둘 다 웹 개발에 중요하지만 역할, 책임 및 작업 환경은 완전히 다릅니다. 프런트 엔드는 기본적으로 사용자가 보는 반면 백엔드는 모든 것이 작동하는 방식입니다.
'programing' 카테고리의 다른 글
| System.Net.Http 대 Microsoft.Net.Http (0) | 2020.10.22 |
|---|---|
| Spring MVC에서 인터셉터와 필터의 차이점 (0) | 2020.10.22 |
| 루비 : Proc # call vs yield (0) | 2020.10.22 |
| Phonegap + jQuery Mobile, 실제 샘플 또는 튜토리얼 (0) | 2020.10.22 |
| package.json에 node_modules 경로 지정 (0) | 2020.10.22 |