프론트 엔드에서 계산하는 것이 언제 적절한가요?

우리 팀은 웹 기반 금융 응용 프로그램을 개발 중이며 동료와 함께 계산을 유지해야 할 부분이 있습니다.

간단한 설명 : 프론트 엔드에는 Java (ZK, Spring)를 사용하고 백엔드에는 Progress 4gl을 사용합니다. 데이터베이스의 일부 하드 코어 수학 및 데이터와 관련된 계산은 백엔드로 유지되므로 이에 대해 이야기하지 않습니다. 사용자가 X 값을 입력 한 다음 Y 값에 추가되고 (화면에 표시됨) 결과가 Z 필드에 표시됩니다. 순수하고 간단한 jQuery-ish 작업입니다.

가장 좋은 방법은 다음과 같습니다.

1) 백엔드로 돌아가는 것을 막는 자바 스크립트를 사용하여 값을 추가 한 후 "저장시"백엔드에서 값을 검증합니까?

2) 모든 비즈니스 로직을 동일한 위치에 유지하십시오. 따라서 값을 백엔드로 가져 와서 계산합니까?

3) 프런트 엔드에서 계산을 수행하십시오. 그런 다음 백엔드로 데이터를 보내고 거기에서 유효성을 검사하고 계산을 다시 수행하며 결과가 유효하고 동일한 경우에만 사용자에게 표시합니까?

4) 다른 것?

참고 : Java에서는 기본 유효성 검사를 수행하지만 대부분 다른 비즈니스 로직과 마찬가지로 대부분 백엔드에 있습니다.

백엔드의 모든 항목을 다시 계산하여 전송되는 데이터의 증가는 문제가되지 않습니다 (소규모 XML 크기; 서버 및 대역폭은 사용자가 수행 한 증가 된 작업량을 견딜 수 있음).

programming-practices web-applications front-end

— 이그나 스
소스

경험 법칙 : 강력한 형식의 언어를 사용하는 경우

— Den

모든 로직이 백엔드에 있으면 자동 단위 테스트가 더 쉬워집니다. 90 %가 백엔드 여야하고 10 %가 백엔드에있을 수 있으면 백엔드에 100 %를 넣습니다.

— Ian

@Ian : 코드를 잘 구성하면 프런트 엔드 코드에 대한 자동 단위 테스트를 수행 할 수 있습니다.

— Lie Ryan

경험 법칙 : 도망 갈 때마다.

— goldilocks

경험 법칙 : 사용자가 JavaScript를 해킹하고 자체 계산을 수행한다고 가정합니다. 보안 관점에서 계산은 백엔드에서 수행되어야합니다. JS도 더 빠른 피드백을 제공 할 수 있지만 실제로 계산은 서버에서 수행됩니다.

답변:

항상 그렇듯이 이러한 결정에는 서로 다른 목표간에 상충 관계가 있으며 그 중 일부는 서로 상충됩니다.

효율성은 프런트 엔드에서 계산을 수행 할 것을 제안합니다. 사용자 컴퓨터는 더 많은 전력을 사용하고 서버는 더 적게 사용하고 사용자는 더 빠른 피드백을보고 사용자 경험을 향상시키기 때문입니다.
보안을 위해서는 클라이언트 컴퓨터가 악의적 인 공격자가 제어 할 수 있기 때문에 상태 변경 작업 이 클라이언트 컴퓨터에서 확인되거나 계산되는 데이터에 의존 할 수 없도록 해야합니다. 따라서 서버 측에서 신뢰할 수없는 소스에서 나오는 것을 검증 해야합니다 .
프로그래밍 효율성과 유지 관리 성은 낭비되는 노력 때문에 동일한 계산을 두 번 수행해서는 안된다는 것을 나타냅니다.

표면적으로는 모든 것이 서버 측에서 수행되어야하는 것처럼 들리지만 항상 그런 것은 아닙니다. 서버 측 Java 유효성 검증기에서 Javascript 유효성 검증기를 자동 생성하여 복제 된 코드를 쉽게 유지 보수 할 수있는 경우 계산을 반복하는 것이 좋은 솔루션이 될 수 있습니다. 관련된 데이터가 모두 중요하지 않은 경우 (예 : 사용자가 자신 만 속일 수 있고 값을 조작 할 경우 사용자가 아닌 경우)에는 서버 측 유효성 검사가 필요하지 않습니다. 응답 시간이 완전히 다른 병목 현상에 의해 지배되어 왕복 지연을 인식 할 수없는 경우 UX 고려 사항이 결정적인 것은 아닙니다. 따라서 이러한 각 압력이 귀하의 상황에 얼마나 강한 지 고려해야 하고 그에 따라 결정해야합니다. .

— 킬리안 포스
소스

Programming efficiency and maintainability suggests that you shouldn't do the same computation twice because of the wasted effort.

