클라이언트 측 로직 또는 서버 측 로직?

클라이언트 측 로직 또는 서버 측 로직?

---

저는 웹 기반 프로젝트를 수행했으며 제가 만난 대부분의 어려움 (질문, 혼란)은 도움으로 해결할 수 있습니다. 그러나 숙련 된 개발자에게 질문 한 후에도 여전히 중요한 질문 이 있습니다. 서버 측 코드와 클라이언트 측 스크립팅 (JavaScript)을 모두 사용하여 기능을 구현할 수있는 경우 어느 것이 선호되어야합니까?

간단한 예 :

동적 HTML 페이지를 렌더링하기 위해 페이지를 서버 측 코드 (PHP, Python)로 형식화하고 Ajax를 사용하여 형식이 지정된 페이지를 가져 와서 직접 렌더링 할 수 있습니다 (서버 측에서 더 많은 로직, 클라이언트 측에서 더 적은 로직).

또한 Ajax를 사용하여 데이터 (형식이 지정되지 않은 JSON)를 가져오고 클라이언트 측 스크립팅을 사용하여 페이지를 형식화하고 더 많은 처리로 렌더링 할 수 있습니다 (서버는 DB 또는 기타 소스에서 데이터를 가져와 클라이언트에 반환합니다. JSON 또는 XML을 사용합니다. 클라이언트 측에서는 더 많은 로직을, 서버에서는 더 적게).

그렇다면 어느 것이 더 나은지 어떻게 결정할 수 있습니까? 어느 것이 더 나은 성능을 제공합니까? 왜? 어느 것이 더 사용자 친화적입니까?

브라우저의 JS 엔진이 진화함에 따라 JS를 더 짧은 시간에 해석 할 수 있으므로 클라이언트 측 스크립팅을 선호해야합니까?

반면에 하드웨어가 진화함에 따라 서버 성능이 증가하고 서버 측 로직 비용이 감소 할 것입니다. 그렇다면 서버 측 스크립팅을 선호해야합니까?

편집하다:

답변으로 간단히 요약하고 싶습니다.

클라이언트 측 로직의 장점 :

1. 더 나은 사용자 경험 (더 빠름).
2. 적은 네트워크 대역폭 (저렴한 비용).
3. 확장 성 향상 (서버 부하 감소).

서버 측 로직의 장점 :

1. 보안 문제들.
2. 가용성 및 접근성 향상 (모바일 장치 및 이전 브라우저).
3. 더 나은 SEO.
4. 쉽게 확장 가능 (더 많은 서버를 추가 할 수 있지만 브라우저 속도를 높일 수 없음).

특정 시나리오에 직면 할 때이 두 가지 접근 방식의 균형을 맞출 필요가있는 것 같습니다. 하지만 어떻게? 모범 사례는 무엇입니까?

다음 조건을 제외하고 클라이언트 측 논리를 사용합니다.

1. 보안이 중요합니다.
2. 특수 그룹 (JavaScript 비활성화 됨, 모바일 장치 및 기타).

---

대부분의 경우 가장 좋은 대답은 둘 다 입니다.

Ricebowl이 말했듯이 클라이언트를 절대 신뢰하지 마십시오. 그러나 클라이언트를 신뢰한다면 거의 항상 문제라고 생각합니다. 애플리케이션을 작성할 가치가 있다면 적절하게 보안을 유지할 가치가 있습니다. 누군가 자신의 클라이언트를 작성하고 예상하지 못한 데이터를 전달하여 문제를 깰 수 있다면 그것은 나쁜 일입니다. 따라서 서버에서 유효성을 검사해야합니다.

불행히도 서버의 모든 것을 검증하면 종종 사용자 경험이 좋지 않습니다. 그들은 그들이 입력 한 많은 것들이 틀렸다는 것을 알기 위해서만 양식을 작성할 수 있습니다. 이것은 "인터넷 1.0"에서 효과가 있었을 수 있지만 오늘날의 인터넷에서는 사람들의 기대가 더 높습니다.

