클라이언트 쪽 또는 서버 쪽 처리를 강조하는 것의 장단점

처리 서버 측이 많은 웹 앱을 작성하고 싶은 이유는 무엇입니까?

나에게, 클라이언트 측에 프로그램을 작성하는 것은 최소한의 처리만으로 클라이언트에 데이터를 보내면되기 때문에 가능한 한 많은 서버로드를 제거하기 때문에 큰 이점이다.

서버 측을 작성하고 클라이언트 측을 보기 로 취급하는 것 외에도 웹 응용 프로그램을 작성하는 것은 거의 볼 수 없습니다 . 왜 내가 이것을하고 싶습니까? 내가 볼 수있는 유일한 장점은 내가 원하는 언어 ( http://www.paulgraham.com/avg.html ) 로 작성할 수 있다는 것 입니다.

두 가지 주요 문제가 있습니다.

1. 첫 번째는 쉽습니다. 일반적으로 클라이언트 측에서 어떤 종류의 리소스를 사용할 수 있는지 모릅니다. 무언가를 처리하는 데 1.5GB가 필요한 경우 알 수없는 클라이언트 플랫폼에서 알 수없는 클라이언트 브라우저 (IE, Safari, Opera, Firefox 등)로 실제로 밀어 넣을 수 있습니까? 당신이 그것을 압도 할 때 클라이언트는 자신의 시스템 dogging을 감사합니까?

2. 두 번째는 더 건축적인 것입니다. 어떤 층을 외부 세계에 노출하고 싶습니까? 대부분은 데이터 계층을 노출하는 것이 매우 위험하다는 데 동의합니다. 서비스 계층은 어떻습니까? 그 논리를 실제로 전달하고 싶습니까? 그렇다면 입력 지점을 데이터 계층에 노출하고 있습니까? 서비스 계층 서버 측을 유지한다면 무엇이 남았습니까? UI 맞지? 서버에 남아있는 양과 클라이언트에있는 양에 대한 고려 사항은 이유 1을 참조하십시오.

가장 먼저 보안 입니다. 모든 논리를 클라이언트에게 전달하면 해커와 익스플로잇에게 적합한 게임입니다.

인지 된 가치가있는 것은 5 분 동안 지속되지 않으며, 특히 화폐 가치는 게임이나 해킹 또는 악용되어 시스템을 상당히 나쁘게 만듭니다. 금전적 가치가 거의 없거나 전혀 없어도 지루하기 때문에 시스템을 파괴하기 위해 해킹 할 사람들이 있습니다.

서버 측과 클라이언트 측

클라이언트 측 처리는 페이지 기반 접근 방식 및 SOAP 대신 MVC뿐만 아니라보다 일반적인 REST 표준과 일치합니다. 이러한 경향의 출현과 AJAX 및 Html-RIA에 중점을 두면서 클라이언트 측 스크립팅이 증가하고 있으며 더 인기가 있습니다. 그러나 보안 문제와 클라이언트 기능으로 인해 클라이언트 쪽 스크립팅에는 특정 틈새가 있으므로 모든 용도로 사용해서는 안됩니다.

고려 사항 :

변하기 쉬운

대상 고객의 상당 부분이 모바일 사용자 인 경우 서버에 많은 처리량을 두어야합니다.

브라우저 간 일관성

웹 표준은 먼 길을 갔고 이것이 큰 문제가되지는 않지만 모든 웹 개발자는 IE 6,7 및 8과 때로는 Safari가 클라이언트 측에서 재미있게 행동 할 수 있다는 것을 알고 있습니다. 구현되지 않은 표준으로 인한 보안 제한 및 기타. 최종 사용자는 브라우저에 특정 제한이 있거나 클라이언트 측 처리를 완전히 해제하도록 구성 할 수 있습니다 (자바 스크립트 없음). 100 % 사용자에게 일관성이 필요한 경우 (특히 정통 작업을 수행하는 경우) 서버 쪽이 가장 중요합니다.

보안

보안하려는 데이터 조작은 서버에서 수행해야합니다. 클라이언트 측에서 처리되는 모든 데이터는 조작을 위해 절대적으로 열려 있습니다. 예를 들어, 일부 정보를 처리 한 다음 시스템으로 다시 게시되는 Javascript 함수가있는 경우, 백엔드 보안이 우수하더라도 결과를 다시 게시하기 직전에 결과를 조작하는 것이 매우 쉽습니다.

UI / UX

클라이언트 측 프로세싱은 사용자 인터페이스를위한 것이며 풍부한 인터넷 애플리케이션 (RIA)을 생성합니다. 전체 페이지를 다시로드하는 대신 애니메이션, 효과, 사용자 상호 작용을 작성하고 AJAX 호출을 통해 컨텐츠를 동적으로로드하는 데 사용됩니다.

주로 노력의 중복이 될 것입니다. 클라이언트의 모든 데이터는 서버 수준에서 다시 확인되고 처리되었을 것입니다.

서버는 리치 / 로버트 클라이언트가 데이터를 보냈다고 가정 할 수 없으므로 전송 된 데이터가 있으면 서버가 데이터를 확인하고 처리해야합니다. 그래서 거기에 두는 것이 합리적입니다.

그러나 더 나은 UI 경험을 위해 클라이언트 수준에서 일부 논리를 수행 할 수 있다고 생각합니다.

정확하지 않은 이유는 서버에 데이터를 보내거나 완료되지 않은 경우입니다. 필수 필드 나 형식이 올바른 전화 또는 이메일 주소를 쉽게 확인할 수 있습니다. 나는 양식을 제출하는 것을 좋아하지 않았고 필드에 들어가는 것을 잊었다 고 5 초 동안 기다렸다. 이러한 종류의 처리는 반드시 클라이언트에서 수행하고 사용자에게 빠른 응답을 위해 클라이언트 측 논리를 사용하고 올바른지 확인하십시오. 지적했듯이, 보너스 부작용은 서버가 덜 나쁜 데이터 요청을 처리해야한다는 것입니다. 그러나 서버는 여전히 유효성 검사해야하므로 논리를 버리고 있습니다. 그러나 사용자는 더 행복 할 것입니다.

여기에 좋은 선이 있습니다. 간단한 유효성 검사 논리는 OK이고 핵심 비즈니스 논리는 OK가 아닙니다.

1. 우선 웹 응용 프로그램의 아키텍처를 이해해야합니다. 대부분이 모두 3 계층은 아닙니다.

   a) 클라이언트 / 프레젠테이션-HTML 및 Javascript에는 ActiveX / Flash / Java 애플릿 / Silverlight가 포함될 수 있습니다. 사지로 나가 백엔드 서버와 통신하는 기본 모바일 애플리케이션을 추가합니다. 기본적으로이 계층의 역할은 시스템 사용자가 해당 계층과 상호 작용할 수있는 인터페이스를 제공하는 것입니다.

   b) 비즈니스 로직-클라이언트의 데이터가 수집, 처리 및 저장되고 데이터에 대한 클라이언트 요청이 처리되어 클라이언트로 다시 전송되는 PHP / RoR / Java

   c) 백엔드 데이터 저장소-시스템 정보를위한 영구 저장소를 제공합니다

