앞부분과 뒷부분을 따로 작성해야 하는 이유는 무엇인가요?

우리 모두 알고 있듯이 회사에서는 일반적으로 프런트엔드와 백엔드를 별도로 작성하도록 요구합니다. 이번에는 앞부분과 뒷부분을 따로 작성해야 하는 이유를 알려드리겠습니다. 다음은 실제 사례를 함께 살펴보겠습니다.

프런트엔드와 백엔드 분리의 워크플로를 시도하지 않았다면 먼저 다음과 같이 프로세스를 변경해 볼 수 있습니다.
프로세스를
PM: "이 기능을 원합니다"에서 변경
백엔드: "먼저 템플릿을 만들려면 프런트엔드를 찾으세요”
프런트엔드: “템플릿이 완성되었습니다”
백엔드: “연결해 보겠습니다. 여기 스타일이 잘못되었습니다”
프런트엔드: “수정을 마쳤습니다”
백엔드: “기능 전달”
PM: “이 활동은 봄 축제 기간 동안 추가될 예정입니다.”
백엔드: "먼저 템플릿을 변경할 프론트엔드를 찾자"
프론트엔드: "템플릿은 다음과 같습니다. 완료"
백엔드: "연결해 보겠습니다. 여기 스타일이 잘못되었습니다."
프론트엔드: "변경을 완료했습니다."
백엔드: "기능 전달"

becomes

PM: "원합니다. 이 기능"
Front-end: "인터페이스를 원합니다"
Back-end: "인터페이스가 완성되었습니다"
Front-end: "연결해서 기능을 전달하겠습니다"
PM: "중에 추가하고 싶어요" 봄 축제 이번 활동"
Front-end: "인터페이스를 추가해야 합니다"
Back-end: "인터페이스가 완성되었습니다"
Front-end: "연결해서 기능을 전달하겠습니다"

될 수 있습니다 프런트엔드와 백엔드 분리의 주요 개념은 다음과 같습니다. 백그라운드는 API 인터페이스만 제공하면 되고 프런트엔드는 AJAX를 호출하여 데이터 표현을 실현합니다.

현재 상황과 차이점

프론트엔드 개발자로서 우리는 새로운 기술을 시도하고 모든 세부적인 문제를 개선하며 끊임없이 스스로 돌파해야 합니다. 프런트엔드와 백엔드의 분리는 새로운 기술이나 아이디어는 아니지만 많은 백엔드 개발자는 물론 심지어 프런트엔드 개발자도 이에 대해 접해 본 적이 없습니다.

제가 개인적으로 이해한 바에 따르면, 부서 내 부서 직원이 모두 백엔드 개발자이고 일부 프런트엔드 페이지도 백엔드 직원이 완성한다면 프런트엔드와 백엔드가 분리될 수 있습니다. 그들에게는 알려지지 않은 분야이며 대부분의 프로젝트는 프론트엔드와 백엔드가 강하게 결합되어 있으며 프론트엔드라는 개념조차 존재하지 않습니다.

프론트엔드에 관심을 두지 않는 기업이나 부서에서는 프론트엔드와 백엔드의 분리를 이해하지 못하는 것은 당연합니다. 대부분의 창업 기업은 한 부서에 1~2개의 프론트엔드 부서를 두고 있으며, 한 사람이 여러 프로젝트를 담당하며 프로젝트를 완료하기 위해 협력하는 경우는 드뭅니다. 표준이 전혀 없기 때문에(여기서의 표준은 코드 구성 구조를 의미함) 프론트엔드 직원이 그림을 잘라내고 페이지를 작성하여 백엔드에 던지고, 백엔드 코드 구조는 다음과 같이 사용됩니다. 표준. 일부 기업에서는 프런트엔드와 백엔드 분리에 대해 인식하고 있지만 이를 실천하는 방법을 모릅니다. 당시 학과의 백엔드 직원들은 프론트엔드와 백엔드가 분리되면 백엔드에서는 더 이상 HTML과 JS를 작성할 필요가 없어 프론트엔드에 맡길 수 있다고 생각했습니다. 이것은 프론트엔드와 백엔드 분업이라고밖에 할 수 없습니다.

위의 상황은 다음과 같습니다. 저는 프론트엔드와 백엔드의 분리를 이해하지 못하고 어떻게 실천해야 할지 모르겠습니다. 아래에는 또 다른 상황이 있습니다. 프런트엔드와 백엔드의 분리를 이해하지만 시도하고 싶지 않은 경우입니다.