이로 인해 상당한 양의 중복 코드를 작성하고 둘 이상의 위치에서 유지 관리 할 수 ​​있습니다 (최대 길이와 같은 일부 정의도 데이터 계층에서 유지해야 함). 상당히 큰 응용 프로그램의 경우 코드 생성을 사용하여이 문제를 해결하는 경향이 있습니다. 개인적으로 저는 UML 모델링 도구 (Sparx System의 Enterprise Architect)를 사용하여 시스템의 "입력 규칙"을 모델링 한 다음 부분 클래스 (일반적으로 .NET에서 작업 중임)를 사용하여 유효성 검사 논리를 생성합니다. XML과 같은 형식으로 규칙을 코딩하고 클라이언트 및 서버 계층 모두에서 해당 XML 파일 (입력 길이, 입력 마스크 등)에서 여러 검사를 파생하여 유사한 작업을 수행 할 수 있습니다.

듣고 싶었던 내용이 아닐 수도 있지만 올바르게 수행하려면 두 계층 모두에 규칙을 적용해야합니다.

---

나는 서버 측 로직을 선호하는 경향이 있습니다. 내 이유는 매우 간단합니다.

1. 나는 클라이언트를 신뢰하지 않습니다. 이것은 진정한 문제 일 수도 있고 아닐 수도 있지만 습관적입니다.
2. 서버 측은 트랜잭션 당 볼륨을 줄입니다 (트랜잭션 수가 증가하지만).
3. 서버 측은 어떤 로직이 발생하는지 상당히 확신 할 수 있음을 의미합니다 (클라이언트 브라우저에서 사용할 수있는 Javascript 엔진에 대해 걱정할 필요가 없습니다).

아마도 더 많고 더 나은 이유가있을 것입니다. 그러나 이것이 바로 지금 제 마음의 맨 위에있는 것입니다. 더 많이 생각하면 추가하거나 먼저 추가 할 것입니다.

---

편집 된 valya 는 클라이언트 측 로직 (Ajax / JSON 사용)을 사용하면 API를 (더 쉽게) 생성 할 수 있다고 설명합니다. 이것은 사실 일 수 있지만, 나는 반 정도만 동의 할 수 있습니다.

서버 측 논리에 대한 나의 개념은 데이터를 검색하고 구성하는 것입니다. 이것이 맞다면 논리는 '컨트롤러'(MVC의 C)입니다. 그리고 이것은 '뷰'로 전달됩니다. 나는 데이터를 얻기 위해 컨트롤러를 사용하는 경향이 있으며, '뷰'는 사용자 / 클라이언트에게 그것을 제시하는 것을 다룬다. 따라서 클라이언트 / 서버 구분이 API를 만드는 주장과 반드시 ​​관련이 있다는 것을 알지 못합니다. 기본적으로 코스 용 말입니다. :)

... 또한 애호가로서 저는 MVC를 약간 뒤틀린 사용법을 알고 있으므로 그 점을 바로 잡을 의향이 있습니다. 그러나 나는 여전히 프레젠테이션을 논리와 별도로 유지합니다. 그리고 그 분리는 API가가는 한 플러스 포인트입니다.

---

나는 일반적으로 합리적인 클라이언트 측을 구현합니다. 나를 서버 측으로 만드는 유일한 예외는 다음을 해결하는 것입니다.

신뢰 문제

누구나 JavaScript를 디버깅하고 암호를 읽을 수 있습니다. 여기에서는 당연합니다.

성능 문제

자바 스크립트 엔진은 빠르게 진화하고 있으므로 문제가되지는 않지만 여전히 IE가 지배하는 세상에 있기 때문에 많은 양의 데이터를 처리 할 때 속도 가 느려질 것 입니다 .

언어 문제

