기본 소개
중요한 개념 "템플릿"으로 시작하겠습니다. 광범위하게 말하면, 웹의 템플릿은 데이터를 작성한 후 파일을 생성 할 수있는 페이지입니다. 엄격히 말하면, 템플릿 엔진은 특정 형식의 파일을 사용하고 페이지를 컴파일하고 생성하기 위해 제공된 데이터를 사용해야합니다. 템플릿은 대략 브라우저 및 서버 측에서 컴파일 된 프론트 엔드 템플릿 (예 : EJS) 및 백엔드 템플릿 (예 : 프리 마커)으로 나뉩니다.
그 자리에있는 일부 학생들은 node.js에 대해 많이 알지 못했기 때문에 Node.js의 관련 지식 중 일부가 있습니다. 공식 웹 사이트에서 이벤트 중심, 비동기식 등의 정의에 대해서는 이야기하지 않습니다. 여기서 나는 pu lingshu에서 사진을 빌려 node.js의 구조를 설명합니다. Java를 이해한다면 JVM의 JS 버전으로 이해할 수 있습니다. 브라우저에는 일반적으로 렌더러 및 JS 스크립트 엔진이 포함됩니다. Chrome 브라우저를 예로 들어 WebKit 커널 렌더러 및 V8 스크립트 엔진을 사용하는 반면 Node.js는 V8 엔진을 사용합니다. 요컨대, 브라우저의 F12 디버깅 도구와 마찬가지로 JS 실행 환경이지만 Node.js에는 DOM과 BOM이 없습니다.
이 그림은 Node.js의 번영을 어느 정도 홍보하고 기술적 인 보증을 제공 한 NPM, NPM, 훌륭한 패키지 관리자 및 GitHub와 같은 Node.js 주변의 정보를 설명합니다.
대기업은 일반적으로 기술의 날씨 금지입니다. 예를 들어, Google의 Angular 및 Facebook의 반응은 현재 매우 인기가 있습니다. 여기에는 3 개의 대기업만이 예로 표시됩니다. 말할 것도없이, Taobao의 미드웨이 아키텍처는 국내 노드의 개척자 인 푸 링 (Pu Ling)은 타오 바오에서 유래 한 것입니다. Qunar는 또한 "QTX"라고 불리는 기술 프레임 워크를 개발했습니다. Yueying이 이끄는 75 팀은 ES6/ES7 -ThinkJS를 기반으로 웹 서버 프레임 워크를 시작했습니다. 당시 기술 책임자는 매우 낙관적 이었지만 ES6을 배울 시간이 없었고 플러그인은 충분히 풍부하지 않았기 때문에 여전히 더 성숙한 표현을 선택했습니다.
주제로 돌아가서,이 표에는 내가 노출 된 전면 및 뒷부분을 분리하기위한 세 가지 개발 방법이 나와 있습니다. 첫 번째는 SEO 친화적이며 캐시 사용 및 브라우저 렌더링 부담을 줄이는 데 더 나은 Java를 사용하는 가장 일반적인 백엔드 언어 템플릿입니다. 가장 큰 문제는 템플릿 파일의 커플 링 정도가 너무 높다는 것입니다. 아무도 문제를 해결하고 싶어하지 않습니다. 프론트 엔드 직원은 데이터를 볼 수없고 백엔드 직원은 페이지를 이해하지 못하고 템플릿 파일은 뜨거운 감자와 같습니다. 두 번째는 Project의 모바일 터미널의 현재 구현 솔루션으로, 각도의 프레임 워크 (각도 명령어는 프론트 엔드 템플릿으로 간주 될 수 있음)와 Nginx의 리버스 프록시 서버를 전면 엔드와 백엔드를 완전히 분리하고 AJAX를 통한 데이터와 만 상호 작용합니다. 이 솔루션은 전자의 장점과 단점과 정확히 반대입니다. 프론트 엔드 템플릿의 성능은 항상 모바일 장치, 특히 저가형 모바일 장치에서 문제가됩니다. 마지막은 Node.js를 프론트 엔드 서버로 사용하는 새로운 프로젝트로 프론트 엔드 책임을 브라우저에서 템플릿 레벨로 나누어 위의 모든 문제를 해결하지만 실제로 새로운 문제가 있으며이 문제는 나중에 분석됩니다.
물론, 풀 스택 개발은 소규모 프로젝트에도 매우 적합합니다. 기존의 JSP/PHP 개발의 경우 풀 스택 개발의 통신 비용이 낮으며 개발자는 전체 기능 모듈을 쉽게 이해하여 제품 설계를 더 잘 복원 할 수 있습니다. 특히 JS 언어를 기반으로 한 풀 스택 개발 : 현재 떠오르는 유성 및 평균 기술은 프론트 엔드 및 백엔드 개발이 한 언어로 직접 처리됩니다. MongoDB를 사용하면 브라우저에서 데이터베이스까지의 데이터가 탈출하지 않고 직접 사용되며 SQL을 작성할 필요가 없으므로 개발 비용이 크게 줄어 듭니다.
이번에는 일부 플러그인이 Node.js 서버를 빌드하는 데 사용되었습니다. 가벼운 웹 서버 프레임 워크 인 유명한 Express를 소개 할 필요가 없습니다. Express4는 기본적으로 핸들 바 템플릿 엔진을 사용하는 것도 우연의 일치입니다. 핸들 바는 "약한 논리"의 템플릿 엔진이 될 가치가 있습니다. 그것은 템플릿 로직을 줄이고 변수와 페이징 만 사용하려고합니다. 디자인 개념을 바탕으로 두 명의 도우미 만 확장했습니다. 특정 기사 : https://yalishizhude.github.io/2016/01/22/handlebars/superagent는 여전히 Express4 때문에 여전히 사용됩니다. 테스트 코드는 Supertest를 사용하기 때문에 Supertest는 초고속을 기반으로하므로 SuperAgent는 요청을 전달하고 시작하는 데 사용됩니다. 초고트는 여전히 너무 약하고 긴 연결을 위해 확립 할 수 없습니다. 여전히 요청 플러그인을 권장합니다. Restfuleapi에 소개 할 것이 없습니다. 프론트 엔드 서버 및 브라우저, 프론트 엔드 서버 및 백엔드 서버는 모두이 사양 세트를 사용합니다. 기본적으로 URL은 리소스를 가리키고, 추가, 삭제, 수정 및 확인하고, 특정 요청 메소드가 표현되고, 상태 코드가 결과 등을 나타냅니다. ~ Gulp Packaging Tool, Webpack은 오랫동안 공부 해 왔으며 모든 페이지가 추가 된 모든 페이지가 구성 파일을 수정해야한다는 것을 발견했습니다. 이것은 너무 고통 스럽기 때문에 포기했습니다.
개발 과정
이 공유가 주로 프론트 엔드 분리를 달성하기 위해 Node.js를 프론트 엔드 서버로 사용하는 방법에 대해 이야기한다면, 말할 것이 없습니다. Taobao Ued의 기사를보십시오. 전면 및 뒷부분 분리의 가장 큰 문제는 통신 비용, 특히 인터페이스의 정의 및 디버깅을 불러 일으킨다는 것입니다. 위의 그림의 기존 개발 프로세스에서 인터페이스의 정의는 인터페이스 서버에 배치 된 다음 전면 및 후방은 인터페이스 문서 사기 데이터를 기반으로 로컬 디버깅을 수행 한 다음 공동 디버깅을 수행합니다. 이 링크는 전면과 후면이 싸우기 시작할 때입니다. 이 매개 변수는 잘못되었고 반환 값이 잘못되었습니다. 요컨대, 그것은 시간 낭비입니다. 다음 으로이 프로젝트 에서이 문제가 어떻게 해결되는지 봅시다 ~
전면 및 후면에서 인터페이스 닳은 문제는 항상 존재했습니다. 보수적 인 것은 반복적 인 개발을 믿습니다. 따라서 첫 번째 단계는 모의 서버를 추가하는 것입니다. 이 서버의 마술은 인터페이스 문서를 기반으로 가짜 데이터를 자동으로 생성하고 인터페이스, 즉 API를 구현하고 프론트 엔드 학생들은 더 이상 테스트를 위해 데이터를 쓸 필요가 없다는 것입니다. 누가 내가 프론트 엔드 개발자라고 누가 말했습니까? 우선, 나는 내 사람들을 생각합니다. 물론, 이것은 어느 정도 프론트 엔드 개발에 유리합니다. 백엔드의 인터페이스와 문서가 일치하지 않고 연결된 경우에도 문제가 있습니다. 무엇을해야합니까?
나는 실수로 블레이드 마스터 블로그에서 라오 마의 기사를 보았습니다. 중요한 개념 중 하나는 계약 테스트이며 양자 테스트라고도합니다. 핵심 개념은 원격 조인트 디버깅 문제를 해결하는 것입니다. 전면 및 후면의 매개 변수를 확인하고 인터페이스 문서에 따라 모든 사람이 개발해야합니다. 이에 영감을 얻은 JSON-SCHEMA 규칙은 HTTP 요청의 매개 변수 검증을 실현하기 위해 추가되었으며 규칙을 따르지 않는 사람은이를 변경합니다.
이 redmine은 가장 초기의 인터페이스 문서 관리자이며 기능을 기록하고보기를 제외하고는 다른 기능이 없습니다.
Swagger는 세계에서 가장 인기있는 인터페이스 문서 서버로 알려져 있습니다. 아름다운 인터페이스와 많은 플러그인이 있습니다. 백엔드 언어에 대한 테스트 코드를 직접 생성 할 수 있습니다. 그러나 배포 할 때는 이해하지 못했고 Yaml 형식은 JSON만큼 좋지 않으므로 포기했습니다.
이것은 프로젝트에 사용 된 문서 서버 및 모의 서버, 평균 기술을 기반으로 구현 된 서버 및 기본 기능입니다.
Mockjs 플러그인을 사용하면 랜덤 데이터를 동적으로 생성하여 JSON-SCHEMA를 기반으로 한 인터페이스 매개 변수에서 체크섬 인터페이스 테스트를 수행 할 수 있으며 테스트 상태 및 인터페이스 응답 시간을 저장할 수 있습니다. 간단한 JSON 편집기에는 로그인 검증 기능이 있으며 로그인 후 인터페이스 디버깅을 수행 할 수 있습니다. 모의 서버는 API 서버에 따라 요청에 응답하며 인터페이스가 업데이트되면 자동으로 업데이트됩니다.
몇 가지 질문
Node.js는 프론트 엔드 엔지니어의 날개이며 날개가있는 천사 나 악마가되어야합니까? 이것은 사용으로 인한 문제를 해결할 수 있는지 여부에 따라 다릅니다.
우선, 프론트 엔드의 워크로드는 의심 할 여지없이 증가하지만 통신 비용은 줄어 듭니다. Node.js 단일 스레드의 서버 안정성은 실제로 충분하지 않지만 코드와 완벽한 로그의 견고성을 효과적으로 피할 수 있습니다. 콜백. Node.js 'Q/Async 모듈 및 ES6/ES7을 포함 하여이 문제에 대한 해결책이 너무 많습니다. node.js 디버깅. 나는 항상 IDE를 거부했지만 Webstorm이 실제로 디버깅에 매우 편리하다는 것을 인정해야합니다. 내가 사용하는 노드 인스 스펙터도 상당히 좋으며 인터페이스는 Chrome 개발자 도구와 유사하며 매우 친숙해 보입니다.
백엔드 프로그래머 인 경우 Node.js를 수용 할 가능성이 높아야합니다. 인터페이스 통합 작업은 처리를 위해 프론트 엔드 서버로 전달되며 프론트 엔드와의 커플 링 정도가 크게 줄어들고 워크로드 및 작업 효율이 줄어 듭니다.
경험해야 할 두 가지 점이 있습니다
Node.js의 사용은 특정 학습 비용이 있지만 프론트 엔드 개발자에게는 여전히 친숙합니다. 또한 Node.js가 프론트 엔드에서 사용되면 기술 컨텐츠와 워크로드가 모두 개선되어 작업의 중요성이 향상됩니다. 현재 개발자가 더 많은 가치를 창출 할 수있는 경우에만 더 높은 급여를 요구할 수 있습니다. 제안을 적게 제안하고 직장에서 더 많은 타당성 계획을 세우고 간단한 Helloworld를 작성하는 대신 기술 사전 연구를 수행하는 것이 좋습니다.
요약
어떤 사람들은 당신이 소개 한 것들의 세트가 너무 복잡하고 사용하기에는 너무 번거 롭기 때문에 얼굴을 마주 보는 것이 좋습니다. 그러한 의심을 위해, 나는 "웹 전체 스택 엔지니어의 자기 배양"에서 Tencent 수석 UI 엔지니어 Yu Guo가 언급 한 예제 만 사용할 수 있습니다. 한 번, 전화로 소규모 회사를 담당하는 프론트 엔드 사람이 그에게 코드를 관리하는 방법을 물었을 때, 상대방은 FTP를 사용하여 직접 업로드 할 것이라고 말했고, 부하 직원이 항상 잘못된 코드를 업데이트했다고 불평했습니다. 그는 또한 왜 SVN이나 GIT를 사용하지 않았는지 물었다. 그는 수동으로 업데이트하는 것이 더 쉬울 것이라고 말했다. 이 이야기의 진실은 질문에 대한 나의 대답입니다 ~
ppt 다운로드 주소