[1] 프론트 엔드의 유효성 검사는 필요한 경우 사용자에게 빠른 피드백을 제공하여 수정할 수 있기 때문에 정확하지 않은 것을 추가하고 싶습니다 . [2] 백엔드의 유효성 검사는 반응이 좋지 않으므로 사용자에게 교정 할 수있는 최상의 기회를 제공하지 않습니다. 사용자는 기다렸다가 더 많은 작업을 다시 수행해야합니다. 따라서 두 가지 유효성 검사가 정확히 동일하지 않다고 생각합니다.

— InformedA

그건 내가 통해 얻고 싶었다 게 아니에요 - 유지 보수는 않습니다 "자신을 반복하지 않는다"의미하고, 이 원칙에 따라 반복 확실히 나쁘다. 다른 고려 사항이 없다면 그렇게하지 말아야합니다. 이 때문에 그럼에도 불구하고 종종 좋은 생각한다는 사실은 있습니다 빠른 처리를 통해, 즉이 원리, 더 나은 사용성을 모순 다른 고려 사항.

— Kilian Foth

@randomA 만약 당신이 서버에 검증되어야하는 것이 서버에서만 계산되어야한다는 것을 의미한다면, 당신은 그 원칙을 잘못 적용하고있다. 어느 시점에서 서버로 다시 보내지면 어쨌든 다시 유효성 을 검사해야합니다 . 그렇지 않으면 아직 비효율적 인 보안 참조 시스템이 필요합니다. 나는 당신이 클라이언트에서 계산을 수행 할 수 있는지, 클라이언트에서 계산을 수행 할 수 있지만 클라이언트가 말한 것을 결코 신뢰하지 말라고 말하고 싶습니다 .

— goldilocks

@goldilocks 굵게 표시된 것은 또한 동의하는 것이므로 백엔드에서 모든 것을 확인해야합니다. 필자의 요점은 프런트 엔드의 유효성 검사가 응답 성이 높기 때문에 백엔드의 유효성 검사와 완전히 동일하지는 않습니다.

— InformedA

백엔드에서 계산을 수행해야하는 강력한 이유가 있습니다.

비즈니스 로직은 프리젠 테이션 레이어에 속하지 않습니다
JavaScript의 비즈니스 로직이 위협
항상 사실이 아닌 한 프론트 엔드-> 한 백 엔드 관계가 있다고 가정 하면 백 엔드는 둘 이상의 프론트 엔드 응용 프로그램을 사용할 수 있거나 제공하는 것으로 생각해야하므로 아무것도 가정 할 수 없습니다.
계산에 많은 양의 데이터가 사용되는 경우 프런트 엔드에 데이터를 보관하는 것이 효율적이지 않습니다
계산에서 데이터베이스를 사용하는 경우 프런트 엔드에서 데이터베이스를 복제 할 수 없습니다

내 추천

데이터베이스에서 외래 키, 기본 키, 검사 제한 조건 및 트리거를 포함하여 가능한 많은 비즈니스 규칙을 모델에 적용하십시오.
비즈니스 규칙이 충족되지 않은 경우 (데이터베이스가 오류를 리턴했거나 비즈니스 계층 자체가 데이터의 유효성을 검증했기 때문에) 비즈니스 계층에서 예외가 발생하도록합니다.
응답 시간이 허용되지 않는 경우에만 Ajax를 사용하여 유효성 검증 또는 사전 처리를 수행하십시오 (실제로는 JavaScript로 작업이 수행되지 않으며 페이지를 다시로드하지 않고도 백엔드에서 수행됨).
빈 값 또는 너무 길거나 범위를 벗어난 값을 허용하지 않는 것처럼 JavaScript에서 간단한 유효성 검사를 수행 할 수 있습니다 (후자는 백엔드에서 범위를 생성 할 수 있음)

— 툴 린즈 코르도바
소스

데이터베이스에 비즈니스 규칙을 적용하는 데 문제가있는 경우 프런트 엔드에 위반을보고하는 것입니다! 프런트 엔드가 비즈니스 규칙을 시행하면 의미있는 오류 메시지를 사용자에게 신속하게 피드백 할 수 있습니다. 백엔드가이를 수행하는 경우 오류가 한 번에 하나씩보고 될 때 프론트 엔드와 백엔드 사이에 많은 양방향 트래픽이 발생합니다.

— James Anderson

@JamesAnderson 더 이상 "프론트 엔드"가 없습니다. 동일한 데이터베이스에 여러 개의 프런트 엔드가 있거나 여러 데이터베이스에 여러 개의 프런트 엔드가있을 수 있습니다. 또한 백엔드에 비즈니스 규칙을 적용한다고해서 프런트 엔드가 금지되는 것은 아닙니다. 나는 두 번째 글 머리에서 강조했다.

— Tulains Córdova '11