JavaScript는 약한 유형의 언어이며 코드에 대해 많은 가정을합니다. 이로 인해 특정 브라우저에서 제대로 작동하도록하기 위해 으스스한 해결 방법을 사용할 수 있습니다. 나는 전염병 같은 이런 종류의 것을 피합니다.

---

귀하의 질문에 따르면 단순히 값을 양식에로드하려는 것 같습니다. 위의 문제를 제외하고 3 가지 옵션이 있습니다.

순수한 클라이언트 측

단점은 사용자의로드 시간이 두 배가된다는 것입니다 (빈 양식에 대해 한 번로드, 데이터에 대해 또 다른로드). 그러나 양식에 대한 후속 업데이트는 페이지를 새로 고칠 필요가 없습니다. 동일한 양식으로로드되는 서버에서 많은 데이터를 가져 오는 경우 사용자는 이것을 좋아할 것입니다.

순수한 서버 측

장점은 페이지가 데이터와 함께로드된다는 것입니다. 그러나 이후 데이터를 업데이트하려면 페이지의 모든 / 중요한 부분을 새로 고쳐야합니다.

서버-클라이언트 하이브리드

두 가지 장점을 모두 얻을 수 있지만 두 개의 데이터 추출 지점을 만들어야하므로 코드가 약간 부풀려집니다.

각 옵션에는 장단점이 있으므로이를 평가하고 어떤 옵션이 가장 큰 이점을 제공하는지 결정해야합니다.

---

내가 언급하지 않은 한 가지 고려 사항은 네트워크 대역폭이었습니다. 구체적인 예를 들자면, 제가 참여한 앱은 모두 서버 측에서 수행되었으며 결과적으로 200Mb 웹 페이지가 클라이언트로 전송되었습니다 (여러 앱을 대대적으로 재 설계하지 않고는 더 적게 할 수 없었습니다). 페이지로드 시간은 2 ~ 5 분입니다.

서버에서 JSON으로 인코딩 된 데이터를 전송하여이를 다시 구현하고 로컬 JS가 페이지를 생성하도록하면 주요 이점은 전송 된 데이터가 20Mb로 축소되어 다음과 같은 결과가 발생한다는 것입니다.

• HTTP 응답 크기 : 200Mb + => 20Mb + ( 해당 대역폭 절약 포함 !)

• 페이지로드 시간 : 2-5 분 => 20 초 (이 중 10-15는 지옥에 최적화 된 DB 쿼리가 차지함).

• IE 프로세스 크기 : 200MB + => 80MB +

마지막 2 점은 주로 서버 측이 테이블 내 트리 구현에 엉성한 테이블을 사용해야한다는 사실에 기인 한 것이지만 클라이언트 측으로 이동하면 훨씬 더 가벼운 페이지를 사용하도록 뷰 레이어를 재 설계 할 수있었습니다. 그러나 내 요점은 네트워크 대역폭 절약이었습니다.

---

I built a RESTful web application where all CRUD functionalities are available in the absence of JavaScript, in other words, all AJAX effects are strictly progressive enhancements.

I believe with enough dedication, most web applications can be designed this way, thus eroding many of the server logic vs client logic "differences", such as security, expandability, raised in your question because in both cases, the request is routed to the same controller, of which the business logic is all the same until the last mile, where JSON/XML, instead of the full page HTML, is returned for those XHR.

Only in few cases where the AJAXified application is so vastly more advanced than its static counterpart, GMail being the best example coming to my mind, then one needs to create two versions and separate them completely (Kudos to Google!).

---

I'd like to give my two cents on this subject.

I'm generally in favor of the server-side approach, and here is why.

• More SEO friendly. Google cannot execute Javascript, therefor all that content will be invisible to search engines
• Performance is more controllable. User experience is always variable with SOA due to the fact that you're relying almost entirely on the users browser and machine to render things. Even though your server might be performing well, a user with a slow machine will think your site is the culprit.
• Arguably, the server-side approach is more easily maintained and readable.

