앞으로 생각 클라이언트-서버 컴퓨팅의 귀환?

클라이언트-서버 컴퓨팅의 귀환?

비디오: 111014 금ìš"일 ë²„ë¼ì´ì ´í‹° 리허설 속보 gCm prese (십월 2024)

비디오: 111014 금ìš"일 ë²„ë¼ì´ì ´í‹° 리허설 속보 gCm prese (십월 2024)
Anonim

지난 몇 달 동안 개발 세계에서 흥미로운 점 중 하나는 최신 애플리케이션이 서버 대신 클라이언트에 더 많은 인텔리전스를 배치하는 방식으로 돌아가는 것입니다. 클라이언트-서버 모델은 물론 새로운 것은 아닙니다. 리치 클라이언트 응용 프로그램이 서버 측 응용 프로그램과 통신하는 전통적인 응용 프로그램이 수년 동안 구축 된 방식입니다. 그러나 웹 시대, 심지어 웹 2.0 시대에도 웹 서버 (일반적으로 Java 기반 응용 프로그램 서버에 있음)에 대한 정보가 많고 클라이언트는 단순한 웹 페이지 인 웹 응용 프로그램으로 초점이 이동했습니다. 클릭 할 때마다 새 페이지가로드 된 브라우저

그러나 최근 HTML5, CSS, 특히 JavaScript의 성숙으로 인해 개발자들은 웹 페이지 자체에 실제 인텔리전스와 실제 처리 기능을 제공하게되었습니다. 특히 최신 웹 브라우저에서 완벽하게 실행되는 지능형 프런트 엔드를보다 쉽게 ​​만들 수있는 다양한 클라이언트 측 JavaScript 기반 프레임 워크가 등장했습니다. 관련된 브라우저는 일반적으로 Chrome 및 Safari를 포함하여 웹킷 엔진 기반 브라우저이지만 대부분의 앱은 현재 버전의 Firefox 및 Internet Explorer에서도 제대로 실행되는 것으로 보입니다. 필요에 따라 서버에서 데이터를 가져와 동적으로 변경되는보다 복잡한 웹 페이지가 생성됩니다.

특히 3 가지 MVC 프레임 워크 인 Backbone.js, Ember.js 및 Angular.js가 가장 주목을 받고있는 것 같습니다. (MVC는 모델-뷰-컨트롤러 (model-view-controller)의 약자입니다. 이는 본질적으로 웹 클라이언트 컴퓨팅의 아키텍처입니다. "js"는 JavaScript의 약자입니다.) 본질적으로 이것은 지난 10 년 동안 널리 보급 된 AJAX (Asynchronous JavaScript and XML) 접근 방식의 결과물입니다. 그러나 훨씬 더 성숙하고 거의 표준화되었습니다. 아이디어는 브라우저에 더 많은 상태와 인텔리전스를 넣은 다음 서버 측에서 브라우저가 REST API와 연결되도록하는 것입니다.

백본은 아마도 이러한 프레임 워크 중 가장 기본적이고 최소한 일 것입니다. 그것은 많은 인기있는 사이트에 의해 다양한 범위로 사용됩니다. Ember는 Apple이 지원하는 Sproutcore라는 프레임 워크에서 성장했으며 데스크탑 스타일의 응용 프로그램을 수행 할 수 있도록 설계된 훨씬 포괄적 인 프레임 워크입니다. Twitter 직원이 처음 만든 HTML 및 CSS 용 템플릿 집합 인 Bootstrap과 함께 자주 사용됩니다. Angular는 Google의 대안으로, 그 사이 어딘가에있는 것으로 보입니다. 일부 사람들은 Ember보다 약간 유연하거나 최소한 "의견이 없다"고 생각하지만 Backbone보다 포괄적입니다. 참고로 Google은 개발자에게 Angular를 사용하여 코딩 품질을 향상 시키려고하지만 내부적으로 다른 독점 프레임 워크를 사용합니다. Microsoft는 이러한 프레임 워크를 위해 Visual Studio에 후크를 추가했습니다.

