NodeJS를 기반으로 한 프론트엔드와 백엔드 분리에 대한 생각과 실천 (2) 템플릿 탐색

머리말

Front-end와 Back-end 분리를 할 때 가장 먼저 주목하는 이슈는 View 레벨의 작업인 렌더링입니다.

기존 개발 모델에서는 브라우저 측과 서버 측이 서로 다른 프런트엔드와 백엔드 팀에 의해 개발되지만 템플릿은 둘 사이의 모호한 영역에 있습니다. 따라서 템플릿에 점점 더 복잡한 로직이 추가되는 것은 불가피하며, 이는 결국 유지 관리가 어려워지게 됩니다.

그리고 프론트엔드와 백엔드 사이의 중간 레이어로 NodeJS를 선택했습니다. NodeJS를 사용하여 뷰 수준에서 작업을 간소화하려고 합니다.

프론트엔드와 백엔드 사이의 작업 구분을 더욱 명확하게 하여 프로젝트를 더 잘 유지 관리하고 더 나은 사용자 경험을 달성할 수 있습니다.

이 기사

렌더링은 프론트엔드 개발자의 일상 업무에서 매우 큰 비중을 차지하며, 백엔드 개발과 가장 얽힐 가능성이 높은 분야이기도 합니다.

지난 몇 년간 프런트엔드 기술의 발전을 되돌아보면 뷰 수준의 작업은 다음과 같은 많은 변화를 겪었습니다.

양식 제출 전체 페이지 새로고침 => AJAX 부분 새로고침
서버 측 렌더링 MVC => 클라이언트 측 렌더링 MVC
기존 페이지 변경 점프 => 단일 페이지 적용
지난 몇 년 동안 모든 사람들이 렌더링을 서버 측에서 브라우저 측으로 옮기는 경향이 있다는 것을 알 수 있습니다.

서버 측은 서비스화에 중점을 두고 데이터 인터페이스를 제공합니다.

브라우저 측 렌더링의 이점

우리 모두는

과 같은 브라우저 측 렌더링의 이점을 알고 있습니다.

1. Java 템플릿 엔진에서 비즈니스 로직과 프리젠테이션 로직의 결합과 혼란을 제거합니다.
2. 다중 터미널 애플리케이션의 경우 인터페이스가 더 쉽습니다. 브라우저 측에서 다양한 템플릿을 사용하여 다양한 애플리케이션을 제공합니다.
3. 페이지 렌더링은 단순한 HTML이 아닙니다. 프런트 엔드 렌더링은 구성 요소화된 형식(html js css)으로 기능을 더 쉽게 제공할 수 있으므로 프런트 엔드 구성 요소는 서버에서 생성된 HTML 구조에 의존할 필요가 없습니다.
4. 백엔드 개발 및 릴리스 프로세스에 대한 의존성을 제거합니다.
5. 공동 디버깅을 촉진합니다.

브라우저 측 렌더링으로 인한 단점

그러나 이점을 누리는 동시에 브라우저 측 렌더링으로 인해 다음과 같은 단점도 직면합니다.

1. 템플릿은 서로 다른 라이브러리로 분리되어 있습니다. 일부 템플릿은 서버 측(JAVA)에 배치되고 일부 템플릿은 브라우저 측(JS)에 배치됩니다. 프런트엔드와 백엔드 템플릿 언어는 연결되어 있지 않습니다.
2. 렌더링이 시작되기 전에 모든 템플릿과 구성 요소가 브라우저에 로드될 때까지 기다려야 하며 즉시 볼 수는 없습니다.
3. 처음 접속 시 렌더링 시간을 기다리는 흰색 화면이 나타나 사용자 경험에 도움이 되지 않습니다
4. 단일 페이지 애플리케이션을 개발할 때 프런트 엔드 Route와 서버 측 Route가 일치하지 않아 처리하기가 매우 어렵습니다.
5. 중요한 내용이 전면에 모아져 있어 SEO에 도움이 되지 않습니다

프론트엔드와 백엔드의 정의를 생각해 보세요

사실 생각해보면 렌더링 작업을 서버사이드(Java)에서 브라우저사이드(JS)로 옮겼을 때 우리의 목적은 단지 프론트엔드와 백엔드 책임을 명확하게 나누는 것이었고, 그렇게 됐습니다. 브라우저 렌더링이 필수라는 뜻은 아닙니다.

