it-gundan.com

"분리 된"웹 응용 프로그램의 장점 / 단점

나는 (곧) 다소 큰 PHP/MySQL 웹 응용 프로그램을 디자인하는 과정에 있습니다. 나는 내부 건축까지 길을 갈았습니다. 웹 사이트를 "전통적인"웹 응용 프로그램으로 구축 할 수 있습니다. 요청하면 서버가 HTML 페이지를 작성하고 전체 페이지를 전송하며 브라우저가이를 렌더링하거나 "분리 된"웹 사이트로 만들 수 있습니다. "초기로드시 애플리케이션의 전체 HTML 구조 및 코드가 브라우저에 제공되는 웹 애플리케이션이며, 애플리케이션은 JavaScript 콜백을 사용하여 특정 데이터를 얻거나 통합 API를 통해 명령을 실행합니다. 또한 여러 버전의 사이트 (데스크톱, 모바일, iPhone/Android 모바일, 검색 엔진 친화적 인 등)가 있고 언젠가는 독립형 모바일 또는 데스크톱 앱도 있습니다.

웹 개발자로서 이러한 각 아키텍처에 어떤 장점/단점이 있습니까? 내가 왜 다른 사람과 함께 가야하는지 분명한 이유가 있습니까? 개발자가 선호하는 것입니까?

3
Adam Maras

우선, 비동기식 무거운 웹 사이트를 사용하든 아니든 관계없이 iPhone/Mobile 및 데스크탑 응용 프로그램을 빌드하는 기능에는 큰 영향을 미치지 않습니다. 어느 쪽이든 코드를 재사용 할 수 없습니다.

또한 비동기 사이트는 일반 사이트보다 느리거나 느릴 수 있습니다. 일반적으로 이러한 종류의 기능은 특히 풍부한 사용자 경험을 위해 추가됩니다. 웹 크롤러가 JavaScript의 의도를 완전히 이해할 수 없으므로 대부분 JavaScript를 무시하기 때문에 JavaScript를 사용하면 SEO에서 해가되는 경향이 있습니다.

나는 당신이 찾고있는 것은 기능적 (중간) 계층을 한 번만 작성하고 모든 앱에 대해 동일한 계층을 사용하여 개발 오버 헤드를 줄이는 방법이라고 생각합니다. 이 경우에는 가치가 있다고 생각하지만 솔직히 이러한 종류의 아키텍처는 설정하기가 어렵고 많은 시간이 걸립니다. 가능한 한 최선을 다해 웹 사이트를 개발하고 중간 계층 코드를 최대한 강하게 유지해야한다고 생각합니다. 그렇게하면 iPhone 앱을 추가 할 때가되거나 일반적인 중간 수준의 모델로 더 쉽게 이동할 수있는 모든 것이 가능해집니다

내가 정말로 옹호하는 것은 아기 발걸음을 내딛는 것입니다. 아직 모르는 것을 처리하기 위해 지금 코드를 작성하지 마십시오. 필요한 코드를 작성하고 가능한 한 유연하게 만드십시오.

4
Ben Hoffman

JavaScript/AJAX에 크게 의존하는 "분리 된"응용 프로그램의 아이디어는 많은 문제를 야기 할 것이라고 생각합니다. 내 머리 꼭대기에서 몇 가지 :

  1. Google이 색인을 생성하는 데 어려움을 겪기 때문에 SEO에 좋지 않습니다.
  2. "책갈피"만들기가 어려울 것입니다
  3. 많은 모바일 기기에서 자바 스크립트 지원이 매우 제한적이거나 깨져 있기 때문에 어려움을 겪을 것입니다.
5
Eric Petroelje

첫째,이 답변이 너무 명백하거나 기본적이라면 위법이 없습니다. Ajax 또는 jQuery와 같은 용어 대신 "분리 된"을 사용하면이 주제에 대한 경험이 줄어 듭니다. 물론 나는 질문을 잘못 읽을 수 있으므로 그럴 경우 사과드립니다.

현명하게 사용하십시오

작업이 가장 효율적으로 수행되는 위치 및 방법과 관련하여 서버 쪽 또는 클라이언트 쪽 작업 중에서 선택한 것을 생각하십시오. 이렇게하면 서버에서 페이지를 빠르게 렌더링 할 수 있지만 작업을 브라우저로 오프로드하면됩니다. 그리고, 당신은 단지 판단 요청을해야하는 회색 영역이있을 것입니다. 당신의 일은 똑똑한 분업을 찾는 것입니다.

서버 측은 무엇입니까?

(이것은 요점을 설명하기위한 극단적 인 예입니다.) 어떤 유형의 검색을 수행하는 웹 앱을 작성한다고 가정하십시오. 서버 측 PHP 웹 서비스를 호출하여 전체 서버 2GB 데이터베이스를 검색하여 "서버를 비우고"사용자 시스템으로 검색을 오프로드하기 위해 브라우저 측 Javascript를 작성하지 않습니다. 당신이하는 일은 POST 형식의 사용자로부터 검색어를 서버로 다시 가져 와서 데이터베이스를 직접 쿼리 한 다음 결과를 서버에서 브라우저로 다시 보내는 것입니다.

