우리 회사에서는 임베디드 Linux 플랫폼에 웹 인터페이스를 구축해야합니다. 나는 2 가지 옵션을 볼 수 있습니다 : 당신은 HTML과 JavaScript가 서버 측에서 생성되는 기술 (JSP, Grails를 생각하지만 C ++을 사용하고 HTML / JavaScript를 생성하는 것입니다)을 사용하거나 HTML5 '클라이언트'를 생성합니다 백엔드를 생성하는 JSON 또는 XML과 통신하는 애플리케이션.

나는 웹 응용 프로그램이 현재 후자와 함께하는 경향이 있다고 생각하지만 그렇게하는 것의 장점은 무엇입니까 (프로젝트 개발자는 주로 HTML과 Javascript보다 C ++을 훨씬 잘 알고 있다는 사실을 바탕으로 전자를 선택합니다)

아약스

귀하의 질문은 "웹 응용 프로그램이 클라이언트 쪽이나 서버 쪽에서 HTML을 생성해야합니까?"로 귀결됩니다. X (XML)가 일반적으로 JSON으로 대체되었지만 클라이언트 측 생성은 AJAX를 사용하여 서버와 통신하지만 대부분의 사람들은 여전히 ​​AJAX라고 부릅니다. 서버 측 서버는 서버에서 HTML을 만듭니다.

XML에 대한 경험이 많고 JSON에 대해서는 거의 경험이 없습니다. XML에 대해 내가 아는 모든 것은 가능한 경우 JSON을 사용하도록 제안합니다.

AJAX 프로 :

• 더 빠르게 실행할 수 있도록 HTTP (S)를 통해 더 적은 데이터를 전송하십시오.
• 서버는 본질적으로 웹 서비스이므로 다른 사람 (또는 사용자)이 자신의 클라이언트를 작성할 수 있습니다. 사이트의 모바일 버전을 만들 때 도움이 될 수 있습니다. 또한 많은 발명품은 제작자가 의도하지 않은 이유로 인기가 있습니다. 서비스는 코드의 새로운 용도를 찾는 사람들에게 친숙합니다.
• 최신 응용 프로그램처럼 보입니다

AJAX 단점 :

• 자바 스크립트 디버깅
• 복잡성?
• JavaScript로 할 수있는 일은 맹인이나 장애인이 사용하기에 완전히 불가능한 경우가 많습니다.
• 더 많은 코드가 필요할 수 있습니다 (내장 장치의 전체 저장소가 더 큼)

클라이언트 서버

모든 웹 응용 프로그램은 클라이언트-서버 아키텍처를 사용합니다. HTTP 프로토콜은 웹 애플리케이션이 그런 식으로 작동하도록합니다. AJAX는 해당 디자인 제한에 대한 해결 방법을 사용하지만 HTTP의 기본 기본 모델은 여전히 ​​클라이언트 서버입니다. 웹 응용 프로그램에 MVC를 적용하는 가장 좋은 방법에 대해서는 모든 것에 매달리지 않을 것입니다. 정치적 이유로 MVC를 수행해야하는 경우 Ruby / Rails가 수행하는 방식을 살펴보십시오. 실제로 Rails는 복사하거나 사용하기에 훌륭한 아키텍처입니다.

서비스 대 앱.

좋은 서비스는 거의 항상 응용 프로그램보다 낫습니다. 그러나 좋은 서비스를 만드는 것은 어렵습니다! 충분히 잘 설계된 서비스 사양을 작성하기 전에 응용 프로그램을 만들어야 할 수도 있습니다. 필요 이상으로 일을 어렵게 만들지 마십시오. 버전 1의 경우 훌륭한 응용 프로그램 만들기에 중점을 둡니다. 응용 프로그램이 상대적으로 안정적이고 사용자의 요구 사항을 충족 할 때까지는 서비스를받는 것이 어쨌든 효과가 없을 것입니다. 잘못된 서비스를 너무 일찍 디자인하면 서비스 인터페이스를 수정하려고 할 때 시간을 낭비하고 서버와 클라이언트 코드의 대규모 리팩토링을 처리해야합니다.

C / 웹

와. 웹 개발로 전환하기 전에 3 년 동안 C와 Assembly에서 근무했습니다. 나는 특히 보안 관점에서 웹 응용 프로그램을 작성하는 데 더 나쁜 언어를 생각할 수 없습니다. 입력 유효성 검사 및 출력 이스케이프는 매우 중요합니다 ... SANS 는 매년 가장 일반적인 오류 목록을 릴리스합니다. 버퍼 오버 플로우, 주입, 교차 사이트 문제 (부적절한 출력 인코딩) ... 이러한 오류는 모두 C 또는 어셈블리에서 쉽게 만들 수 있습니다. Java와 같은 언어에는 오버플로에 영향을받지 않는 String과 일반적으로 오류 코드가 시스템 메모리에 액세스하는 것을 방지하는 예외 처리 메커니즘이 있습니다. 다국어 문자 세트 처리는 말할 것도 없습니다 (가능한 경우 UTF-8 사용 ).

메모리 또는 펌웨어 이유로 C를 사용해야하는 경우, 그렇게해야합니다. 조심해!

브라우저 지원

웹 응용 프로그램에서 사용되는 브라우저 발견되어 제작하는 첫 번째 단계 당신의 클라이언트를? W3Schools 및 Wikipedia 는 일반적인 통계의 좋은 소스이지만 YMMV입니다.