두 번째 상황에 대해서는 많은 분들이 그에 맞게 설명을 해주셨는데요. 사실 이는 '앞끝과 뒤끝 분리의 장단점' 문제와 관련이 있습니다. 많은 백엔드 직원들은 자신이 한 일에 문제가 없다고 생각할 것입니다. 백엔드에서 프런트엔드 html을 적용한다고 해도 그것은 일반적이고 항상 일반적인 추세였습니다. 백엔드 MVC 프레임워크도 이런 방식으로 권장됩니다. 매우 합리적입니다. 이때 프론트엔드 개발자들은 부서 내에서 충분한 발언권을 갖지 못하거나, 백엔드 개발자의 의견이 항상 옳고 주관성이 없다고 생각하는 경우가 많습니다.

반대로, 백엔드 개발자들은 프런트엔드와 백엔드 분리를 강력히 권장하지만, 프런트엔드 개발자들은 이를 실천하고 싶어하지 않을 수도 있습니다. 이때 프론트엔드는 백엔드 개발자들이 엉터리를 하고 있다고 생각할 것이다. 과거에는 프론트엔드와 백엔드가 분리되지 않은 프로젝트는 순조롭게 진행됐을 것이다. -끝이 분리되면 기술 역량에 따라 추가 작업량과 학습 비용이 발생하게 됩니다.

물론, 프론트엔드와 백엔드 분리에 있어 현재 상황과 차이점이 있다고 개인적으로 생각하는 부분이기도 합니다.

시나리오 및 요구 사항

프런트엔드와 백엔드가 분리된 애플리케이션 시나리오에 모든 시나리오가 적합한 것은 아니지만, 대부분의 프로젝트는 프런트엔드와 백엔드 분리를 통해 실현될 수 있습니다.

저는 주로 엔터프라이즈급 백엔드 애플리케이션의 프런트엔드 개발에 종사하고 있기 때문에 개인적으로 백엔드 애플리케이션 개발에 있어서는 프런트엔드와 백엔드 분리의 장점이 단점보다 훨씬 크다고 믿습니다.

대부분의 백그라운드 애플리케이션을 SPA 애플리케이션(단일 페이지 애플리케이션)으로 만들 수 있으며 단일 페이지 애플리케이션의 주요 기능은 프런트 엔드 제어 라우팅을 통해 AJAX를 호출하고 인터페이스를 제공함으로써 달성할 수 있습니다. 이러한 방식으로 사용자 경험이 더 친숙해지고, 웹 페이지 로드 속도가 빨라지며, 개발 및 유지 관리 비용이 많이 줄어들고 효율성이 크게 향상됩니다.

마찬가지로 디스플레이 웹사이트와 모바일 APP 페이지에서도 프런트엔드와 백엔드 분리를 시도하고 있습니다. 프런트엔드와 백엔드가 분리되지 않은 경우 서버는 웹측을 별도로 처리하고 완전한 HTML을 반환해야 합니다. 이는 필연적으로 서버의 복잡성을 증가시키고 웹측에서는 전체 HTML을 로드해야 하므로 성능에 영향을 미칩니다. 이는 모바일 성능이 가장 중요한 곳에서는 매우 비우호적입니다.

프론트엔드 기술의 발전과 반복으로 프론트엔드 MVC 프레임워크가 탄생했습니다. React, Vue, Angular 등 현재 주류인 프론트엔드 프레임워크를 사용하여 쉽게 웹사이트를 구축할 수 있습니다. 동시에 이 클래스 프레임워크는 모두 프런트엔드 라우팅 기능을 제공합니다. 백엔드는 더 이상 라우팅 점프를 제어할 수 없으며 원래 프런트엔드에 속한 모든 비즈니스 로직을 전면에 던질 수 없습니다. -end. 이는 프론트엔드와 백엔드의 가장 완벽한 분리라고 할 수 있습니다. 다음은 프런트엔드 제어 라우팅을 위한 코드입니다.

'use strict'export default function (router) {
    router.map({        '/': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            }
        },        '/m/:params': {            component: function (resolve) {                require(['./Mobile.vue'], resolve)
            }
        },        '/p': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            },            subRoutes: {                '/process/:username': {                    component: function (resolve) {                        require(['./components/Process.vue'], resolve)
                    }
                }
            }
        }
    })
}

프론트엔드와 백엔드 분리를 구현하면 기술 인력, 특히 프런트엔드 인력에 대한 요구 사항이 높아집니다. 페이지 자르기, 템플릿 작성 또는 간단한 js 로직 처리에 대해 설명합니다. 프런트엔드 서버에서 반환된 다양한 데이터 형식을 처리해야 하며 일련의 데이터 처리 로직, MVC 아이디어 및 다양한 주류 프레임워크도 마스터해야 합니다.

장점과 의의

프론트엔드와 백엔드 분리의 의미도 프론트엔드 렌더링의 의미로 생각해볼 수 있습니다. 저는 주로 다음 네 가지로 요약했습니다.