여기서의 논리는 DB 자체가 쿼리를 가장 잘 수행하는 방법을 알고 서버가 소스 데이터에 더 가깝고 구성 요소 사이에서 더 적은 데이터를 이동해야한다는 것입니다. 브라우저에는 표시되는 내용 만 필요하므로 모든 브라우저로 보내지 마십시오. (상대 언어 성능은 말할 것도 없습니다.)

브라우저에는 무엇이 있습니까?

브라우저 사이드 코드는 "분리 된"시나리오입니다 (정확하게 이해하는 경우). 그러나 브라우저가 대부분의 지능형 작업을 수행하려면 서버 협력이 필요합니다.

좋아, 검색 응용 프로그램이 작동하지만 멋진 바지 Ajax로 꾸미고 싶습니다. PHP 웹 서비스를 작성하여 몇 글자를 가져와 일치하는 검색어 a 를 Bing, Google 등의 "검색 제안"기능으로 반환하십시오. 브라우저 코드는 사용자가 3 ~ 4 자로 입력 한 후에 만 ​​용어를 제안하므로 제안 목록이 작습니다. 서버로 돌아가서 해당 필드에서 데이터베이스를 색인화하여 검색이 빠르고 빠릅니다.

여기서 "검색 제안"은 를 서버와 클라이언트간에 분리해야하는 기능입니다. 브라우저는 대상이되는 작은 데이터 더미를 신속하게 처리 할 수 ​​있습니다. 서버는 목표로하는 작은 데이터 더미를 가져 와서 클라이언트에게 제공 할 수 있습니다. 불량한 서버는 서버가 가능한 필드 값의 몬스터 목록 (예 : 500,000 개 항목)을 HTML 페이지에 포함 된 XML 섬으로 렌더링 한 다음 브라우저에서 사용자가 입력하도록 검색하는 것입니다. (a) 모든 데이터를 브라우저로 전송하는 속도가 느립니다. (b) 자바 스크립트로 검색하면 결코 DB가 검색하는 것만 큼 빠르지 않으며 (c) 귀하는 모든 데이터를 브라우저 앱 공간에 넣음으로써 사용자 컴퓨터를 폭발시킬 가능성이 높습니다. 반면에 Ajax가 서버를 호출하는지 확인하고 sure 하고 후속 쿼리 및 리턴이 매우 빠릅니다. 어리석은 일도 없습니다.

회색 영역은 어디에 있습니까?

다시 한 번 심판 전화입니다. 위에서 서버가 검색을 수행 한 다음 결과를 브라우저로 전송하는 것에 대해 이야기했습니다. 그러나 질문이 발생하면 브라우저가 양식으로 검색어를 제출하고 서버가 결과 페이지를 렌더링하게하거나 클라이언트 측 Ajax/Javascript를 사용하여 검색어를 보내고 결과를 검색 한 다음 렌더링해야합니까? 페이지 새로 고침을 피하기 위해 DIV에서? 둘 다 유효합니다. 리소스 측면에서 어느 쪽이든 실질적인 이점은 없습니다. Ajax 방식은 더 나은 사용자 경험을 제공 할 수 있지만 앱과 환경에 따라 다른 문제 (예 : 보안)가 발생할 수 있습니다.

결론

둘 다 적절하게 사용하십시오. 건축 성능과 효율성에 대한 사고와 학습에 빠지지 마십시오. 적은 데이터, 적은 시간으로 이동하십시오. 서버, 데이터베이스 및 사용자의 브라우저를로드하게됩니다.

2
b w

코드를 재사용하려면 랜딩 페이지 생성을 위해 항상 XSLT를 확인한 다음 AJAX에 대한 XML/JSON 인터페이스를 사용할 수 있습니다 (XSLT 랜딩 페이지의 XML 인터페이스 사용).

일반적으로/json/... 및/xml/... 접두사가있는 RESTful 인터페이스에서 컨텐츠 및 상호 작용이 작동하도록하고 메인 컨텐츠를 호스트하고/LT의 XSLT를 통해 마크 업으로 변환합니다.

이렇게하면 사람들이 어느 페이지 에나 착륙 할 수 있고 갑자기 AJAX 웹 사이트가 가득 찼습니다. 스파이더는 사이트를 크롤링 할 수 있으며 콘텐츠/인터페이스에 가장 중점을 두었습니다. 승리/승리처럼 보입니다.

모바일 웹 사이트에는 때때로 다른 레이아웃이 필요합니다 (iPhone 만 해당하는 사이트 만?) 여기 또는 다른 사용자 클라이언트를위한 간단한 XSLT 변환은 지금까지 수행 한 모든 것을 재사용 할 수 있습니다.

AJAX 단순화는 간단한 HTML 출력 및 탐색을 위해 설계해야합니다.

PS-XSLT 변환 서버 측 수행

1
Metalshark