2. 따라서 모든 계층에서 어디에서 유효성 검사를 수행합니까? 왜?

   a) 클라이언트 측-사용자가 올바른 데이터, 필수 필드 등을 입력했는지 확인하십시오

   b) 비즈니스 로직-고객 데이터를 필터링, 삭제 및 검증합니다. 보다 복잡한 비즈니스 규칙을 실행하여 데이터를 스토리지에 맞게 구성하십시오. 클라이언트가 다를 수 있으므로 브라우저에서 Javascript를 비활성화 할 수 있다는 사실 때문에 프런트 엔드에서 수행 된 일부 유효성 검사가 여기에서 반복됩니다. 예를 들어 API를 통해 다른 소스의 데이터를 수신 할 수도 있으므로 모두 확인해야합니다.

   c) 백엔드 데이터 저장소-제약 조건으로 인해 데이터가 저장 및 나중에 검색 할 수 있도록 잘 구성됩니다.

따라서 검증 노력에 초점을 맞추고 각 계층을 사용하여 가장 적합한 검증을 수행하고이를 처리 할 수있는 계층에 대해보다 복잡한 규칙을 남겨 둡니다.

중요한 부분은 처리를 데이터에 가깝게 유지하는 것입니다. 수백 GB의 데이터가 있다면 분명히 클라이언트에게 제공하지 않을 것입니다. 데이터 액세스 속도가 증가함에 따라 이는 문제가되지 않지만 빅 데이터 사이트가있는 경우 서버를 출하하기 전에 서버에서 필터링 및 범위를 좁히기를 원합니다.

