웹 개발 모델에 대한 탐구와 생각
- 伊谢尔伦원래의
- 2016-11-21 14:00:342037검색
최근에는 소프트웨어와 하드웨어 기술의 발전으로 웹 개발 관련 기술도 비약적으로 발전했습니다. 10년 전, 심지어 5년 전과 비교하면 비즈니스 복잡성과 기술 선택이 완전히 달라졌습니다. .
이 글은 주로 웹 개발 모델에 대한 저자의 개인적인 이해와 생각을 일부 설명한 에세이입니다.
서문
5~6년 전, 혹은 그 이전에는 웹 개발을 이야기할 때 주로 Java와 같은 백엔드 언어를 기반으로 하는 특정 기술을 언급했습니다. 웹, Ruby on Rails, Php 및 기타 기술 스택. 최근 몇 년 동안 웹 개발 관련 기술이 급속히 발전하면서 이제 웹 개발은 시나리오에 따라 다르게 나누어질 수 있다고 합니다.
일반적으로 최근 몇 년간 점차 세분화되어온 소위 웹 프론트엔드, 웹 풀스택 등 기술적 방향이 이러한 환경에서 탄생했습니다.
다시 본론으로 돌아가서 웹 개발에 대해 이야기해 볼까요? 웹 개발의 본질은 무엇인가요? 수준에서 웹 개발은 클라이언트를 다루는 것입니다. 요청과 서버 응답은 두 가지입니다.
2008년경 웹 애플리케이션이나 웹 개발의 표준 모델에서 백엔드가 하는 주요 일은 데이터베이스에서 데이터를 가져와 서버 측에서 HTML 템플릿을 생성하는 것이었습니다. 그런 다음 생성된 템플릿을 클라이언트에 보냅니다. 클라이언트는 템플릿을 받은 후 클라이언트에 js 및 css를 삽입하고 dom 트리를 생성한 다음 이를 페이지로 렌더링하여 사용자에게 표시합니다.
이 패턴은 일부 웹 애플리케이션 개발에 여전히 사용됩니다. 이 모델은 이제 전통적인 개발 모델 또는 프런트엔드 및 백엔드 하이브리드 개발 모델로 더 일반적으로 알려져 있습니다. 주요 기능 중 하나는 페이지 템플릿이 백엔드에 의해 생성되고, 생성된 템플릿에도 스타일과 상호 작용이 있다는 것입니다. 프런트 엔드는 페이지를 생성하기 위해 템플릿을 브라우저에 던져 DOM 트리로 렌더링합니다. 때로는 프런트 엔드에 일부 js 코드를 삽입하여 페이지의 동적 상호 작용을 지원하는 경우도 있습니다.
실제로 이 개발 모델을 직접 경험해봤습니다. 과거에는 JavaEE와 JavaWeb이 비교적 인기가 있었을 때 학생 관리 시스템, 도서관 관리 시스템 등과 같은 특정 시스템을 작성하고 Java를 사용하여 서버 측에서 JDBC 링크 데이터베이스를 운영하는 경우가 많았습니다. 그런 다음 해당 데이터를 jsp와 결합하여 클라이언트로 전송하고, 클라이언트는 렌더링을 위해 이를 브라우저에 전달합니다. 나중에는 php plus smarty의 개발 모델도 경험해봤습니다. 실제로 이 두 가지 방법은 서로 다른 기술 스택을 사용하지만 개발 모델의 본질은 동일합니다.
그러나 현재로서는 동일한 개발자가 여러 역할을 수행하고 서버측 코드, 템플릿 레이어 코드, 심지어 일부 js 및 css 코드도 작성해야 한다는 것을 알게 됩니다. 이를 위해서는 개발자가 서로 다른 역할 간에 전환해야 합니다. 하지만 서버 측에 집중하는 개발자들은 템플릿, 인터랙션, 스타일 작성을 싫어하거나 잘 못하는 경우가 많습니다. 이때 소위 페이지 개발 모델이 개발되었습니다. 소위 페이지 세트란 전업 프런트엔드 개발자가 먼저 정적 페이지를 잘라낸 다음 이를 백엔드 개발팀에 보내 템플릿을 모방한 다음 작성하고 동적 변경이 필요한 부분을 백엔드 템플릿 구문. 이 모델은 비효율적인 것으로 입증되었으며 적절한 애플리케이션 개발 리소스를 할당하지 않습니다.
개발 효율성 측면에서 대규모 팀 협업에서는 올바른 사람이 올바른 일을 하도록 하는 것, 노동 분업과 협업, 조립 라인 운영이 반드시 성공해야 한다는 생각을 고수해야 합니다. 최고의 솔루션.
전통적인 개발 모델에서는 해결해야 할 몇 가지 문제점이 있습니다. 이로 인해 프런트엔드와 백엔드 개발을 분리한다는 아이디어가 탄생했습니다. 다양한 유형의 작업은 각자의 업무만 담당하며, 효율적인 결과물을 얻기 위해 특정 협업 계약을 따릅니다.
위 내용은 기본적으로 프론트엔드와 백엔드 분리의 진화 역사입니다.
프런트엔드와 백엔드 분리 개발 모드에서는 서버측이 데이터베이스로부터 메타데이터를 가져와서 템플릿 대신 처리한 후 직접 데이터를 내놓는 방식입니다. 클라이언트 측에서 데이터를 얻은 후 클라이언트 측에서 템플릿 렌더링을 수행하여 페이지를 생성하고 사용자에게 제공합니다.
기존 개발 모델에 비해 서버는 더 이상 템플릿 레이어의 업무를 처리하지 않고 데이터만 직접 제공합니다. 책임은 더욱 특이합니다. 이때, 서버는 다양한 비즈니스 요구 사항이나 아키텍처 차이에 따라 직접 서비스를 제공할 수 있습니다. 여기서 서비스의 의미는 종종 마이크로서비스를 의미합니다. 일부 비절대 프런트엔드 및 백엔드 분리 모드에서도 서버는 템플릿 조각도 제공합니다.
분명히 이 모드에서는 프런트엔드 개발이 더 많은 작업을 수행해야 하며 비즈니스가 성장함에 따라 프런트엔드 로직과 코드의 양이 더 커지고 복잡해질 수 있습니다. 이는 크고 포괄적인 프레임워크인 Angular, 특정 수준의 비즈니스를 해결하는 데 중점을 둔 프레임워크인 React, 구축 부족을 보완하는 프레임워크인 Webpack 등 다양한 프런트엔드 프레임워크의 등장을 촉진했습니다. 기능 등등. 다양한 프레임워크 자체가 주변 커뮤니티의 발전을 주도하여 전체 프론트엔드 개발 서클이 폭발적인 기술 발전을 경험하게 할 것입니다.
전통적인 웹 개발 외에도 모바일 인터넷의 급속한 발전으로 인해 모바일 단말 개발, WeChat 개발, h5 개발 등의 분야에서도 프론트엔드 개발자들이 받아들이고 있습니다. 또한 NodeJS 플랫폼의 등장으로 인해 프런트엔드 개발은 더 이상 브라우저 측 개발 작업으로 제한되지 않을 수 있습니다. NodeJS 플랫폼과 Express 및 Koa와 같은 프레임워크의 도움으로 프런트엔드 개발자는 이미 이러한 능력을 갖추고 있습니다. 서버사이드 개발에 참여합니다.
프론트엔드 개발 기술 스택의 폭과 업데이트 속도를 엿보기에 충분한 기사입니다.
따라서 논의할 수 있는 내용이 정말 많습니다. 이번 글에서는 크게 다르지 않고 웹 개발과 관련된 내용만 다루겠습니다. 다음은 프론트엔드와 백엔드의 분리를 시작으로 PC측 웹 개발 모델에 대한 논의를 중심으로 제가 경험한 두 가지 개발 모델을 설명하여 다른 분들께 영감을 드리고자 합니다.
중간 계층 모드
앞서 언급했듯이 NodeJS 플랫폼의 활동으로 인해 특히 Express, Koa 등과 같은 일부 성숙한 서버 측 개발 프레임워크의 등장으로 인해 전면 -최종 개발자는 JavaScript를 사용할 수 있습니다. 서버 측 프로그램을 개발하고 데이터베이스를 운영하는 것도 가능합니다. 이는 또한 이전에 브라우저 측에서 개발해 온 프런트 엔드 개발자에게 새로운 작업 시나리오를 열어줍니다. 만약 그들이 데이터베이스, http 프로토콜, 네트워크 보안, 웹 서버 등에 대한 지식을 어느 정도 숙달했다면 개인적으로 프런트 엔드에 있다고 생각합니다. 역할을 백엔드 개발자로 전환하고 몇 가지 일반적인 시나리오에서 백엔드 개발을 처리하는 것은 문제가 되지 않습니다.
이는 분명히 기존 프런트엔드 개발자에게 더 높은 요구 사항을 제시했으며, 작업에 관련된 분야는 이전보다 더 낮은 수준이며 실제 백엔드 개발자와 더 자주 소통하게 될 것입니다. 일부 합의 및 규범 수립에 참여하는 경우에도 약간의 백엔드 사고가 필요합니다. 그렇지 않으면 다른 사람과 소통할 때 채널에 없다면 어떻게 할 수 있습니까?! >
이거 컨텐츠 일부 제목이 미들티어 모드인데 미들티어 모드란게 제 개인적인 이해로는 앞부분과 뒷부분 분리가 시작점인거 같은데, NodeJS 플랫폼에서는 웹 백엔드와 기존 프런트엔드(UI 레이어) 사이에 레이어가 추가됩니다. 중간 레이어는 데이터, 템플릿, 비즈니스 및 기타 콘텐츠 처리를 담당합니다. 백엔드와 UI 레이어 사이의 브리지입니다. 어떤 사람들은 이 중간층을 접착제 층이라고 부르기를 좋아합니다.
백엔드의 상위 레이어는 프론트엔드입니다. 여기서 소위 프런트엔드는 실제로 사용자 요청 및 상호 작용에 대한 응답과 같은 작업 모음을 나타내는 광범위한 참조입니다. 이 컬렉션에서 최상위 계층은 사용자, 클라이언트(브라우저) 계층, 클라이언트 아래의 NodeJS 계층입니다. nginx 레이어도 있습니다.
첫 번째 시나리오에서 사용자가 페이지 요청을 시작하면 브라우저는 먼저 요청을 수락한 다음 이를 프록시용 nginx에 전달합니다. nginx는 요청을 유형에 따라 해당 NodeJS 레이어 서비스로 전달합니다. 요청의. NodeJS 레이어는 nginx 레이어에서 전달된 요청을 내부적으로 구문 분석하고, 해당 비즈니스 클래스를 실행하고, 데이터를 조합한 후 최종적으로 클라이언트(브라우저)에 html 템플릿을 출력합니다. 브라우저는 템플릿을 가져온 후 클라이언트의 js와 그런 다음 이를 페이지로 렌더링하여 사용자에게 제공합니다.
두 번째 시나리오에서는 사용자가 요청을 시작하기 위해 버튼을 클릭하는 등 페이지에서 대화형 요청을 시작하면 해당 요청이 결국 NodeJS 레이어로 전달됩니다. NodeJS 레이어가 요청을 처리합니다. 받은 후 브라우저에 응답을 반환합니다.
기본적으로 클라이언트(UI 계층)의 대부분의 요청과 상호 작용은 NodeJS 계층에서 처리됩니다. UI 계층은 기본 REST 서비스 또는 마이크로서비스와 격리됩니다. 물론 사진 확인 코드 시나리오와 같이 브라우저가 기본 REST 서비스 또는 마이크로서비스를 직접 요청하는 특별한 경우도 있습니다.
Middle Tier 모드 솔루션 실습
여기서는 Middle Tier 모드 솔루션 Sword-plus를 제공하려고 합니다. 그 포지셔닝은 크고 포괄적인 원스톱 솔루션이 아니라 NodeJS 레이어의 보다 편리한 개발을 위한 도구 모음과 공통 기능의 개선입니다. Koa 프로그램을 기반으로 로깅, 템플릿 렌더링, 요청 액세스, 라우팅 분석, 비즈니스 클래스 추상화 등의 기능을 제공합니다. 그 안에는 다양한 기능적 구성 요소 간에 어느 정도 결합이 있습니다. 따라서 Sword-plus를 사용하는 전제는 NodeJS를 중간 계층으로 도입하는 것입니다. 기본 프레임워크는 Koa로 선택되며, NodeJS 계층은 상위 계층에 조립된 데이터에 대한 템플릿을 제공합니다.
Sword-plus에는 Router, Pugger, Connector, Logger, Handler 및 SwordError 구성 요소가 포함되어 있습니다.
라우터는 Koa의 패키지 요청을 파싱하는 데 사용됩니다. 크게 두 가지 방법이 있습니다.
파싱, 경로 파싱
공급자, 비즈니스 클래스 생성, 해당 경로의 비즈니스 로직 시작
Pugger는 주로 데이터를 조립하고 Jade/Pug 템플릿을 렌더링합니다.
여기서 템플릿은 서버측 템플릿이며, 렌더링 과정에서 매개변수를 통해 렌더링 로그를 기록할지 여부를 구성할 수 있습니다.
주요 메소드인 render는 데이터를 조합하여 서버 측 템플릿을 생성하는 데 사용됩니다.
렌더링 로그에는 렌더링 프로세스 중 모든 오류 메시지가 기록됩니다.
커넥터는 NodeJS 레이어->REST 레이어, UI 레이어->NodeJS 레이어의 요청 작업을 캡슐화합니다. Node-fetch는 내부적으로 사용됩니다. 또한 요청을 실행할 때 요청 로그를 기록할 수 있습니다.
Get, get 요청 실행
Post, post 요청 실행
Logger는 로그 구성 요소로, 모든 로그를 다음 범주로 나눕니다. 카테고리),
Fatal, error, warning, info
request, response, render, action
첫 번째 줄은 실제로 Bunyan의 자체 로그 수준 별칭이고, 두 번째 줄은 다양한 비즈니스 시나리오를 기반으로 추상화되었습니다.
요청, NodeJS 프로그램이 REST 서버로 보낸 나머지 API 요청 로그
응답, REST 서버가 NodeJS 프로그램으로 반환한 나머지 API 응답 로그
서버측 템플릿 렌더링 렌더링 로그는 실제로 클라이언트(브라우저)와는 아무런 관련이 없습니다.
작업, 페이지 요청, 양식 제출, 클라이언트 Ajax 요청 등을 포함하여 사용자가 시작한 모든 작업.
각 로그는 레코드 추상화입니다. 일반적으로 사용되는 레벨에는 경고, 오류 유형의 정보가 있습니다.
핸들러는 비즈니스 클래스 모델의 최상위 추상화입니다. 모든 요청이 라우터에 의해 구문 분석된 후 특정 비즈니스 클래스가 핸들러를 통해 파생됩니다. Handler에서는 내부 확장이나 외부 확장(Handler.inject)을 사용하여 모든 비즈니스 클래스에서 사용할 수 있는 기능적 메서드를 추가할 수 있습니다. 또한 핸들러는 특정 비즈니스 클래스에서 사용할 수 있도록 여러 제품군 인스턴스 개체를 프록시합니다. Handler는
이 상속하는 다음 메소드를 제공합니다. Router가 구문 분석된 후 이 메소드를 통해 Router.provider에 특정 비즈니스 클래스 Clazz가 생성됩니다.
디스패치, 비즈니스 클래스의 요청 가져오기 및 게시 유형에 대한 적응형 전달을 수행합니다.
주입, 서버 시작 시 필요에 따라 외부 확장을 주입할 수 있으며, 일단 주입되면 생성된 모든 비즈니스 클래스에서 사용할 수 있습니다.
SwordError는 SwordPlus의 Error 패키지입니다. 오류를 균일하게 배포하는 데 사용됩니다.
현재 SwordPlus Error의 종류는 다음과 같습니다.
LACK_OF_PARAMETER
INVALID_OF_PARAMETER
404
ERROR_OF_MAKEDIR
ibsix_not_support
ibsix_is_Required
타임 아웃
module_not_found no_template_file
즉, 이 모드의 프런트엔드 개발은 전통적인 의미의 백엔드 개발과 완전히 분리되어 중간 계층의 개발을 포함하지 않습니다.
프런트엔드와 백엔드는 Ajax 요청을 통해 상호작용하고, 백엔드는 프런트엔드로 데이터를 반환합니다. 페이지 렌더링, 상호 작용, 스타일, 라우팅 등을 포함한 클라이언트 측의 모든 사항은 프런트 엔드 자체에서 관리됩니다. 현재 프런트엔드 개발에서는 보다 성숙한 프런트엔드 오픈 소스 프레임워크를 기본 선택으로 도입하는 경우가 많습니다. 이 개발 모델에는 단일 페이지 애플리케이션, 기업 내 관리 시스템 등과 같은 고유한 적용 가능한 시나리오가 있습니다. 프런트엔드 개발자가 기본 프레임워크에 익숙하다면 개발 속도가 매우 빠른 경우가 많습니다. 기본적으로 실제 개발에서 직면하는 일부 문제는 프레임워크 커뮤니티에서 해결 방법을 찾을 수 있습니다.
이런 종류의 개발에도 단점이 있습니다. 종종 수요가 반복될수록 프런트엔드 코드의 양은 점점 더 많아지고 프런트엔드의 다양한 상호 작용과 모듈식 관리도 점점 더 많아질 것입니다. 더 무겁습니다. 유지 관리가 쉽지 않습니다. 또 다른 점은 선택할 수 있는 옵션이 너무 많아서 어떤 것을 선택해야 할지 모를 때가 있다는 것입니다.
시나리오와 요구 사항에 따라 구현 솔루션과 기술을 선택하고 맹목적으로 새로운 기술과 트렌드를 추구하지 않는 것이 개인적인 의견입니다. Angular, React, Vue 등과 같이 현재 프런트엔드에서 널리 사용되는 여러 주류 프레임워크에는 모두 장점과 단점이 있습니다. 예를 들어 Angular 자체는 포괄적인 프레임워크이므로 익숙해지면 개발 속도가 매우 빠릅니다. 그러나 진입 임계값이 낮고 심층적으로 이해하기가 복잡하며 몇 가지 시나리오가 있습니다. 그것은 적합하지 않습니다. React는 View 레이어의 처리에만 초점을 맞추고 View 및 Data 레이어와 상호 작용하고 업데이트하는 방법에 대해 매우 좋은 아이디어를 제공합니다. 그러나 Redux와 같은 기존 데이터 상태 관리 솔루션은 개인적으로 그다지 유용하지 않다고 생각합니다. . VueJS의 작성자는 시중에 나와 있는 많은 프레임워크의 장점을 흡수했습니다. 개인적으로는 항상 개발 중이라고 생각하므로 프로덕션 환경에서 사용해 본 적이 없으므로 자세한 설명은 생략하겠습니다.
요약
이 글의 주된 목적은 현재의 웹 개발 모델에 대한 개인적인 이해와 탐구를 좀 더 자세히 설명하는 것입니다. 개인적으로 이 글에서 말하는 Middle Tier 개발 모델은 다음과 같습니다. 기사에서 언급한 내용 외에도 추가 탐구를 위한 몇 가지 사항도 제시했습니다. 중간 계층 개발 모델은 기본적으로 어떤 요구에도 적응할 수 있다고 생각합니다.