I've written several systems using both approaches, and in my experience, server-side is the way. However, that's not to say I don't use AJAX. All of the modern systems I've built incorporate both components.

Hope this helps.

---

At this stage the client side technology is leading the way, with the advent of many client side libraries like Backbone, Knockout, Spine and then with addition of client side templates like JSrender , mustache etc, client side development has become much easy. so, If my requirement is to go for interactive app, I will surely go for client side. In case you have more static html content then yes go for server side. I did some experiments using both, I must say Server side is comparatively easier to implement then client side. As far as performance is concerned. Read this you will understand server side performance scores. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

---

I know this post is old, but I wanted to comment.

In my experience, the best approach is using a combination of client-side and server-side. Yes, Angular JS and similar frameworks are popular now and they've made it easier to develop web applications that are light weight, have improved performance, and work on most web servers. BUT, the major requirement in enterprise applications is displaying report data which can encompass 500+ records on one page. With pages that return large lists of data, Users often want functionality that will make this huge list easy to filter, search, and perform other interactive features. Because IE 11 and earlier IE browsers are are the "browser of choice"at most companies, you have to be aware that these browsers still have compatibility issues using modern JavaScript, HTML5, and CSS3. Often, the requirement is to make a site or application compatible on all browsers. This requires adding shivs or using prototypes which, with the code included to create a client-side application, adds to page load on the browser.

All of this will reduce performance and can cause the dreaded IE error "A script on this page is causing Internet Explorer to run slowly" forcing the User to choose if they want to continue running the script or not...creating bad User experiences.

Determine the complexity of the application and what the user wants now and could want in the future based on their preferences in their existing applications. If this is a simple site or app with little-to-medium data, use JavaScript Framework. But, if they want to incorporate accessibility; SEO; or need to display large amounts of data, use server-side code to render data and client-side code sparingly. In both cases, use a tool like Fiddler or Chrome Developer tools to check page load and response times and use best practices to optimize code.

Checkout MVC apps developed with ASP.NET Core.

---

I think the second variant is better. For example, If you implement something like 'skins' later, you will thank yourself for not formatting html on server :)

It also keeps a difference between view and controller. Ajax data is often produced by controller, so let it just return data, not html.

If you're going to create an API later, you'll need to make a very few changes in your code

Also, 'Naked' data is more cachable than HTML, i think. For example, if you add some style to links, you'll need to reformat all html.. or add one line to your js. And it isn't as big as html (in bytes).

But If many heavy scripts are needed to format data, It isn't to cool ask users' browsers to format it.

---

As long as you don't need to send a lot of data to the client to allow it to do the work, client side will give you a more scalable system, as you are distrubuting the load to the clients rather than hammering your server to do everything.

On the flip side, if you need to process a lot of data to produce a tiny amount of html to send to the client, or if optimisations can be made to use the server's work to support many clients at once (e.g. process the data once and send the resulting html to all the clients), then it may be more efficient use of resources to do the work on ther server.

---

If you do it in Ajax :

You'll have to consider accessibility issues (search about web accessibility in google) for disabled people, but also for old browsers, those who doesn't have JavaScript, bots (like google bot), etc.

You'll have to flirt with "progressive enhancement" wich is not simple to do if you never worked a lot with JavaScript. In short, you'll have to make your app work with old browsers and those that doesn't have JavaScript (some mobile for example) or if it's disable.

But if time and money is not an issue, I'd go with progressive enhancement.

But also consider the "Back button". I hate it when I'm browsing a 100% AJAX website that renders your back button useless.

Good luck!

---

2018 answer, with the existence of Node.js

Since Node.js allows you to deploy Javascript logic on the server, you can now re-use the validation on both server and client side.

Make sure you setup or restructure the data so that you can re-use the validation without changing any code.

ReferenceURL : https://stackoverflow.com/questions/1516852/client-side-logic-or-server-side-logic