현재 작업중인 응용 프로그램은 현재 유효한 XHTML 1.0 전환 HTML 만 생성하는지 확인합니다. 또한 브라우저에서 HTML을보다 쉽게 ​​작성할 수 있도록 IE에서 Quirks Mode를 피하는 데 필요한 특정 Doctype 및 형식을 사용합니다 ( 내 블로그의 팁 참조 ). 최신 버전의 IE와 Windows 및 Linux에서 Firefox 및 Chrome을 테스트합니다 (Safari는 Chrome과 동일한 렌더링 엔진을 사용함). 이 유효성 검사 및 테스트를 통해 BlackBerry를 제외한 모든 응용 프로그램 (Windows, Mac, Linux, iPhone, Android 등)이 거의 작동합니다.

BlackBerry에는 JavaScript가있는 실제 브라우저가 없었으므로 지원하지 않습니다. BlackBerry 사용자는 실제 웹 브라우저가 없어서 불평하지 않습니다. 어쩌면 그것은 변화하고 있습니까? 몇 명의 클라이언트에게 어떤 브라우저를 사용하고 있는지 물어보고 해당 브라우저로 테스트해야합니다.

요약

모든 웹 사이트는 HTML 및 HTTP를 기반으로합니다. 응용 프로그램을 작성하는 동안 이러한 기술을 잘 참조하십시오. 툴킷을 사용하는 경우에도 응용 프로그램을 만드는 과정에서 이러한 기술을 해결하기 위해 기본적으로 이해해야하는 여러 문제가 발생합니다.

괜찮은 것처럼 보이고 빠르게 반응하는 것을 만들기 위해 CSS와 이미지 압축에 익숙해야 할 것입니다. JavaScript, 웹 서버 및 브라우저는 궁극적으로 필요한 추가 지식 영역입니다.

서버 측에서 HTML을 빌드하면 코드 기반이 더 작아지고 JavaScript를 배울 필요가 없습니다. 서버 측 모델은 프로그래머가 HTML을 생성하는 (C?) 코드를 작성하여 클라이언트로 보내기 전에 직접 볼 수 있음을 의미합니다. AJAX 모델은 프로그래머가 HTML을 생성하는 JavaScript를 작성 함을 의미합니다. 브라우저에서 JavaScript로 생성 된 HTML 코드를 검증하거나 볼 수있는 도구가 많지 않아서 올바르게 프로그래밍하기가 어렵습니다.

지금 작업하는 곳에서는 HTML을 생성하는 JavaScript를 생성하는 Java 코드가 포함되는 하이브리드 방식을 사용합니다. 여러분이 웹 개발에 익숙하지 않다면 시작하기 좋은 곳이 아닙니다. AJAX 모델을 사용해야 할 강력한 이유가 없다면 이전의 서버 측 HTML 생성 모델로 시작하여 얼마나 멀리 도달하는지 확인해야한다고 생각합니다.

후자는 "백엔드"를 일반 "데이터 서비스"(컨텍스트에서 의미 할 수있는 것)로 만드는 이점이 있습니다.

그러면 HTML 클라이언트는 해당 데이터의 가능한 많은 소비자 중 하나 일뿐입니다. iOS 앱, Andriod 앱, Windows 8 앱, API 등을 다른 소비자라고 생각하십시오.

웹 응용 프로그램의 일반적인 방법은 점점 한쪽 또는 다른 쪽을 혼합하는 것입니다.

첫 번째 접근법은 더 전통적이며 수년 동안 존재 해 왔으며 잘 문서화되어 있습니다 (c ++은 일반적으로 인기있는 언어는 아니지만).

두 번째 옵션은 더 현대적이며 오늘날 개발 블로그와 포럼에 있습니다. 그 이유 중 하나는 동일한 인터페이스를 다른 인터페이스, 모바일 및 서비스 API에 제공해야 할 필요성이 증가하고 있기 때문입니다. 두 번째 접근 방식 은 고객이 더 풍부하고 반응이 빠른 경향이 있습니다.

대체로 팀 친숙성 및 비즈니스 사례와 같은 다른 제약 조건에 따라 달라집니다.

옵션을 평가하는 데 도움이되는 몇 가지 질문 :

1. 팀은 언어와 플랫폼에 경험이 있습니까?
2. 팀은 새로운 접근 방식과 기술을 기꺼이 배우고 있습니까?
3. 이 응용 프로그램은 다른 장치 (iPhone, android, windows 8 등)에 대해 더 쉽게 프로그래밍 할 수 있다는 이점이 있습니까?
4. 서비스 또는 데이터와 통합 된 다른 내부 또는 외부 앱이 애플리케이션에 제공됩니까?

이러한 "인트라넷"애플리케이션의 경우 ExtJS4와 함께 fat-client (JavaScript / HTML5-app + JSON) 접근 방식을 사용합니다.

일반적인 "인터넷"웹 사이트에서는 더 "고전적인"접근 방식을 사용합니다.

클라이언트는 어쨌든 사이트를 렌더링해야하므로 전체 프로세스로 요금을 부과하지 않고 채워 넣을 데이터를 제공해야합니다. 응답을 생성하기위한 서버 코드 (일반 JSON 또는 XML)만으로 성능을 절약 할 수 있습니다. 또한 서버보다 항상 많은 클라이언트가 있으므로 클라이언트가 더 많은 작업을 수행하면 전체 시스템이 훨씬 더 잘 확장됩니다.

클라이언트 코드는 HTTP와 함께 제공되므로 모호한 업데이트 메커니즘 없이도 사용자에게 새 버전을 쉽게 보낼 수 있습니다. (HMTL / JS / CSS 만 교체하십시오)

일반적인 웹 사이트에서 고전적인 접근 방식을 선호하는 유일한 이유는 검색 엔진입니다.