NodeJS 기반의 프론트엔드와 백엔드 분리에 대한 생각과 실천 (1) 풀스택 development_node.js

머리말

전통적인 웹 개발 모델에서 발생하는 다양한 문제를 해결하기 위해 많은 시도를 해왔지만 프론트엔드와 백엔드 간의 물리적인 격차로 인해 시도한 솔루션은 모두 유사합니다. 고통스러운 경험을 통해 배운 후 오늘은 "프론트엔드와 백엔드"의 정의를 다시 생각하고, 프론트엔드 학생들에게 친숙한 NodeJS를 소개하며, 새로운 프론트엔드와 백엔드 분리 모델을 탐색해 봅니다. .

다양한 단말기(패드/모바일/PC)가 등장하면서 개발자에 대한 요구 사항이 점점 더 높아지고 있습니다. 순수한 브라우저 측 응답성은 더 이상 다양한 사용자 경험에 대한 높은 요구 사항을 충족할 수 없습니다. 터미널. 개발 효율성을 높이기 위해 프론트엔드와 백엔드의 분리 필요성이 점점 더 강조되고 있습니다. 백엔드는 비즈니스/데이터 인터페이스를 담당하고, 프론트엔드는 디스플레이/백엔드를 담당합니다. 상호 작용 논리. 동일한 데이터 인터페이스의 여러 버전을 사용자 정의하고 개발할 수 있습니다.

이 주제는 최근 많이 논의되었으며, 알리바바의 일부 BU에서도 시도를 하고 있습니다. 오랜 논의 끝에 우리 팀은 NodeJS를 기반으로 한 프런트엔드와 백엔드 분리 솔루션을 탐색하기로 결정했습니다. 그 과정에서 우리는 몇 가지 변화하는 이해와 생각을 보았는데, 이를 보시는 학우 여러분도 참고하시기 바랍니다. 토론에 참여하여 개선하는 데 도움을 드리겠습니다.

1. 프론트엔드와 백엔드 분리란?

그룹의 초기 토론에서 프런트엔드와 백엔드 분리에 대해 모든 사람이 서로 다른 이해를 갖고 있음을 발견했습니다. 동일한 채널에서 논의가 이루어지려면 먼저 도달해야 합니다. "프론트엔드와 백엔드의 분리"가 무엇인지에 대한 합의입니다.

모두가 동의하는 프런트엔드와 백엔드 분리의 예는 SPA(Single-page application)입니다. 사용되는 모든 디스플레이 데이터는 비동기 인터페이스(AJAX/JSONP)를 통해 백엔드에서 제공되며, 프런트 엔드에서는 이를 표시만 합니다.
어떤 의미에서 SPA는 프런트엔드와 백엔드의 분리를 달성하지만 이 접근 방식에는 두 가지 문제가 있습니다.

WEB 서비스 중 SPA는 작은 비중을 차지하고 있습니다. 많은 시나리오에는 동기/동기 및 비동기 혼합 모드가 있으며 SPA는 범용 솔루션으로 사용할 수 없습니다.
현재 SPA 개발 모델에서는 일반적으로 프레젠테이션 로직을 기반으로 인터페이스가 제공됩니다. 때로는 효율성을 높이기 위해 백엔드가 일부 프레젠테이션 로직을 처리하는 데 도움을 줍니다. 앞부분과 뒷부분이 분리되어 있지 않습니다.
SPA 방식의 프런트엔드와 백엔드 분리는 물리적 계층을 기반으로 합니다(클라이언트이면 프런트엔드, 서버측은 백엔드라고 생각함). . 이 분할 방법은 더 이상 프런트엔드와 백엔드 분리에 대한 요구를 충족할 수 없습니다. 우리는 책임 분할이 달성될 수 있다고 믿습니다. 현재 사용 시나리오를 충족하세요.

프런트 엔드: 뷰 및 컨트롤러 레이어를 담당합니다.
백엔드: 모델 레이어, 비즈니스 처리/데이터 등만 담당합니다.
이렇게 책임을 분담하는 이유에 대해서는 나중에 논의하겠습니다.

2. 앞부분과 뒷부분을 분리해야 하는 이유는 무엇인가요?

이 문제에 대해 Yu Bo의 기사 The Evolution of Web R&D Model이 매우 포괄적으로 설명되어 있습니다.

2.1 기존 개발 모델의 적용 시나리오

