Web Notes
1.0.0
온라인 읽기 >>
코드 케이스 · 참조 자료
웹 개발은 시작하기 쉽지만 알기가 어렵습니다. 그것은 문을 한 눈에, 방에 들어가고, 전체 프로세스를 통합하는 것과 같은 단계로 나뉩니다. 저자의 일련의 기사를 처음 읽고 있다면 포괄적 인 이해를 위해 특정 곰의 기술적 경로로 이동하는 것이 좋습니다. 이 시리즈에서 저자는 제품 반복의 수명주기 동안 팀의 R & D 효율성을 효과적으로 향상시키고 적시에 안정적으로 전달하는 방법을 모색하기 위해 노력하고 있습니다. 동시에 시스템의 전반적인 복잡성을 제어하고 시스템의 성능과 경험을 지속적으로 최적화 할 수 있습니다.
지난 수십 년 동안 웹 기술과 생태학의 훌륭한 변화를 되돌아 보면서 우리는 흥미로운 변화를 경험했으며 종종 선택의 혼란에서 사라집니다. 브라우저 버전의 혁신과 하드웨어 성능 향상으로 웹 프론트 엔드 개발은 빠르고 끊임없이 변화하는 시대에 시작되었습니다. 수많은 프론트 엔드 개발 프레임 워크와 기술 시스템은 뷰티를 놓고 경쟁하고 있으며, 이로 인해 개발자는 혼란스럽고 손실을 입었습니다. 특히 현대적인 웹 프론트 엔드 프레임 워크 (Angular, React, Vue.js), JavaScript, CSS, HTML 등과 같은 언어 기능의 개선 및 엔지니어링, 크로스 플랫폼, 마이크로 프론트 엔드, 대형 프론트 엔드 및 BFF와 같은 제안 된 이론적 개념의 개선, Web Prant-Ender Community의 출현과 개선 및 개선되었습니다. 상태. 소위 최신 프론트 엔드 엔지니어의 경우 일반적으로 프로젝트 모듈화 방법, 구성 요소 간의 상호 작용을 설계하는 방법, 재사용 가능성을 향상시키는 방법, 포장 효율을 향상시키는 방법, 브라우저 렌더링 성능 등을 포함하여 엔지니어링 문제를 해결하기 위해 많은 전문 지식을 사용해야합니다. 더 이상 이전과 마찬가지로 정적 페이지를 개발하려면 HTML/CSS/JS 루틴 만 있으면됩니다.
전반적으로, 모든 프로그래밍 생태계는 우선 원래 기간 3 단계를 거치게됩니다. 언어 및 기본 API를 확장해야 하므로이 단계는 많은 보조 도구를 낳을 것입니다. 두 번째 단계에서는 더 복잡해지면서 더 많은 조직이 필요하며 많은 디자인 패턴과 건축 패턴이 도입 될 것입니다. 이 단계는 많은 프레임 워크를 낳을 것입니다. 세 번째 단계에서는 수요가 더 복잡해지고 팀의 확장으로 엔지니어링 단계와 다양한 계층 적 MVC, MVP, MVVM 등, 시각적 개발, 자동 테스트 및 팀 협업 시스템이 등장했습니다.
흥미롭게도, 우리가 다른 시점에 서있을 때,이 세 단계의 분열도 일관되지 않습니다. 저자의 현재 이해에 따르면, 템플릿 렌더링, 프론트 엔드 분리 및 단일 페이지 응용 프로그램, 엔지니어링 및 마이크로 프론트 엔드, 대형 프론트 엔드 및 서버리스의 세 가지 단계로 나뉩니다.
물론, 모든 작은 단계는 새로운 프레임 워크와 새로운 도구의 출현을 동반 할 것입니다.
웹 프론트 엔드 개발은 1991 년 Tim Berners-Lee의 HTML 설명에 대한 공개 언급으로 거슬러 올라가는 다음 W3C는 1999 년 HTML4 표준을 발표했습니다.이 단계는 주로 B/S 아키텍처였으며 소위 프론트 엔드 개발 개념이 없었습니다. 현재 템플릿 렌더링을 기반으로 한 정적 페이지였습니다. 가장 중요한 것은 JSP, PHP 및 기타 기술을 통해 동적 템플릿을 작성한 다음 웹 서버를 통해 템플릿을 HTML 파일로 구문 분석하는 것입니다. 브라우저는 이러한 HTML 파일을 렌더링 할 책임이 있습니다. 이 단계에서는 전면 끝 사이에 노동 분할이 없으며 일반적으로 백엔드 엔지니어는 프론트 엔드 페이지를 작성합니다.
향후 몇 년 동안 Ajax Technology 및 REST와 같은 건축 표준이 도입되면서 프론트 엔드 분리 및 풍부한 고객의 개념이 점점 인정되고 있습니다. 우리는 언어와 기본 API를 확장해야합니다. 이 단계에서는 jQuery가 대표하는 일련의 프론트 엔드 보조 도구가 등장했습니다. Ajax를 기반으로 전면 및 뒷부분도 분리 도로를 열었으며 전면 및 후면 분리 아키텍처가 점차 인기를 얻었습니다. 프론트 엔드는 인터페이스와 상호 작용을 담당하며 백엔드는 비즈니스 로직 처리를 담당합니다. 전면 및 후면은 인터페이스를 통해 상호 작용합니다. 우리는 더 이상 각 백엔드 언어로 관리하기 어려운 HTML을 작성할 필요가 없습니다. 웹 페이지의 복잡성은 백엔드 웹 서버에서 브라우저 측 JavaScript로 전환되었습니다.
2009 년부터 스마트 폰의 개발이 인기를 얻었으며 모바일 터미널의 물결은 막을 수 없었습니다. SPA 단일 페이지 응용 프로그램의 디자인 개념도 인기를 얻었습니다. 관련 프론트 엔드 모듈성, 구성 요소화, 반응 형 개발, 하이브리드 개발 및 기타 기술이 시급합니다. 특히 2009 년 Node.js의 출현과 함께 CommonJS 사양 및 NPM 패키지 관리 메커니즘은 Angular 1 및 Ionic과 같은 일련의 우수한 프레임 워크뿐만 아니라 AMD, CMD, UMD, 요구 사항 및 Grunt 및 Gulp와 같은 도구와 같은 모듈 표준을 낳았습니다. 프론트 엔드 엔지니어는 또한 백엔드와 독립적 인 기술 시스템과 아키텍처 모델을 갖춘 특별한 개발 분야가되었습니다.
과거에는 간단한 HTML과 JS 만 필요했습니다. 이제 패키지 관리자를 사용하여 타사 패키지를 자동으로 다운로드하고 모듈 관리자를 사용하여 단일 스크립트 파일을 만들고 번역 컴파일러를 사용하여 새 JavaScript 기능을 적용하고 작업 러너를 사용하여 각 구성 단계를 자동으로 실행해야했습니다.
지난 2 년 동안 웹 애플리케이션의 복잡성, 팀원의 확장 및 페이지 상호 작용 친화 성 및 성능 최적화에 대한 사용자의 요구가 증가함에 따라 우리는 더 나은 프론트 엔드 개발을 돕기 위해보다 우수하고 유연한 개발 프레임 워크가 필요합니다. 이 단계는 상대적으로 집중된 우려와 더 나은 디자인 개념을 가진 많은 프레임 워크가 등장했습니다. 예를 들어, React, Vue.js 및 Angular 2와 같은 구성 요소 프레임 워크를 사용하면 명령 프로그래밍을 DOM 작업으로 선언 적 프로그래밍으로 대체 할 수 있으므로 구성 요소 개발 속도를 높이고 구성 요소 재사용 가능성 및 부품 성을 향상시킬 수 있습니다. 기능 프로그래밍을 따르는 Redux와 응답 형 프로그래밍의 개념을 빌려주는 MOBX는 매우 우수한 상태 관리 보조 프레임 워크이며 개발자는 비즈니스 논리를보기 렌더링과 분리하고 프로젝트 구조를보다 합리적으로 나누고 단일 책임의 원칙을 더 잘 구현하고 코드 유지 보수 가능성을 향상시키는 데 도움이됩니다. 프로젝트 건설 도구에서 Grunt 및 Gulp로 대표되는 작업 운영 관리 및 Webpack, Rollup 및 JSPM으로 대표되는 프로젝트 포장 도구는 모두 길을 이끌고 있으며 개발자는 프론트 엔드 구성 프로세스를 더 잘 구축하고 전처리, 비동기로드, 다중 채취, 압축 및 기타 작업을 자동화 한 방식으로 수행 할 수 있도록 도와줍니다.
도구 체인의 성숙도는 또한 비즈니스 주요 기술 및 기술 주도 사업으로 엔지니어링 수요를 가져 왔습니다. 프론트 엔드 엔지니어링은 특정 비즈니스 특성에 따라 프론트 엔드 개발 프로세스, 기술, 도구, 경험 등을 표준화하고 표준화하는 것입니다. 프론트 엔드 개발이 자체 시스템을 구성하고 프론트 엔드 엔지니어의 개발 효율을 극대화하며 기술 선택, 프론트 엔드 및 백엔드 공동 공동 시운전 등으로 인한 조정 및 통신 비용을 줄이는 것이 목적입니다.
응용 프로그램 자체의 논리적 복잡성, 엔지니어링 하중 및 조합 복잡성 개선은 또한 프론트 엔드의 성능에 특정한 과제를 가져옵니다. 예를 들어, React와 같은 구성 요소 프레임 워크는 페이지 초기화시 흰색 화면 시간이 있으며 SEO에 친숙하지 않습니다. 프론트 엔드는 서버 렌더링을 통해이 문제를 해결하고 React, VUE 등이 구현 한 등방성 응용 프로그램을 기반으로 JSP 및 PHP와 같은 서버 언어 템플릿을 교체하거나 전체 HTML 문서의 형태로 브라우저로 반환하기 시작했습니다.
Node.js는 수년간의 개발 후에 전체 스택에 중점을두고 엔터프라이즈 수준의 응용 프로그램을 지원할 수있는 능력을 완전히 보유하고 있으며 Lowe, Netflix 및 Alibaba와 같은 많은 국내 및 외국 기업에서 많은 관행을 보유하고 있습니다. 또한 Node.js는 자연어 친화력을 가지고있어 개발자가 전체 스택의 책임을 더 쉽게 가정 할 수 있습니다. 마이크로 서비스 아키텍처 및 클라우드 네이티브 및 서버리스와 같은 개념이 증가함에 따라 백엔드 인터페이스는 점차 원자가되고 마이크로 서비스 인터페이스가 더 이상 페이지를 직접 직면하지 않으며 프론트 엔드 호출이 복잡해졌습니다. 따라서 GraphQL로 표시되는 BFF (Frontend for Frontend) 개념이 존재했습니다. BFF 층을 마이크로 서비스와 프론트 엔드 사이에 첨가하고, 인터페이스를 BFF로 집계하고 잘린 다음 프론트 엔드로 출력 하였다.
인터페이스 조정 및 집계 문제를 해결하는 동안 BFF는 백엔드에 대한 원래 동시 압력을 가지고 있으며, 이로 인해 프론트 엔드 엔지니어에게 많은 개발 및 운영 및 유지 보수 압력이 생깁니다. 서버리스는이 문제를 완화시킬 수 있습니다. 인터페이스의 집계 및 자르기를 구현하기 위해 기능을 사용 할 수 있습니다. BFF에 대한 프론트 엔드 요청은 FAAS HTTP 트리거의 트리거로 변환됩니다. 이 기능은 데이터를 얻기 위해 여러 마이크로 서비스를 호출 한 다음 프로세싱 결과를 프론트 엔드로 반환하는 등 요청에 대한 비즈니스 로직을 구현합니다. 이러한 방식으로 운영 및 유지 보수 압력은 이전 BFF 서버에서 FAAS 서비스로 이동했으며 프론트 엔드는 더 이상 서버를 신경 쓰지 않아도됩니다. 서버리스는 서버 측 렌더링에 적용하여 각 이전 경로를 기능으로 분할 한 다음 FAA에 해당 함수를 배포 할 수 있습니다. 이러한 방식으로, 사용자가 요청한 경로는 각 개별 기능에 해당합니다. 이러한 방식으로 운영 및 유지 보수 작업은 FAAS 플랫폼으로 전송됩니다. 프론트 엔드가 서버 측을 렌더링하면 서버 프로그램의 작동 및 유지 보수 배포에 신경을 줄 필요가 없습니다. 또한 WeChat 및 Alipay와 같은 미니 프로그램은 서버리스 개념을 준수하는 클라우드 개발 플랫폼을 제공하여 비즈니스 프론트 엔드의 빠른 반복을 강화합니다.
자세한 내용과 안내는 소개를 참조하십시오.
중국어 버전 | 영어 버전
경험이 풍부한 개발자이고 프론트 엔드 엔지니어링 및 아키텍처에 대해 알고 싶다면 기사 프론트 엔드 진화를 읽는 것이 좋습니다.
JavaScript Basic Syntax를 완전히 이해하지 못한 경우 기본 JavaScript 구문 및 실제 응용 프로그램을 이해하기 위해 "Modern JavaScript 구문 및 엔지니어링 실습"을 먼저 탐색하는 것이 좋습니다.
Node.js 전체 스택 개발을 이해하려면 Node-Notes를 참조 할 수 있습니다.
이론적 지식을 이해 한 후에는 WX-FE로 이동하여 모든 저자의 프론트 엔드 관련 오픈 소스 프로젝트를 확인하는 것이 좋습니다.
저자의 모든 기사는 Creative Commons Attribution-Non-Commercial Use-Hibited Explanation 4.0 International License의 적용을받습니다. 재판을 환영하며 저작권이 존중됩니다. 또한 NGTE Books 홈페이지로 이동하여 지식 시스템, 프로그래밍 언어, 소프트웨어 엔지니어링, 모델 및 아키텍처, 대규모 프론트 엔드, 서버 측 개발 실습 및 엔지니어링 아키텍처, 인공 지능 및 심층 학습, 제품 운영 및 기업가 정신 및 기타 등 여러 카테고리 목록을 찾을 수 있습니다.