프론트엔드를 완전히 해방합니다
프런트엔드는 더 이상 백엔드나 백엔드에 템플릿을 제공할 필요가 없습니다. 백엔드 코드는 다음과 같이 프런트엔드 HTML에 포함되어 있습니다.

<!--服务器端渲染 --><select>
    <option value=&#39;&#39;>--请选择所属业务--</option>
    {% for p in p_list %}    <option value="{{ p }}">{{ p }}</option>
    {% endfor %}</select>

이는 프런트엔드와 백엔드 사이에 연결되어 있어 가독성이 떨어집니다.

<!--前端渲染 --><template>
    <select id="rander">
        <option value=&#39;&#39;>--请选择所属业务--</option>
        <option v-for="list in lists" :value="list" v-text="list"></option>
    </select></template><script>export default {    data: {        return {            lists: [&#39;选项一&#39;, &#39;选项二&#39;, &#39;选项三&#39;, &#39;选项四&#39;]
        }
    }，
    ready: function () {        this.$http({            url: &#39;/demo/&#39;,            method: &#39;POST&#39;,
        })
        .then(function (response) {            this.lists = response.data.lists // 获取服务器端数据并渲染
        })
    }
}
</script>

위는 프런트엔드가 AJAX를 통해 백엔드 인터페이스를 호출하는 코드입니다. 데이터 로직은 프런트엔드에서 유지됩니다.

업무 효율성 향상 및 업무 분담 명확화
프론트엔드와 백엔드를 분리하는 워크플로를 통해 프론트엔드는 프론트엔드 업무에만 집중하고, 백엔드는 백엔드 활동에만 집중할 수 있습니다. 두 가지 개발은 동시에 수행할 수 있습니다. 백엔드에서 인터페이스를 제공할 시간이 없으면 프런트엔드에서 먼저 데이터를 쓰거나 로컬 json 파일을 호출할 필요가 없습니다. 페이지를 추가하고 경로를 수정할 때 백엔드를 방해하여 개발을 더욱 유연하게 만듭니다.

부분적인 성능 개선
프런트엔드 라우팅 구성을 통해 홈페이지가 로드되자마자 웹사이트의 모든 리소스를 더 이상 로드할 필요가 없습니다. 페이지 상호 작용 및 사용자 경험을 향상시키는 프런트 엔드 페이지를 구문 분석합니다.

유지 관리 비용 절감
현재 주류인 프런트엔드 MVC 프레임워크를 통해 문제를 매우 빠르게 찾고 발견할 수 있습니다. 클라이언트 측 문제에는 더 이상 백엔드 인력 참여와 디버깅, 코드 리팩토링 및 유지 관리성 향상이 필요하지 않습니다.

생각과 통찰:

처음에는 백그라운드 제어 라우팅 및 백그라운드 렌더링 페이지부터 지금은 프런트 엔드 제어 라우팅 및 프런트 엔드 렌더링 데이터에 이르기까지 하나의 프로젝트에서 작업 흐름과 방법이 진행되었습니다. 큰 변화. 저는 다음과 같은 상황에 직면할 때마다 프론트엔드와 백엔드 분리로 인한 장점에 감동적으로 한숨을 쉬게 됩니다.

1. 프로젝트 초반에 프론트엔드 페이지를 만들 때 더 이상 필요하지 않습니다. 서버 환경을 구성하기 위한 백엔드 2. 백엔드 인터페이스를 호출해야 할 때 미리 서버에 넣을 필요가 없습니다. 프로젝트 페이지를 추가하고 라우팅을 구성해야 하면 더 이상 백엔드 동료에게 추가하라고 요청할 필요가 없습니다. 프런트엔드에서 직접 수행하세요
4. 프런트엔드 파일이 더 이상 백엔드 코드와 혼합되지 않습니다. 로직이 훨씬 편해 보이고
5. 페이지 이동이 이전보다 부드러워지고 부분 렌더링 및 부분 로딩이 매우 빠릅니다
6. 페이지 템플릿을 반복해서 사용할 수 있어 프론트엔드 컴포넌트 개발 시 개발 효율성이 향상됩니다

곧. 빠르게 발전하는 프론트엔드에 직면하여, 이로 인해 발생하는 작업 방식과 프로세스의 변화에 ​​적응해야 합니다. 프론트엔드와 백엔드를 분리하는 현재의 작업 방식은 미래의 트렌드가 되어야 합니다. 최종 개발자라면 우리는 새로운 프론트엔드를 대중화하는 책임을 져야 합니다. 변화를 만들기 위한 지식과 책임.

이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!

관련 읽기:

Angularjs에서 mvvm 스타일 탭을 구현하는 방법은 무엇입니까? 케이스+코드

vue2.0 프로젝트 아주 실용적인 코드 모음

위 내용은 앞부분과 뒷부분을 따로 작성해야 하는 이유는 무엇인가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!