유삼촌이 언급한 여러 개발 모델에는 각각 적용 가능한 시나리오가 있으며 어느 누구도 다른 모델을 완전히 대체할 수 없습니다.

예를 들어 백엔드에 중점을 둔 MVC는 일부 동기식 디스플레이 비즈니스를 수행하는 데 매우 효율적이지만, 동기식과 비동기식을 결합한 페이지의 경우 백엔드 개발과 통신하기가 더 까다롭습니다.
Ajax는 주요 SPA 개발 모델로 APP 개발 시나리오에 더 적합하지만 SEO와 같은 문제를 해결하기 어렵기 때문에 이 개발 방법은 너무 무겁습니다.
2.2 프론트엔드와 백엔드의 불명확한 책임

복잡한 비즈니스 로직이 있는 시스템에서는 프런트엔드와 백엔드가 혼합된 코드를 유지 관리하는 것이 가장 두렵습니다. M-V-C의 각 계층에는 시간이 지남에 따라 다른 계층의 코드가 포함될 수 있기 때문입니다. 유지보수성이 전혀 없습니다.
프론트엔드와 백엔드를 분리한다고 해서 이 문제가 완전히 해결될 수는 없지만 크게 완화될 수는 있습니다. 물리적으로 그렇게 할 수 없다는 것이 보장되어 있기 때문입니다.

2.3 개발 효율성 문제

Taobao의 웹은 기본적으로 MVC 프레임워크 webx를 기반으로 하며, 아키텍처는 프런트엔드가 백엔드에만 의존할 수 있다고 결정합니다.
따라서 우리의 개발 모델은 여전히 ​​프런트엔드에서 정적 데모를 작성하고 이를 백엔드에서 VM 템플릿으로 변환하는 것입니다. 오랫동안 비판을 받아온 이 모델의 문제에 대해서는 다루지 않겠습니다.
백엔드 환경을 기반으로 직접 개발하는 것도 힘들고, 구성과 설치, 사용이 번거롭다. 이 문제를 해결하기 위해 VMarket과 같은 다양한 도구를 개발했지만 프런트엔드는 여전히 VM을 작성해야 하고 백엔드 데이터에 의존하기 때문에 여전히 효율성이 높지 않습니다.
또한 백엔드는 프레젠테이션에 대한 강한 집중을 버리지 못하고 비즈니스 로직 레이어 개발에 집중할 수 없습니다.

2.4 프론트엔드 성능의 한계

성능 최적화를 프런트 엔드에서만 수행하면 공간이 매우 제한되어 스파크를 달성하기 위해 백엔드 협력이 필요한 경우가 많습니다. 그러나 백엔드 프레임워크의 한계로 인해 어렵습니다. 성능을 최적화하기 위해 Comet 및 Bigpipe와 같은 기술 솔루션을 사용합니다.

위에서 언급한 몇 가지 문제를 해결하기 위해 많은 시도를 하고 다양한 도구를 개발했지만, 백엔드 플레이에서 할당된 작은 공간만 사용할 수 있기 때문에 크게 개선되지 않았습니다. 전면과 후면을 완전히 분리해야만 위의 문제를 완전히 해결할 수 있습니다.

3. 앞부분과 뒷부분을 어떻게 분리하나요?

앞부분과 뒷부분을 어떻게 분리하나요? 사실 답은 첫 번째 섹션에 이미 나와 있습니다.

프런트 엔드: 뷰 및 컨트롤러 레이어를 담당합니다.
백엔드: 모델 레이어, 비즈니스 처리/데이터 등을 담당합니다.

프런트 엔드가 컨트롤러를 마스터하면 URL 디자인을 할 수 있고, 장면에 따라 서버 측에서 동기적으로 렌더링할지, 뷰 레이어 데이터를 기반으로 json 데이터를 출력할지 결정할 수도 있습니다. , Comet 등은 프레젠테이션 계층의 요구에 따라 결정됩니다. 소켓 등은 전적으로 수요에 따라 사용 방법을 결정합니다.

3.1 NodeJS 기반의 "풀스택" 개발

위 그림의 레이어링을 구현하려면 프런트엔드와 백엔드에서 수행하는 작업을 수행하는 데 도움이 되는 웹 서비스가 반드시 필요하므로 "NodeJS 기반 풀스택 개발"이 언급되어 있습니다. 제목에

이 그림은 간단하고 이해하기 쉬워 보이지만, 시도해 보지 않으셨다면 궁금한 점이 많을 것입니다.

