질문: 프론트엔드 개발과 백엔드 개발의 분리를 어떻게 이해해야 합니까? 분리의 장점과 단점은 무엇입니까? 특정 프로젝트를 개발할 때 이별 경험이 있으신가요? 편하게 조언 부탁드립니다~
다음은 프론트엔드와 백엔드 개발의 분리와 비분리에 대한 제가 이해한 내용입니다. 혹시 부적절한 점이 있으면 알려주세요~
표현: 프런트 엔드 개발 프로젝트는 백엔드 개발 프로젝트와 분리되어 있으며, 통신은 도메인 간 요청(종종 개발 상황에서는 프록시를 통해)을 통해 이루어지며, 페이지 라우팅은 프런트 엔드에서 처리되며 모든 데이터를 얻습니다.
기능:
프런트엔드와 백엔드 개발은 서로 영향을 미치지 않습니다.
프런트엔드는 모든 데이터를 중앙 집중화할 수 있으며 모든 페이지에서 애플리케이션 데이터에 액세스할 수 있으므로 반복적인 요청을 피할 수 있습니다.
페이지를 로드한 후 데이터를 로드하는 데 시간이 걸리고 때로는 데이터가 지연되거나 데이터 로드에 실패합니다.
플래그: /#/, 도메인 이름 뒤에 이 기호가 있습니다. URL
개발 방법 :
1) 개발 시 분리, 개발 후 병합 예:
vue-cli
를 통해 생성된 프로젝트의 경우 프론트엔드 개발 완료 후 생성된 프론트를 병합 -리소스 파일을 백엔드 프로젝트(예: laravel)에 넣습니다. vue-cli
建立的项目,前端开发完成后把生成的前端资源文件合并到后端项目(如laravel)里;
2)开发时分离,开发完成仍保持分离,比如:ionic
2) 개발 중에 분리되고 개발 후에도 분리된 상태로 유지됩니다. 예:
ionic
개발된 하이브리드 APP 프로젝트
표현:
프런트 엔드 프로젝트와 백엔드 프로젝트는 동일하며 페이지 라우팅은 백엔드에서 처리되며 데이터 통신은 도메인을 넘나들 필요가 없습니다. 특징:
개발 중에 프런트엔드와 백엔드가 밀접하게 연결됩니다.
백엔드는 페이지를 반환할 때 동시에 페이지에 필요한 데이터를 반환하므로, 사용자가 페이지에 액세스할 때 데이터 지연 또는 데이터 획득 실패 개발 방법: laravel
的blade
웹 R&D 모델의 진화
기술적인 고려 사항에 따른 질문입니다. 사실 분리 여부는 비즈니스와 비용에 따라 결정됩니다. 프론트엔드와 백엔드 개발자가 충분하고 비즈니스가 상대적으로 복잡하다면 당연히 프론트엔드와 백엔드를 분리해야 하고 전문적인 사람들이 전문적인 일을 하므로 품질 요구와 추후 유지 관리에 유리합니다. . 그러나 프런트엔드와 백엔드를 분리하면 비즈니스의 프런트엔드와 백엔드를 모두 이해해야 하며 추가적인 프런트엔드와 프런트엔드 공동 디버깅 및 테스트가 필요합니다. 모래밭.
장점:
인터페이스에 동의한 후에는 프런트엔드와 백엔드를 동시에 개발할 수 있으며, 품질과 사후 유지 관리도 크게 향상될 수 있습니다.
단점:
통신비 및 인건비.