[ruby-on-rails-3] 별도의 REST JSON API 서버와 클라이언트? [닫은]

Program / 글쓴이

처음부터 많은 웹 앱을 만들려고합니다. ( 개요에 대해서는 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
  • 기타 관련 도구 / 라이브러리 :

나의 결론과 추천

옵션 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 를 사용해보십시오 .