클라이언트 쪽에서 동작을 완전히 만들면 (예 : 자바 스크립트 사용) SEO가 문제가 될 수 있습니다.

서버 측에 많은 정보를 유지하는 웹 솔루션은 검색 엔진에 표시되는 방식으로 특정 URL에 게시 된 특정 콘텐츠 (보통 RESTful)를보다 쉽게 ​​유지할 수 있습니다.

또한 방문자가 특정 페이지를 북마크 할 수 있습니다. 당신은 페이스 북에서 그것을 시도 했습니까?

이 문제는 해결할 수 있지만 일반적으로 서버에서 많은 작업을 수행하는 응용 프로그램 (RAILS, WordPress 등)에 내장되어 있지만 REACT라고 말하면 후프를 뛰어 넘어야합니다.

그 이유는 안정성 입니다.

서버 측에서 안정적인 구성 요소를 선택할 수 있습니다. 일반적으로 이것은 Java와 FreeMarker와 같이 매우 신중하게 선택된 라이브러리를 선택한다는 것을 의미합니다. 말할 것도없이 Java의 표준 라이브러리를 제외한 모든 라이브러리는 일회용으로 취급되므로 자체 제작 래퍼를 통해 외부 라이브러리에 액세스합니다. 이것은 요구 사항이 발생하면 한 라이브러리에서 다른 라이브러리로 쉽게 변경할 수 있음을 의미합니다.

Java를 새 버전으로 업데이트 할 때마다 주요 버전 업데이트에서도 Java가 매우 안정적인 구성 요소이기 때문에 일반적으로 잘 작동합니다. 또한 내가 가지고있는 모든 서버는 동일한 Java 버전을 실행하고 있습니다. 모든 클라이언트가 동일한 JavaScript 구현을 실행하는 것은 아닙니다.

클라이언트 쪽에서는 안정적인 구성 요소를 선택할 수 없습니다. 브라우저 제작자들은 제가 특히 마음에 들지 않는 언어 인 JavaScript를 선택하도록 강요 할 것입니다. (그리고 JavaScript로 컴파일 된 언어에 대해서는 말하지 마십시오. 끔찍합니다!) 모든 브라우저의 JavaScript 구현은 다릅니다. 이것은 지원되는 모든 브라우저 버전으로 제품을 테스트하는 것이 완전히 지옥이라는 것을 의미합니다.

내 솔루션? 나는 서버 측에서 가능한 한 많은 처리를 수행하며 클라이언트 측은 서버로 데이터를 보내고 JSON 및 HTML 조각 형태로 서버에서 데이터를 수신하는 경량 래퍼 일뿐입니다. XML을 피하십시오. 대신 JSON을 사용하십시오.

나는 클라이언트 측 템플릿을하지 않습니다. 서버의 내용을 HTML 조각으로 렌더링 한 다음 .innerHTML속성을 사용 하여 클라이언트 쪽의 다양한 자리 표시 자 요소에 할당합니다 . 두 개의 템플릿 엔진 (자바 엔진과 자바 스크립트 엔진)이 필요하지 않기 때문에 기술 스택을 가능한 한 단순하게 유지합니다.

단점은 분명히 빛의 속도 지연입니다. 대륙간에 0.5 초의 대기 시간이 드문 일은 아닙니다.

요즘 고객은 스마트 폰일 수 있습니다. 스마트 폰은 배터리 수명이 제한되어 있으므로 계산량이 많은 경우 서버로 오프로드하는 것이 좋습니다. 그러나 클라이언트 측에서 수행하면 간단한 작업이 에너지 효율적일 수 있습니다. 무선 액세스를 피할 수 있기 때문입니다. 그러나 안정성이라는 주요 논거는 실제로 간단한 계산조차도 서버로 오프로드하는 것이 합리적 일 수 있습니다.

부록으로 이미 일부 답변에서 관찰 된 것처럼 보안 도 확보 할 수 있습니다. 응용 프로그램 논리가 전적으로 클라이언트 측에있는 경우 누군가는 온라인 웹 상점에서 구매할 대상으로 가격을 설정할 수 있습니다.