머리말
전면 및 후면을 분리 할 때, 내가주의를 기울이는 첫 번째 문제는 렌더링, 즉보기 수준에서 작동합니다.
기존 개발 모델에서 브라우저와 서버는 전면과 후면 모두 두 팀에 의해 개발되지만 템플릿은 둘 사이의 모호한 영역에 있습니다. 따라서 템플릿에는 항상 점점 더 복잡한 논리가 있으며 궁극적으로 유지하기가 어렵습니다.
그리고 우리는 nodejs를 전면 및 후면의 중간 층으로 선택했습니다. nodejs를 사용하여보기 수준에서 작업을 정리하십시오.
이로 인해 전면과 후면 사이의 노동 분열이 더 명확 해지고 프로젝트가 더 잘 유지되고 더 나은 사용자 경험을 달성합니다.
이 기사
렌더링 작업은 프론트 엔드 개발자의 일일 작업 중 매우 많은 비율이며 백엔드 개발과 혼동하는 가장 쉬운 부분입니다.
지난 몇 년간의 프론트 엔드 기술 개발을 되돌아 보면보기 수준의 작업은 다음과 같은 많은 변화를 겪었습니다.
양식 전체 페이지를 제출하십시오. 새로 고침 => Ajax 로컬 새로치
서버 측 계속 + MVC => 클라이언트 측 렌더링 + MVC
기존 페이지 변경 점프 => 단일 페이지 응용 프로그램
최근 몇 년 동안 모든 사람이 서버 끝에서 브라우저 끝으로 이동하는 경향이 있음을 알 수 있습니다.
서버 측은 서비스에 중점을두고 데이터 인터페이스를 제공합니다.
브라우저 렌더링의 이점
우리는 모두 브라우저 측 렌더링의 이점을 알고 있습니다
1. Java 템플릿 엔진의 비즈니스 로직과 프리젠 테이션 로직 사이의 커플 링과 혼란을 제거하십시오.
2. 다중 터미널 응용의 경우 인터페이스하기가 더 쉽습니다. 브라우저쪽에 다른 템플릿을 몇 가지 다른 응용 프로그램을 제시하십시오.
3. 페이지 렌더링은 HTML 일뿐 만 아니라 프론트 엔드의 렌더링은 구성 요소화 형식 (HTML + JS + CSS)의 기능을 쉽게 제공 할 수 있으므로 프론트 엔드 구성 요소는 서버에서 생성 한 HTML 구조에 의존 할 필요가 없습니다.
4. 백엔드 개발 및 유통 프로세스에 대한 의존성을 제거하십시오.
5. 편리한 관절 조정.
브라우저 렌더링으로 인한 단점
그러나 혜택을 즐기면서 우리는 또한 다음과 같은 브라우저 측 렌더링의 단점에 직면 해 있습니다.
1. 템플릿은 다른 라이브러리에서 분리됩니다. 일부 템플릿은 서버 측 (Java)에 배치되고 다른 템플릿은 브라우저 측 (JS)에 배치됩니다. 전면 및 백엔드 템플릿 언어는 연결되어 있지 않습니다.
2. 렌더링이 시작되기 전에 모든 템플릿과 구성 요소가 브라우저에로드 될 때까지 기다려야하며 즉시 읽을 수 없습니다.
3. 처음으로 렌더링을 기다리는 흰색 화면이있을 것입니다. 이는 사용자 경험에 도움이되지 않습니다.
4. 단일 페이지 애플리케이션을 개발할 때 프론트 엔드 경로는 서버 측 경로와 일치하지 않으므로 처리하기가 매우 귀찮습니다.
5. 모든 중요한 내용은 프론트 엔드에서 조립되며 SEO에는 도움이되지 않습니다.
전면 및 후면의 정의에 반영하십시오
실제로, 우리가 서버 측 (Java)에서 브라우저 쪽 (JS)으로 렌더링 작업을 가져 오면 우리의 목적은 전면 및 후면 책임을 명확하게 나누는 것이며 브라우저를 렌더링 할 필요는 없습니다.
기존 개발 모델에서 서버가 릴리스되고 브라우저에 도달하기 때문에 프론트 엔드의 작업 내용은 브라우저 측만 제한 될 수 있습니다.
따라서 많은 사람들이 아래 그림과 마찬가지로 백엔드 = 서버 프론트 엔드 = 브라우저 측을 결정했습니다.
Taobao Ued가 현재 진행중인 Midway Midway 프로젝트에서 Java 브라우저 중간에 Nodejs 중간 계층을 구축함으로써 하드웨어 환경 (Server & Browser)이 아닌 작업 책임에 대해 전면 및 후면 디비전 라인을 다시 차별화하려고합니다.
따라서, 우리는 템플릿과 경로를 공유 할 수있는 기회가 있으며, 이는 또한 프론트 엔드 및 백엔드 노동 부서에서 가장 이상적인 상태입니다.
타오 바오 중간에 타오바오
미드웨이 프로젝트에서는 브라우저에서 서버쪽으로 전면 및 후면을 구분하는 선을 옮겼습니다.
프론트 엔드에 의해 쉽게 제어되고 브라우저에 공통적 인 Nodejs 층을 사용하면 프론트 엔드 분리를보다 명확하게 완료 할 수 있습니다.
프론트 엔드 개발이 다양한 상황에 가장 적합한 솔루션을 결정할 수 있도록 할 수도 있습니다. 브라우저쪽에 모든 것이 처리되는 대신.
책임을 분할
Midway는 프론트 엔드가 백엔드 작업을 잡으려고하는 프로젝트가 아닙니다. 목적은 템플릿의 모호한 영역을 명확하게 자르고 명확한 책임의 분할을 얻는 것입니다.
백엔드 (Java), 초점
1. 서비스 계층
2. 데이터 형식 및 데이터 안정성
3. 비즈니스 논리
프론트 엔드, 초점
1.UI 층
2. 제어 로직, 논리 렌더링 로직
3. 상호 작용, 사용자 경험
더 이상 서버 또는 브라우저 측의 차이점을 고수하지 않습니다.
템플릿 공유
기존 개발 모델에서 브라우저와 서버는 전면과 후면 모두 두 팀에 의해 개발되지만 템플릿은 둘 사이의 모호한 영역에 있습니다. 따라서 템플릿에는 항상 점점 더 복잡한 논리가 있으며 궁극적으로 유지하기가 어렵습니다.
NodeJS를 통해 백엔드 학생들은 Java 계층의 비즈니스 로직 및 데이터 개발에 중점을 둘 수 있습니다. 프론트 엔드 학생들은 제어 논리 및 렌더링 개발에 중점을 둡니다. 또한이 템플릿을 직접 선택하여 서버 측 (NODEJS) 또는 브라우저 측에서 렌더링 할 수 있습니다.
동일한 템플릿 언어 사용 xtemplate 사용 및 동일한 렌더링 엔진 JavaScript 사용
다른 렌더링 환경 (서버 측, PC 브라우저, 모바일 브라우저, 웹보기 등)에서 동일한 결과를 렌더링합니다.
라우팅 공유
또한 Nodejs 레이어로 인해 라우팅을보다 신중하게 제어 할 수 있습니다.
프론트 엔드에서 브라우저 측 라우팅을 수행 해야하는 경우 서버 측 라우팅을 동시에 구성하여 동시에 브라우저 측의 페이지를 변경하거나 서버 측의 페이지를 변경할 수 있으며 일관된 렌더링 효과를 얻을 수 있습니다.
동시에 SEO 문제도 처리되었습니다.
템플릿 공유 관행
일반적으로 브라우저에서 템플릿을 렌더링 할 때 프로세스는
브라우저에 템플릿 엔진을 입력하십시오 (XTMPLEATE, Juicer, Handlerbar 등).
로드 템플릿 아카이브 브라우저 측면 에서이 방법은 다음과 같습니다.
<script type = "js/tpl"> ... </script>를 사용하여 페이지에 인쇄하십시오
모듈로드 도구를 사용하여 템플릿 아카이브 (키스, 요구 사항 등)를로드하십시오.
다른
데이터를 가져 와서 템플릿 엔진을 사용하여 HTML을 생성하십시오.
HTML을 지정된 위치에 삽입하십시오.
위의 프로세스는 템플릿의 크로스 엔드 공유를 달성하려면 실제로 일관된 모듈 선택에 중점을 둡니다.
KMD, AMD 및 CommonJS와 같은 시장에는 많은 인기있는 모듈 표준이 있습니다. Nodejs 템플릿 아카이브가 일관된 모듈 사양을 통해 NodeJS에 출력 될 수있는 한 기본 템플릿 공유를 수행 할 수 있습니다.
후속 기사 일련의 기사는 모델의 대리 및 공유에 대해 더 논의 할 것입니다.
사례 토론
Midway Island의 중간 층으로 인해 과거의 일부 질문에 대한 더 나은 답변이 있습니다.
사례 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 Middle Layer Architecture 아래 프론트 엔드에서 더 나은 작업을 수행하기 위해 워크 플로를 개선하고 백엔드와 협력하는 방법에 대해 논의 해 봅시다.