처음부터 많은 웹 앱을 만들려고합니다. ( 개요에 대해서는 http://50pop.com/code 를 참조하십시오 .) 프론트 엔드 웹 사이트, 스마트 폰 앱, 백엔드 웹 서비스 등 다양한 클라이언트에서 액세스 할 수 있기를 바랍니다. 각각에 대한 JSON REST API.

또한 백엔드 작업을 선호하므로 웹 사이트, iPhone, Android 또는 기타 앱에 관계없이 순수하게 API에 집중하고 프론트 엔드 UI를 만들기 위해 다른 사람을 고용하는 것을 좋아합니다.

어떤 방법을 사용해야하는지 결정하도록 도와주세요.

철도에 함께

매우 표준적인 Rails 웹앱을 만드십시오. 컨트롤러에서 respond_with 스위치를 수행하여 JSON 또는 HTML을 제공하십시오. JSON 응답은 내 API입니다.

찬성 : 많은 선례. 이런 식으로 일을하는 훌륭한 표준 및 많은 예.

단점 : API를 웹앱과 동일하게 만들 필요는 없습니다. if / then respond_with 스위치 방식을 좋아하지 않습니다. 두 가지 매우 다른 것들을 혼합 (UI + API).

REST 서버 + JAVASCRIPT-HEAVY 클라이언트

JSON 전용 REST API 서버를 작성하십시오. 클라이언트 측 JavaScript에 Backbone 또는 Ember.js를 사용하여 API에 직접 액세스하여 브라우저에 템플릿을 표시하십시오.

Pro : API와 클라이언트의 분리를 좋아합니다. 똑똑한 사람들은 이것이 갈 길이라고 말합니다. 이론적으로는 훌륭합니다. 최첨단과 흥미 진진한 것 같습니다.

단점 : 많은 선례가 없습니다. 이것의 많은 예가 잘 이루어지지 않았습니다. 공개 예 (twitter.com)는 느리게 느껴지고 심지어이 접근법에서 벗어나고 있습니다.

REST 서버 + 서버 측 HTML 클라이언트

JSON 전용 REST API 서버를 작성하십시오. REST API에만 액세스하는 기본 HTML 웹 사이트 클라이언트를 작성하십시오. 클라이언트 측 JavaScript가 적습니다.

Pro : API와 클라이언트의 분리를 좋아합니다. 그러나 평범한 HTML5를 제공하는 것은 매우 무모하고 클라이언트 집약적이지 않습니다.

단점 : 많은 선례가 없습니다. 이것의 많은 예가 잘 이루어지지 않았습니다. 프레임 워크도이를 지원하지 않습니다. 어떻게 접근 해야할지 모르겠습니다.

특히 이론이 아닌 경험으로부터 조언을 구합니다.

에서 무한한 , 우리는 옵션 # 2와 함께 깊은 갔어요 학생들의 수천을 출시했다. Google 서버는 JSON REST API (Scala + MongoDB)이며 모든 클라이언트 코드는 CloudFront에서 바로 제공됩니다 (예 : www.boundless.com은 CloudFront의 별칭 임).

장점 :

• 최첨단 / 흥미
• 비용 절감 : API는 웹 클라이언트, 모바일 클라이언트, 타사 액세스 등에 대한 기초를 제공합니다.
• 매우 빠른 사이트 로딩 / 페이지 전환

단점 :

• 더 많은 작업이 없으면 SEO에 익숙하지 않습니다.
• 70 % 자바 스크립트 인 사이트 경험의 현실과 그 의미에 대처할 준비가되어있는 최고 수준의 웹 프런트 엔드 직원이 필요합니다.

나는 이것이 모든 웹 응용 프로그램의 미래라고 생각합니다.

웹 프론트 엔드 사람들에 대한 몇 가지 생각 (새로운 아키텍처 / 챌린지에이 아키텍처가 제공되는 곳) :

• CoffeeScript. 고품질 코드를 훨씬 쉽게 생성 할 수 있습니다.
• 등뼈. 논리와 활동적인 커뮤니티를 구성하는 좋은 방법입니다.
• HAMLC. Haml + CoffeeScript 템플릿 => JS.
• SASS

우리는 단일 페이지 앱 개발을 위해 조정 된 Rails의 자산 파이프 라인 인 'Spar'(Single Page App Rocketship)이라는 프론트 엔드 개발을위한 하네스를 구축했습니다. 우리는 다음 몇 주 안에 github 페이지에서 오픈 소싱을 할 것이며 , 사용법과 전반적인 아키텍처를 자세히 설명하는 블로그 게시물과 함께 제공 될 것입니다.

최신 정보:

Backbone에 대한 사람들의 우려와 관련하여 나는 그들이 과대 평가 된 것으로 생각합니다. 백본은 심오한 틀보다 훨씬 조직적인 원칙입니다. 트위터 사이트 자체는 수백만 명의 사용자 및 레거시 브라우저에서 모든 코너 케이스를 다루는 거대한 자바 스크립트입니다. 보시다시피 트위터가 이상합니다. JS를 통해 제공되는 매우 복잡한 앱이 많이 있습니다.

아키텍처 선택은 전적으로 목표에 달려 있습니다. 여러 고객을 지원할 수있는 가장 빠른 방법을 찾고 우수한 프론트 엔드 인재를 확보하려면 독립형 API에 투자하는 것이 좋습니다.

잘 부탁했다. +1. 확실히 이것은 미래의 유용한 참고 자료입니다. 또한 @Aaron과 다른 사람들은 토론에 가치를 더했습니다. Ruby와 마찬가지로이 질문은 다른 프로그래밍 환경에도 동일하게 적용됩니다.

처음 두 옵션을 사용했습니다. 첫 번째는 수많은 응용 프로그램을위한 것이고 두 번째는 오픈 소스 프로젝트를 위한 것입니다.

옵션 1

이것은 의심 할 여지없이 가장 인기있는 것입니다. 그러나 구현이 매우 http-ish라는 것을 알았습니다. 모든 API의 초기 코드는 요청 객체를 처리합니다. 따라서 API 코드는 순수한 루비 / 파이썬 / 기타 언어 코드 이상입니다.

옵션 2

나는 항상 이것을 좋아했다.

이 옵션은 HTML이 서버에서 런타임으로 생성되지 않음을 의미합니다. 이것이 옵션 2와 옵션 3의 차이점입니다. 그러나 빌드 스크립트를 사용하여 정적 html로 빌드됩니다. 클라이언트 측에로드되면 이러한 HTML은 API 서버를 JS API 클라이언트로 호출합니다.

• 우려의 분리는 큰 이점입니다. 또한 원하는대로 백엔드 전문가가 백엔드 API를 구현하고 프레임 워크 / http 요청 코드에 대한 걱정없이 일반 언어 코드처럼 쉽게 테스트 할 수 있습니다.

• 이것은 프론트 엔드 쪽에서 들리는 것만 큼 어렵지 않습니다. 클라이언트 측 템플릿 또는 MVC에서 API 호출 및 결과 데이터 (주로 json)를 사용할 수 있습니다.

• 서버 쪽 처리가 적습니다. 그것은 당신이 필수 하드웨어 / 저렴한 서버를 갈 수 있음을 의미합니다.

• 레이어를 독립적으로 테스트하기 쉽고 API 문서를 쉽게 생성 할 수 있습니다.

단점이 있습니다.

• 많은 개발자들이이 기술을 이해하고 이해하기 어렵습니다. 따라서 아키텍처가 비판을받을 수 있습니다.

• i18n / l10n은 단단합니다. HTML은 기본적으로 생성 시간이 정적으로 생성되므로 지원되는 언어 당 여러 빌드가 필요합니다 (필수 나쁜 것은 아닙니다). 그러나 그럼에도 불구하고 l10n / i18n 주변에 코너 케이스가있을 수 있으므로주의해야합니다.

옵션 3

이 경우 백엔드 코딩은 두 번째 옵션과 동일해야합니다. 옵션 2의 대부분의 포인트도 여기에 적용됩니다.

웹 페이지는 서버 측 템플릿을 사용하여 런타임으로 렌더링됩니다. 이를 통해보다 확립 된 / 수용된 기술로 i18n / l10n을 훨씬 쉽게 사용할 수 있습니다. 사용자, 언어, 통화 등과 같은 페이지 렌더링에 필요한 일부 필수 컨텍스트에 대해 하나의 HTTP 호출이 적을 수 있습니다. 따라서 렌더링시 서버 측 처리가 증가하지만 API 서버에 대한 http 호출이 줄어들면 가능할 수 있습니다.

이제 페이지가 서버에서 서버로 렌더링되고 프런트 엔드가 프로그래밍 환경과 더 밀접하게 연결되었습니다. 많은 응용 프로그램에서는 고려되지 않을 수도 있습니다.

트위터 사례

내가 이해하는 것처럼 Twitter는 서버에서 초기 페이지 렌더링을 수행 할 수 있지만 페이지 업데이트의 경우 DOM을 조작하기위한 API 호출 및 클라이언트 측 템플릿이 여전히 있습니다. 따라서 이러한 경우 유지 관리해야 할 이중 템플릿이있어 오버 헤드와 복잡성이 추가됩니다. 트위터와 달리 모든 사람이이 옵션을 감당할 수있는 것은 아닙니다.

우리의 프로젝트 스택

파이썬을 사용합니다. REST 대신 JsonRPC 2.0을 사용합니다. 나는 여러 가지 이유로 JsonRPC에 대한 아이디어를 좋아하지만 REST를 제안합니다. 나는 아래 도서관을 사용합니다. 옵션 2/3을 고려하는 사람은 유용 할 수 있습니다.

• API 서버 : Python 빠른 웹 마이크로 프레임 워크 -Flask
• 프론트 엔드 서버 : Nginx
• 클라이언트 측 MVC : Knockout.js
• 기타 관련 도구 / 라이브러리 :
  • jquery
  • 돈 통화에 대한 Accounting.js
  • Webshim : 크로스 브라우저 폴리 필
  • 감독 : 고객 측 라우팅
  • sphc : HTML 생성

나의 결론과 추천

옵션 3 !.

모두 말했다, 나는 옵션 2를 성공적으로 사용했지만 이제는 단순화를 위해 옵션 3에 기대어 있습니다. 빌드 스크립트를 사용하여 정적 HTML 페이지를 생성하고 정적 페이지 서비스를 전문으로하는 초고속 서버 중 하나에서 제공하는 것은 매우 유혹적입니다 (옵션 2).

gaug.es를 만들 때 # 2를 선택했습니다. API (ruby, sinatra 등)에서 일했고 비즈니스 파트너 인 Steve Smith가 프론트 엔드 (javascript client)에서 일했습니다.

장점 :

1. 병렬로 빠르게 움직입니다. Steve보다 앞서 작업하면 새로운 기능을위한 API를 계속 만들 수있었습니다. 그가 저보다 앞서 일했다면 API를 아주 쉽게 가짜로 만들고 UI를 만들 수있었습니다.

2. 무료 API. 앱의 데이터에 공개적으로 액세스하는 것이 표준 기능이되고 있습니다. 처음부터 API로 시작하면 무료로 얻을 수 있습니다.

3. 깨끗한 분리. 앱을 클라이언트의 API로 생각하는 것이 좋습니다. 물론, 가장 중요한 첫 번째 클라이언트는 웹 클라이언트 일 수 있지만 다른 클라이언트 (iPhone, Android)를 쉽게 만들 수 있도록 설정합니다.

단점 :

1. 이전 버전과의 호환성. 이것은 직접적인 질문보다 API와 더 관련이 있지만 일단 API가 나오면 API를 중단하거나 모든 클라이언트를 중단시킬 수 없습니다. 그렇다고 천천히 움직여야한다는 의미는 아니지만 종종 두 가지를 한 번에 작동시켜야한다는 의미입니다. API 또는 새 필드에 추가하는 것은 좋지만 버전 관리없이 변경 / 제거를 수행해서는 안됩니다.

지금은 더 이상 단점을 생각할 수 없습니다.

결론 : API 공개를 계획중인 경우 API + JS 클라이언트가 사용됩니다.

추신 : 또한 API를 공개하기 전에 API를 완전히 문서화하는 것이 좋습니다. Gaug.es API를 문서화하는 프로세스는 실제로

http://get.gaug.es/documentation/api/

저는 2 번과 3 번 노선을 선호합니다. 주로 # 1이 우려의 분리를 위반하고 모든 종류의 것들을 혼합하기 때문입니다. 결국 HTML 페이지 등이 일치하지 않는 API 엔드 포인트가 필요하다는 것을 알게 될 것이며 동일한 코드베이스에서 HTML 및 JSON 엔드 포인트가 혼합되어 있습니다. 그것은 비록 MVP라도, 당신이 구원받을 가치가없는 너무 지저분하기 때문에 결국 그것을 다시 써야 할 것입니다.

# 2 또는 # 3을 사용하면 (대부분) 동일하게 작동하는 API를 완전히 가질 수 있습니다. 이것은 큰 유연성을 제공합니다. 아직 Backbone / ember / whatever / etc.js에서 100 % 판매되지 않았습니다. 나는 그것이 훌륭하다고 생각하지만, 트위터에서 볼 때 이것은 최적이 아닙니다. 그러나 ... Twitter는 회사의 거대한 짐승이며 수억 명의 사용자가 있습니다. 따라서 모든 개선은 다양한 사업부의 다양한 영역에 대한 수익에 큰 영향을 줄 수 있습니다. 나는 속도보다 결정에 더 많은 것이 있다고 생각하며 그것들을 우리에게 알려주지 않습니다. 그러나 그것은 단지 내 의견입니다. 그러나 저는 백본과 경쟁 업체를 할인하지 않습니다. 이 앱은 사용하기에 훌륭하고 매우 깨끗하며 반응이 매우 뛰어납니다 (대부분의 경우).

세 번째 옵션에는 유효한 매력도 있습니다. 여기에서 파레토 원칙 (80/20 규칙)을 따르고 서버에서 주 마크 업의 20 % (또는 그 반대)를 렌더링 한 다음 멋진 JS 클라이언트 (백본 등)를 실행합니다. . JS 클라이언트를 통해 REST API와 100 % 통신하지 않을 수 있지만, 더 나은 경험을 제공하기 위해 필요한 경우 일부 작업을 수행하게됩니다.

나는 이것이 "의존하는"종류의 문제 중 하나라고 생각하며, 당신이하고있는 일, 누구에게 봉사하고 있는지, 그리고 어떤 종류의 경험을 받기를 원하는지에 대한 대답은 "의존적이다"라고 생각합니다. 나는 당신이 2 또는 3 또는 그 중에서 하이브리드를 결정할 수 있다고 생각합니다.

현재 거대한 CMS를 옵션 1에서 옵션 3으로 변환하려고 노력하고 있습니다. SEO는 우리에게 큰 일이기 때문에 마크 업을 서버 측으로 렌더링하기로 결정했으며, 사이트가 휴대 전화에서 잘 작동하기를 원합니다.

나는 클라이언트의 백엔드에 node.js를 사용하고 있으며 나를 돕기 위해 소수의 모듈을 사용하고 있습니다. 나는 프로세스 초기에 있지만 기초가 설정되었으며 모든 것이 올바르게 렌더링되도록 데이터를 검토해야합니다. 내가 사용하는 것은 다음과 같습니다.

• 앱의 기초를 표현하십시오.
  (https://github.com/visionmedia/express)
• 데이터 반입 요청.
  (https://github.com/mikeal/request)
• 서버 측으로 렌더링되는 밑줄 템플릿. 나는 이것을 클라이언트에서 재사용합니다.
  (https://github.com/documentcloud/underscore)
• UTML은 밑줄의 템플릿을 감싸서 Express에서 작동하도록합니다.
  (https://github.com/mikefrey/utml)
• Upfront는 템플릿을 수집하고 클라이언트에게 보낼 템플릿을 선택하도록합니다.
  (https://github.com/mrDarcyMurphy/upfront)
• Express Expose는 페치 된 데이터, 일부 모듈 및 템플리트를 프론트 엔드로 전달합니다.
  (https://github.com/visionmedia/express-expose)
• 백본은 전달 된 데이터를 삼킨 후 프런트 엔드에서 모델과 뷰를 만듭니다.
  (https://github.com/documentcloud/backbone)

이것이 스택의 핵심입니다. 내가 찾은 다른 모듈들 :

• fleck (https // github.com / trek / fleck)
• 순간 (https // github.com / timrwood / moment)
• 스타일러스 (https // github.com / LearnBoost / stylus)
• smoosh (https // github.com / fat / smoosh)
  … 그런데보고 있지만 (https // github.com / cowboy / grunt)
• 콘솔 추적 (//github.com/LearnBoost/console-trace).

아니요, 커피 스크립트를 사용하지 않습니다.

이 옵션은 정말 잘 작동합니다. 백엔드 모델은 존재하지 않습니다. API에서 얻은 데이터가 잘 구조화되어 있고이를 프론트 엔드로 그대로 전달하기 때문입니다. 유일한 예외는 렌더링을 더 똑똑하고 가볍게 만드는 단일 속성을 추가하는 레이아웃 모델입니다. 나는 그것을 위해 멋진 모델 라이브러리를 사용하지 않았습니다. 초기화에 필요한 것을 추가하고 자체를 반환하는 함수 일뿐입니다.

(이상한 링크에 대해 죄송합니다. 스택 오버플로로 인해 n00b가 너무 많아서 많은 것을 게시 할 수 없습니다)

다음과 같은 # 3 변형을 사용합니다. JSON 전용 REST API 서버를 만듭니다. HTML 웹 사이트 서버를 만드십시오. HTML 웹 서버는 변형에서와 같이 REST API 서버에 대한 클라이언트가 아닙니다. 대신 두 사람은 동료입니다. 표면 아래에는 두 서버에 필요한 기능을 제공하는 내부 API가 있습니다.

우리는 어떤 선례도 알지 못하기 때문에 실험적입니다. 지금까지 (베타에 진입하려고) 꽤 잘 작동했습니다.

저는 보통 Rails를 사용하여 API를 빌드하고 JS를위한 백본을 사용하는 두 번째 옵션을 사용합니다. ActiveAdmin을 사용하여 무료로 관리자 패널을 얻을 수도 있습니다 . 이런 종류의 백엔드와 함께 수십 개의 모바일 앱을 제공했습니다. 그러나 앱이 대화 형인지 아닌지에 따라 크게 다릅니다.

마지막 RubyDay.it 에서이 접근법에 대한 프레젠테이션을했습니다 : http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

세 번째 옵션의 경우 두 번째 옵션의 응답 성을 얻으려면 Github과 마찬가지로 pajax 를 사용해보십시오 .

나는 3 개월 동안 약 2 개월 동안 프로젝트에 대해 두 번째 접근 방식을 취합니다. 앞면에 backbone.js가있는 RESTful API 서버 측을 사용합니다. Handlebars.js는 템플릿을 관리하고 jQuery는 AJAX 및 DOM 조작을 처리합니다. 오래된 브라우저와 검색 스파이더의 경우 서버 측 렌더링으로 넘어갔지 만 Mozilla Rhino를 사용하는 핸들 바 프론트 엔드와 동일한 HTML 템플릿을 사용하고 있습니다.

우리는 여러 가지 이유로이 접근법을 선택했지만 아직 광범위하게 입증되지 않았기 때문에 약간 위험하다는 것을 잘 알고 있습니다. 모두 똑같이, 지금까지 모든 것이 순조롭게 진행되고 있습니다.

지금까지 우리는 하나의 API로 작업했지만, 다음 단계에서는 두 번째 API로 작업 할 것입니다. 첫 번째는 많은 양의 데이터를위한 것이고 두 번째는 API를 통해 CMS처럼 작동합니다.

이 두 가지 프로젝트가 서로 완전히 독립적으로 작동하도록하는 것이이 인프라를 선택하는 데있어 중요한 고려 사항이었습니다. 의존성없이 다른 독립적 인 리소스를 mashup하는 아키텍처를 찾고 있다면이 방법을 살펴볼 가치가 있습니다.

나는 루비 사람이 아니기 때문에 다른 접근법에 대해서는 언급 할 수 없다. 때때로 위험을 감수해도 괜찮습니다. 다른 경우에는 안전하게 플레이하는 것이 좋습니다. 당신은 프로젝트의 유형에 따라 스스로 행동 할 것입니다.

당신의 선택에 행운을 빕니다. 다른 사람들도 공유하는 것을보고 싶어했습니다.

내 웹 사이트가 내 데이터의 100 % CRUD 구현이 아닌 경우 # 3이 마음에 듭니다. 아직 일어나지 않았습니다.

나는 sinatra를 선호하며 다른 목적으로 응용 프로그램을 몇 가지 다른 랙 응용 프로그램으로 나눕니다. API에 필요한 것을 다룰 API 전용 랙 앱을 만들겠습니다. 그런 다음 내 웹 페이지를 표시하는 사용자 랙 응용 프로그램 일 수 있습니다. 때로는 해당 버전이 필요한 경우 API를 쿼리하지만 일반적으로 html 사이트와 관련이 있습니다.

걱정하지 않고 필요한 경우 사용자 측에서 지속성 계층 쿼리를 수행하십시오. 나는 일반적으로 다른 목적을 달성하기 때문에 완전한 분리를 만드는 것에 지나치게 걱정하지 않습니다.

다음은 여러 랙 앱을 사용 하는 매우 간단한 예입니다. API 앱에 충돌하는 것을 볼 수 있도록 빠른 jquery 예제를 추가했습니다. Sinatra를 사용하여 다양한 목적으로 여러 랙 앱을 마운트하는 것이 얼마나 간단한 지 알 수 있습니다.

https://github.com/dusty/multi-rack-app-app

여기에 몇 가지 훌륭한 답변이 있습니다-분명히 # 2 또는 # 3을 추천합니다-분리는 개념적으로는 좋지만 실제로도 좋습니다.

API에서로드 및 트래픽 패턴과 같은 사항을 예측하기 어려울 수 있으며 API를 독립적으로 제공하는 고객은 프로비저닝 및 확장 시간이 더 쉽다는 것을 알게됩니다. 휴먼 웹 액세스 패턴으로 해결해야 할 경우 덜 쉽습니다. 또한 API 사용량이 웹 클라이언트보다 훨씬 빠르게 확장되어 노력을 지시 할 위치를 확인할 수 있습니다.

# 2와 # 3 사이는 실제로 목표에 달려 있습니다. # 2는 아마도 웹앱의 미래 일 것입니다.하지만 그 채널이 많은 것 중 하나 일 경우 더 간단한 것을 원할 것입니다!

atyourservice.com.cy의 경우, 특히 해당 부분을 다루기 위해 페이지에 서버 측 렌더링 템플릿을 사용합니다. 그리고 페이지로드 후 상호 작용에 API를 사용합니다. 우리의 프레임 워크는 MVC이기 때문에 모든 컨트롤러 기능은 json 출력과 html 출력에 복제됩니다. 템플릿은 깨끗하고 객체 만받습니다. 몇 초 만에 js 템플릿으로 변환 할 수 있습니다. 우리는 항상 서버 측 템플릿을 유지 관리하고 요청시 js로 다시 변환합니다.

동형 렌더링 및 점진적 향상. 옵션 3에서 당신이 향한 것으로 생각됩니다.

동형 렌더링 은 클라이언트 측 코드에서 사용하는 것과 동일한 템플릿을 사용하여 마크 업 서버 측을 생성하는 것을 의미합니다. 우수한 서버 측 및 클라이언트 측 구현으로 템플릿 언어를 선택하십시오. 사용자를 위해 완전히 구워진 HTML을 만들어서 아래로 보냅니다. 캐싱도 사용하십시오.

점진적 향상 이란 모든 리소스를 다운로드하고 클라이언트 기능을 확인할 수있게되면 클라이언트 측 실행 및 렌더링 및 이벤트 수신을 시작한다는 의미입니다. 접근성 및 이전 버전과의 호환성을 위해 가능하면 클라이언트가없는 기능적인 기능으로 대체합니다.

예, 물론이 앱 기능을위한 독립형 JSON API를 작성하십시오. 그러나 정적 HTML 문서처럼 잘 작동하는 것에 대해 JSON API를 작성하기까지는 가지 마십시오.

REST 서버 + JavaScript가 많은 클라이언트는 최근 작업에서 따라온 원칙입니다.

REST 서버는 node.js + Express + MongoDB (매우 훌륭한 쓰기 성능) + Mongoose ODM (모델링 데이터에 적합, 검증 포함) + CoffeeScript (지금 대신 ES2015로 갈 것입니다)에서 구현되었습니다. Node.js는 가능한 다른 서버 측 기술에 비해 상대적으로 젊을 수 있지만 지불이 통합 된 견고한 API를 작성할 수있었습니다.

Ember.js 를 JavaScript 프레임 워크로 사용 했으며 대부분의 애플리케이션 로직이 브라우저에서 실행되었습니다. CSS 사전 처리에 SASS (특히 SCSS)를 사용했습니다 .

Ember는 강력한 커뮤니티의 지원을받는 성숙한 프레임 워크입니다. 최신 Glimmer 렌더링 엔진 (React에서 영감을 얻은) 과 같이 성능에 초점을 맞춘 많은 작업이있는 매우 강력한 프레임 워크입니다 .

Ember Core Team은 FastBoot 를 개발 하는 중입니다.이를 통해 서버 측 (특히 node.js)에서 JavaScript Ember 로직을 실행하고 사전 렌더링 된 애플리케이션의 HTML (일반적으로 브라우저에서 실행 됨)을 사용자에게 보낼 수 있습니다. 페이지가 표시 될 때까지 기다리지 않기 때문에 SEO 및 사용자 경험에 좋습니다.

Ember CLI 는 코드를 구성하는 데 도움이되는 훌륭한 도구이며 코드베이스가 커짐에 따라 확장 할 수있었습니다. Ember는 또한 자체 애드온 생태계를 가지고 있으며 다양한 Ember Addons 중에서 선택할 수 있습니다 . 부트 스트랩 (필자의 경우) 또는 Foundation을 쉽게 잡고 앱에 추가 할 수 있습니다.

Express를 통해 모든 것을 제공하지 않기 위해 이미지와 JavaScript가 많은 클라이언트를 제공하기 위해 nginx를 사용하기로 선택했습니다. 내 경우에는 nginx 프록시 사용이 도움이되었습니다.

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Pro : API와 클라이언트의 분리를 좋아합니다. 똑똑한 사람들은 이것이 갈 길이라고 말합니다. 이론적으로는 훌륭합니다. 최첨단과 흥미 진진한 것 같습니다.

나는 또한 그것이 실제로 훌륭하다고 말할 수 있습니다. REST API 분리의 또 다른 장점은 나중에 다른 애플리케이션에서 재사용 할 수 있다는 것입니다. 완벽한 세상에서는 웹 페이지뿐만 아니라 모바일 응용 프로그램을 작성하기로 결정한 경우 동일한 REST API를 사용할 수 있어야합니다.

단점 : 많은 선례가 없습니다. 이것의 많은 예가 잘 이루어지지 않았습니다. 공개 예 (twitter.com)는 느리게 느껴지고 심지어이 접근법에서 벗어나고 있습니다.

상황이 달라 보입니다. REST API를 수행하는 많은 예제와이를 사용하는 많은 클라이언트가 있습니다.

UI와 비즈니스 로직을 분리하는 좋은 방법을 제공했기 때문에 Infiniforms 의 옵션 # 2 아키텍처로 가기로 결정했습니다 .

이것의 장점은 API 서버가 웹 서버와 독립적으로 확장 될 수 있다는 것입니다. 클라이언트가 여러 개인 경우 일부 클라이언트는 전화 / 태블릿 또는 데스크톱 기반이므로 웹 서버는 웹 서버와 같은 정도로 확장 할 필요가 없습니다.

이 접근 방식은 특히 사용자 자신의 API를 사용하여 웹 사이트에 대한 모든 기능을 제공하는 경우 사용자에게 API를 열 수있는 좋은 기반을 제공합니다.

매우 좋은 질문이며 요즘 이것이 매우 일반적인 작업이라고 생각하여 놀랐습니다.이 문제에 대한 많은 리소스가 있지만 사실이 아닙니다.

내 생각은 다음과 같습니다 : -json 을 반환하거나 HTML을 렌더링 하지 않고 API 컨트롤러와 HTML 컨트롤러 사이에 공통 논리를 갖는 모듈을 만들고 HTML 컨트롤러와 API 컨트롤러 모두 에이 모듈을 포함 시킨 다음 원하는대로하십시오. 예를 들어 :

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end

우리는 Sinatra를 기본, ActiveRecord / Postgress 등으로 사용하여 페이지 경로 (슬림 템플릿)를 제공하여 웹 응용 프로그램에서 사용할 수있는 REST API를 노출시키는 하이브리드 접근 방식을 사용했습니다. 초기 개발에서 선택 옵션 채우기와 같은 작업은 슬림 템플릿으로의 도우미 렌더링을 통해 수행되지만 프로덕션에 접근함에 따라 AJAX 호출을 위해 REST API에 대한 AJAX 호출을 위해 스왑 아웃되어 페이지로드 속도 등에 관심을 갖기 시작합니다.

Slim에서 렌더링하기 쉬운 것들이 그런 식으로 처리되고 물건 (jQuery.Validation submitHandler등에서 양식 POST 데이터를 수신하는 양식 채우기 는 모두 AJAX입니다)

테스트는 문제입니다. 지금은 JSON 데이터를 Rack :: Test POST test에 전달하려고 시도했습니다 .

개인적으로 솔루션 (3)을 선호합니다. 그것은 이전의 (가구 이름) 고용주가 가진 거의 모든 사이트에서 사용됩니다. 즉, 자바 스크립트, 브라우저 문제 및 프런트 엔드를 코딩하지 않는 것에 대해 모두 알고있는 프런트 엔드 개발자를 얻을 수 있습니다. 그들은 "curl xyz를 알고 있으면 json을 얻을 수 있습니다."

한편, 무거운 백엔드 직원은 Json 공급자를 코딩 할 수 있습니다. 이 사람들은 프레젠테이션에 대해 전혀 생각할 필요가 없으며, 대신 백엔드, 시간 초과, 우아한 오류 처리, 데이터베이스 연결 풀, 스레딩 및 확장 등에 대해 걱정할 필요가 없습니다.

옵션 3은 우수하고 견고한 3 계층 아키텍처를 제공합니다. 프론트 엔드에서 뱉어 낸 물건은 SEO 친화적이며 오래된 브라우저 또는 새로운 브라우저 (JS가 꺼져있는 브라우저)에서 작동하도록 만들 수 있으며 원하는 경우 여전히 자바 스크립트 클라이언트 측 템플릿이 될 수 있습니다. 정적 HTML로 오래된 브라우저 / Googlebot을 처리하는 것과 같은 작업을 수행하지만 최신 Chrome 브라우저를 사용하는 사람들에게 JS 빌드 동적 환경을 보냅니다).

모든 경우에 옵션 3을 보았을 때 프로젝트간에 특히 양도 할 수없는 일부 PHP의 사용자 정의 구현이었습니다. 좀 더 최근에 PHP가 Ruby / Rails로 대체되었을 수도 있지만 같은 종류의 것이 여전히 사실입니다.

FWIW, $ current_employer는 몇 가지 중요한 장소에서 옵션 3과 관련이 있습니다. 무언가를 만들 수있는 좋은 루비 프레임 워크를 찾고 있습니다. 나는 많은 보석을 함께 붙일 수 있다고 확신하지만 템플릿, '컬링', 선택적 인증, 선택적 memcache / nosql 연결 캐싱 솔루션을 광범위하게 제공하는 단일 제품을 선호합니다. 거기에 일관성있는 것을 찾지 못했습니다 :-(

Rails에서 JSON API를 빌드하는 것이 첫 번째 클래스입니다. JSONAPI :: Resources gem은 http://jsonapi.org 사양 API에 대해 많은 노력을 기울 입니다.