SPA 모드에서는 백엔드가 이미 필요한 데이터 인터페이스를 제공하고 뷰 프런트엔드를 이미 제어할 수 있습니다. NodeJS의 추가 레이어를 추가하는 이유는 무엇입니까?
레이어를 하나 더 추가하면 성능이 어떤가요?
레이어를 하나 더 추가하면 프런트엔드 작업 부하가 늘어나나요?
더 많은 레이어를 추가하면 더 많은 위험이 발생합니다.
NodeJS는 모든 것을 할 수 있는데 왜 JAVA가 필요한가요?
이러한 문제를 명확하게 설명하는 것은 쉽지 않습니다. 아래에서 제가 이해하는 과정을 이야기하겠습니다.

3.2 왜 NodeJS 레이어를 추가하나요?

이 단계에서는 주로 백엔드 MVC 모델로 개발합니다. 이 모델은 프론트엔드 개발의 효율성을 심각하게 저해하고 백엔드가 비즈니스 개발에 집중하는 것을 방해합니다.
해결책은 프런트엔드가 컨트롤러 레이어를 제어할 수 있도록 허용하는 것인데, 기존 기술 시스템으로는 그렇게 하기 어렵다. 모든 프런트엔드가 자바를 배우고, 백엔드 개발 환경을 설치하고, 설치하는 것이 불가능하기 때문이다. VM을 작성합니다.
NodeJS는 이 문제를 매우 잘 해결할 수 있습니다. 우리는 새로운 언어를 배울 필요가 없으며 이전 개발자가 우리를 위해 했던 일을 할 수 있으며 모든 것이 매우 자연스러워 보입니다.

3.3 성능 문제

레이어링에는 각 레이어 간의 통신이 수반되며, 확실히 성능 손실이 발생합니다. 그러나 합리적인 계층화를 통해 책임이 명확해지고 협업이 촉진되어 개발 효율성이 크게 향상됩니다. 계층화로 인한 손실은 반드시 다른 분야의 이익으로 보상될 것입니다.
또한 일단 계층화를 결정하면 통신 방식과 프로토콜을 최적화하여 손실을 최대한 최소화할 수 있습니다.

예:
타오바오 베이비 상세 페이지를 정적으로 만든 후에도 물류, 프로모션 등 실시간으로 얻어야 ​​하는 정보가 여전히 많습니다. 이 정보는 서로 다른 비즈니스 시스템에 있기 때문에 프런트 엔드에서 5개를 보내야 합니다. 또는 콘텐츠를 채우기 위한 6개의 비동기 요청.
NodeJS를 사용하면 프런트 엔드는 NodeJS에서 이러한 5개의 비동기 요청을 프록시할 수 있으며 Bigpipe를 쉽게 만들 수 있습니다. 이러한 최적화는 전반적인 렌더링 효율성을 크게 향상시킬 수 있습니다.
어쩌면 PC에서 5~6개의 비동기 요청을 보내는 것이 괜찮다고 생각할 수도 있지만 무선 측면에서는 클라이언트의 휴대폰에서 HTTP 요청을 설정하는 데 비용이 매우 많이 들기 때문에 성능이 여러 번 향상될 수 있습니다.

Taobao 세부정보: NodeJS를 기반으로 Taobao를 최적화하는 중입니다. 최적화 과정은 온라인화 후 공유하겠습니다.

3.4 프론트엔드 작업량이 늘어났나요?

단순한 페이지 자르기/데모와 비교하면 확실히 약간 추가되지만 현재 모델에서는 공동 디버깅 및 통신 링크가 있습니다. 이 프로세스는 시간이 많이 걸리고 버그가 발생하기 쉬우며 유지 관리가 어렵습니다.
따라서 작업량이 조금 늘어나더라도 전체적인 개발 효율성은 많이 향상될 것입니다.

게다가 테스트 비용도 많이 절약할 수 있습니다. 기존에 개발된 인터페이스는 모두 프리젠테이션 레이어용이어서 테스트 케이스 작성이 어려웠습니다. 프런트엔드와 백엔드가 분리되면 테스트도 분리될 수 있습니다. 한 그룹은 인터페이스 테스트에 집중하고 다른 그룹은 UI 테스트에 집중합니다(이 작업은 대체될 ​​수도 있습니다). 도구로).

3.5 노드 레이어 추가로 인한 위험을 어떻게 제어할 수 있나요?