기존 개발 모델에서는 서버를 떠난 뒤 브라우저로 넘어가기 때문에 프런트 엔드 작업 내용은 브라우저 측으로만 제한될 수 있습니다.

이 때문에 많은 사람들은 아래 그림처럼 백엔드=서버측, 프런트엔드=브라우저측이라고 믿고 있습니다.

현재 Taobao UED에서 진행하고 있는 Midway 프로젝트에서는 JAVA와 Browser 사이에 NodeJS 중간 계층을 구축하여 하드웨어 환경이 아닌 업무 책임을 기준으로 프런트엔드와 백엔드 사이의 구분선을 재정의하려고 합니다. (서버 및 브라우저)를 구별합니다.

그래서 우리는 템플릿과 경로를 공유할 기회를 갖게 되었는데, 이는 프런트엔드와 백엔드 간의 업무 분담에 있어 가장 이상적인 상태이기도 합니다.

타오바오 미드웨이 미드웨이

Midway 프로젝트에서는 브라우저 측에서 앞부분과 뒷부분을 구분하는 선을 다시 서버 측으로 옮겼습니다.

프런트엔드에서 쉽게 제어할 수 있고 브라우저와 공통되는 Nodejs 레이어를 사용하면 프런트엔드와 백엔드 분리를 더욱 명확하게 완성할 수 있습니다.

프런트엔드 개발자가 다양한 상황에 가장 적합한 솔루션을 결정하도록 할 수도 있습니다. 모든 것이 브라우저 측에서 처리되는 대신.

책임분담

미드웨이는 백엔드 작업을 훔치려는 프론트엔드 프로젝트가 아닙니다. 단지 템플릿의 모호한 영역을 잘라내고 보다 명확한 책임 분할을 얻으려는 것이 목적입니다.

백엔드(JAVA)
를 중심으로 1. 서비스 레이어
2. 데이터 형식 및 데이터 안정성
3.비즈니스 로직

프론트엔드,
에 집중하세요 1.UI 레이어
2. 제어 로직과 렌더링 로직
3. 상호작용과 사용자 경험

더 이상 서버 측과 브라우저 측의 차이에 집착하지 마세요.

템플릿 공유

NodeJS를 사용하면 백엔드 학생들은 JAVA 계층에서 비즈니스 로직 및 데이터 개발에 집중할 수 있습니다. 프론트엔드 학생들은 제어 로직 및 렌더링 개발에 중점을 둡니다. 그리고 이러한 템플릿을 서버 측(NodeJS)에서 렌더링해야 하는지 아니면 브라우저 측에서 렌더링해야 하는지 선택할 수 있습니다.

동일한 템플릿 언어 XTemplate과 동일한 렌더링 엔진 JavaScript 사용

다른 렌더링 환경(서버사이드, PC 브라우저, 모바일 브라우저, 웹뷰 등)에서도 동일한 결과를 렌더링합니다.

경로 공유

NodeJS 레이어 덕분에 라우팅을 더욱 세밀하게 제어할 수 있습니다.

프런트 엔드에서 브라우저 측 라우팅을 수행해야 하는 경우 서버 측 라우팅을 동시에 구성하면 브라우저 측 페이지 변경이나 서버 측 페이지 변경 중에 일관된 렌더링 효과를 얻을 수 있습니다.

동시에 SEO 문제도 다루었습니다.

템플릿 공유 실천

일반적으로 브라우저 측에서 템플릿을 렌더링할 때 프로세스는

에 지나지 않습니다.

브라우저에 템플릿 엔진(xtmpleate, juicer, handlerbar 등) 로드
브라우저에 템플릿 파일을 로드합니다. 방법은
일 수 있습니다. 페이지에 인쇄하려면 모듈 로딩 도구를 사용하여 템플릿 파일(KISSY, requireJS 등)을 로드합니다
기타
데이터를 얻고 템플릿 엔진을 사용하여 HTML을 생성합니다
지정된 위치에 html을 삽입합니다.
위 프로세스에서 볼 수 있듯이 템플릿의 크로스엔드 공유를 달성하기 위해서는 실제로 일관된 모듈 선택에 초점이 맞춰져 있습니다.