이것은 웹이기 때문에 수십 가지 대안이 있습니다. 최근에 들었던 가장 흥미로운 것 중 하나는 클라이언트와 서버 측 모두에서 JavaScript와 작동하도록 설계된 Meteor입니다. 그러나 이것은 아직 초기 단계이며 아직 실제 사용자를 모른다. 그 동안 서버 측 JavaScript 구현에 자주 사용되는 더 많은 개발자가 Node.js를 사용하고 있습니다.

이러한 프레임 워크의 장점은 분명해 보입니다. 풍부한 웹 클라이언트 응용 프로그램은 모든 것이 서버에서 실행되는 씬 클라이언트 응용 프로그램보다 강력하며 더 나은 사용자 인터페이스를 제공하고 오프라인 정보를 제공 할 수 있습니다. 이러한 프레임 워크를 사용하면 처음부터 모든 것을 구축하여 훨씬 더 빠른 리치 웹 클라이언트 애플리케이션을 작성하고 각 애플리케이션을 중심으로 개발하는 커뮤니티를 활용할 수 있습니다.

가장 중요한 것은 특정 기본 응용 프로그램을 작성하지 않고도 다른 장치로 확장 할 수있는 모바일 응용 프로그램을 만들 수 있다는 것입니다. 각 플랫폼의 특정 기능을보다 직접적으로 다룰 수있는 네이티브 앱에 대해서는 여전히 좋은 주장이 있습니다. 그러나 많은 개발자들은 이러한 프레임 워크가 특히 플랫폼이 개발하는 속도를 획기적으로 향상시킬 수 있음을 발견했습니다. 특히 Adobe에서 구매하고 Apache Cordova 프로젝트에 오픈 소스로 제공되는 오픈 소스 모바일 프레임 워크 인 PhoneGap과 함께 사용할 경우 더욱 그렇습니다.

물론 모바일은 프로세서 속도, 더 중요하게는 연결 속도 (때로는 연결 속도 부족)를 포함하여 자체 제한 사항을 제공합니다. 사람들이 웹 페이지를 통해 앱을 좋아하는 이유 중 하나는 Wi-Fi 또는 빠른 연결을 통해 기본 기능을 다운로드하고 전체 디자인이 아닌 다운로드 한 데이터를 얻을 수 있기 때문입니다. PhoneGap과 같은 패키지는 JavaScript를 다운로드 한 앱에 넣어이 문제를 해결합니다.

그러나 이러한 프레임 워크에는 다른 문제가 있습니다. 정의에 따르면 클라이언트 측에서 더 많은 컴퓨팅을 수행하면 단순한 서버 전용 앱에 비해 복잡성이 증가하고 실제로 이전 클라이언트 서버 모델의 일부 단점은 돌아옵니다. 개발자는 양쪽에서 상태를 관리해야합니다. 두 곳의 코드는 두 곳의 보안에 중점을 두어야 함을 의미합니다. 개발 팀은 종종 클라이언트에서 일하는 사람들과 서버에서 다른 사람들이 있기 때문에 추가 통신 문제가 발생합니다. 반면, 클라이언트-서버의 이전 문제 중 일부는 다시 나타나지 않고 웹 소프트웨어의 이점을 유지합니다. 이것은 표준 중심의 커뮤니티 중심 세계이므로 단일 독점 환경에 의존하지 않습니다. 클라이언트와 서버 측 부분을 분리하면 UI가 아닌 처리 만 수행하고 결과적으로 더 적은 리소스를 요구하는보다 깨끗하고 간단한 서버 측 구현을 가질 수 있습니다. 그러나 일반적으로 앱이 호출 될 때 브라우저가 서버에서 코드를로드하기 때문에 모든 클라이언트를 한 번에 업데이트 할 수 있다는 장점이 있습니다.

우리는 모든 경우가 아니라 많은 새로운 응용 프로그램에서보다 지능적인 웹 클라이언트로의 전환을 분명히보고 있습니다. 오래된 응용 프로그램을 가져 와서이 모델로 옮기는 것이 훨씬 어렵지만 일부도 볼 수 있습니다. 꽤 오래된 클라이언트 서버 모델은 아니지만 점점 더 가까워지고 있습니다.

클라이언트-서버 컴퓨팅의 귀환?