Node의 대규모 사용으로 인해 시스템/운영 및 유지보수/보안 부서의 학생들이 인프라 구축에 반드시 참여하게 될 것이며, 각 링크에서 발생할 수 있는 문제를 개선하고 시스템의 안정성을 보장하는 데 도움이 될 것입니다.

3.6 Node로 모든 것을 할 수 있는데 왜 JAVA가 필요한가요?

이 문제를 고려하면 원래 의도에 어긋나는 것입니다. Node를 사용하여 Java를 대체하더라도 책임이 불분명한 등 오늘날 직면하는 다양한 문제가 발생하지 않는다고 보장할 수는 없습니다. 우리의 목표는 전문적인 사람들이 전문적인 일에 집중하면서 계층적으로 발전하는 것입니다. JAVA 기반 인프라는 이미 매우 강력하고 안정적이며 현재 아키텍처를 수행하는 데 더 적합합니다.

4. 타오바오의 Node 기반 프론트엔드와 백엔드 분리

위 사진은 타오바오의 Node 기반의 프론트엔드와 백엔드 분리 및 레이어링과 Node의 책임 범위에 대해 제가 이해한 것입니다. 간략한 설명:

최상위는 우리가 흔히 백엔드라고 부르는 서버입니다. 우리에게 백엔드는 인터페이스의 모음이고 서버는 우리가 사용할 수 있는 다양한 인터페이스를 제공합니다. Node 레이어가 있기 때문에 서비스 형태에 제한을 둘 필요가 없습니다. 백엔드 개발의 경우 비즈니스 코드에 관심이 있는 인터페이스 구현만 사용합니다.
서버 아래에는 노드 애플리케이션이 있습니다.
노드 애플리케이션에는 서버와 통신하기 위한 모델 프록시 계층이 있습니다. 이 레이어는 현재 주로 다양한 인터페이스를 호출하는 방식을 원활하게 하고 뷰 레이어에 필요한 일부 모델을 캡슐화하는 데 사용됩니다.
노드 계층은 또한 원래의 vmcommon, tms(Taobao 콘텐츠 관리 시스템 참조) 및 기타 요구 사항을 쉽게 실현할 수 있습니다.
노드 계층에 사용할 프레임워크를 결정하는 것은 개발자의 몫입니다. 그러나 xTemplate은 프런트엔드와 백엔드 간에 공유할 수 있으므로 Express xTemplate 조합을 사용하는 것이 좋습니다.
Node를 사용하는 방법은 누구나 결정하지만 흥미로운 점은 마침내 Node를 사용하여 우리가 원하는 출력 방법(JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/synchronous, asynchronous)을 원하는 방식으로 쉽게 얻을 수 있다는 것입니다. 조정 방법은 전적으로 장면에 따라 다릅니다.
브라우저 계층은 우리 아키텍처에서 변경되지 않았으며 Node의 도입으로 인해 브라우저 개발에 대한 이전 이해가 바뀌기를 바라지 않습니다.
Node의 도입으로 프런트엔드에서 제어해야 하는 부분을 프런트엔드에서 제어할 수 있게 되었습니다.
이 모델을 사용하여 이미 두 개의 프로젝트를 개발 중입니다. 아직 출시되지는 않았지만 개발 효율성과 성능 최적화 측면에서 이미 이점을 맛보았습니다.

5. 또 무엇을 해야 할까요?

Node의 개발 프로세스를 Taobao의 기존 SCM 프로세스에 통합합니다.
세션, 로거 및 기타 공통 모듈과 같은 인프라 구축.
최고의 개발 사례
온라인 성공사례
Node의 프론트엔드와 백엔드 분리 개념은 모두가 이해하고 있습니다
안전합니다
공연
…
기술적으로 혁신하고 연구해야 할 것은 많지 않고, 이미 기성품이 축적된 상태입니다. 실제로 핵심은 일부 프로세스를 정리하고 공통 솔루션을 축적하는 것입니다. 프로젝트를 더 많이 실행하면 점차 안정적인 프로세스가 될 것이라고 믿습니다.

6. '미드웨이'

'NodeJS 기반 풀스택 개발' 모델은 매우 흥미롭지만, Node 기반 풀스택 개발을 안정적이고 모두가 수용할 수 있는 것으로 전환하려면 아직 갈 길이 멀습니다. "Midway" 프로젝트는 이러한 문제를 해결하기 위해 고안되었습니다. 이제 시작했지만 목표에 점점 가까워지고 있습니다! !