시중에는 KMD, AMD, CommonJS 등 널리 사용되는 모듈 표준이 많이 있습니다. NodeJS 템플릿 파일을 일관된 모듈 사양을 통해 NodeJS 측으로 출력할 수 있다면 기본적인 템플릿 공유는 가능합니다.

다음 시리즈에서는 모델의 대리 및 공유에 대해 더 자세히 논의할 것입니다.

사례 연구

미드웨이 섬의 중층으로 인해 과거의 일부 문제에 대한 답변이 더 잘 나왔습니다.

사례 1 복잡한 대화형 애플리케이션(장바구니, 주문 페이지 등)

상태: 모든 HTML은 프런트 엔드에서 렌더링되며 서버는 인터페이스만 제공합니다.

문제: 페이지에 들어갈 때 잠깐 흰색 화면이 나타납니다.
답:
페이지에 처음 들어갈 때 NodeJS 측에서 전체 페이지 렌더링을 수행하고 백그라운드에서 관련 템플릿을 다운로드합니다.
후속 대화형 작업은 부분 새로 고침을 통해 브라우저 측에서 완료됩니다.
동일한 템플릿을 사용하면 동일한 결과가 생성됩니다

사례 2 단일 페이지 신청

상태: 클라이언트 측 MVC 프레임워크를 사용하여 브라우저에서 페이지를 변경합니다.

문제: 브라우저 측에서 렌더링 및 페이지 변경이 완료됩니다. URL을 직접 입력하거나 f5로 새로 고치면 동일한 내용이 직접 표시되지 않습니다.
답:
브라우저 측과 NodeJS 측에서 동일한 경로 설정을 공유합니다
브라우저 측에서 페이지를 변경할 때 브라우저 측에서 경로 변경 및 페이지 콘텐츠 렌더링을 수행합니다
동일한 URL을 직접 입력하면 NodeJS 측에서 페이지 프레임과 페이지 콘텐츠가 렌더링됩니다
브라우저 측에서 페이지를 변경하든, 동일한 URL을 직접 입력하든, 보이는 내용은 동일합니다.
경험을 늘리고 논리 복잡성을 줄이는 것 외에도. SEO 문제도 해결해줍니다

사례 3 순수 탐색 페이지

상태: 페이지는 정보만 제공하고 상호작용은 거의 또는 전혀 없습니다

문제: HTML은 서버 측에서 생성되고 CSS와 JS는 다른 위치에 배치되며 서로 종속됩니다.
답:
NodeJS를 통해 html css js 통합관리
향후 복잡한 애플리케이션이나 단일 페이지 애플리케이션으로 확장해야 하는 경우 쉽게 이전할 수 있습니다.

사례 4 교차단말 페이지

상황: 동일한 애플리케이션이 서로 다른 엔드포인트에서 서로 다른 인터페이스와 상호 작용을 제공해야 합니다

문제: HTML 관리가 쉽지 않습니다. 서버 측에서 다른 HTML이 생성되는 경우가 많으며 브라우저 측에서 다른 처리가 필요합니다.
답:
교차 터미널 페이지는 렌더링 문제이며 프런트 엔드에서 균일하게 처리됩니다.
NodeJS 레이어와 백엔드 서비스화를 통해 이러한 유형의 복잡한 애플리케이션에 가장 적합한 솔루션을 설계할 수 있습니다.

요약

과거 AJAX, 클라이언트 측 MVC, SPA, 양방향 데이터 바인딩 및 기타 기술의 등장은 모두 당시 프런트 엔드 개발에서 직면했던 병목 현상을 해결하려는 시도였습니다.

NodeJS 미들 레이어의 등장은 현재 프런트엔드가 브라우저 측에 국한되어 있는 한계를 해결하려는 시도이기도 합니다.

이 기사는 프런트엔드 및 백엔드 템플릿 공유에 중점을 두고 있으며, NodeJS 중간 계층 아키텍처에서 워크플로를 개선할 수 있는 방법과 백엔드와 협력하는 방법에 대해 논의하는 데 다른 사람들에게 영감을 줄 수 있기를 바랍니다. -end가 더 나은 작업을 수행합니다.