ruby-on-rails-3 python specification - Separate REST JSON API Server und Client?




9 Answers

Bei Boundless haben wir uns mit der zweiten Option beschäftigt und Tausende von Schülern darauf vorbereitet. Unser Server ist eine JSON REST API (Scala + MongoDB), und unser gesamter Client-Code wird direkt aus CloudFront bereitgestellt (dh: www.boundless.com ist nur ein Alias ​​für CloudFront).

Vorteile:

  • Modern / aufregend
  • Viel Geld für Ihr Geld: API bietet Ihnen die Basis für Ihren eigenen Webclient, mobile Clients, Zugriffe Dritter usw.
  • extrem schnelles Seitenladen / Seitenwechsel

Nachteile:

  • Nicht SEO freundlich / bereit ohne viel mehr Arbeit.
  • Erfordert erstklassige Web-Front-End-Leute, die bereit sind, mit der Realität einer Website-Erfahrung, die 70% Javascript und was das heißt, zu bewältigen sind.

Ich denke, das ist die Zukunft aller Web-Apps.

Einige Gedanken für das Web-Front-End-Leute (wo ist all die Neuheit / Herausforderung ist diese Architektur gegeben):

  • KaffeeScript. Viel einfacher, qualitativ hochwertigen Code zu produzieren.
  • Rückgrat. Gute Möglichkeit, Ihre Logik und aktive Community zu organisieren.
  • HAMLC. Haml + CoffeeScript Vorlagen => JS.
  • SASS

Wir haben ein Netzwerk für unsere Front-End-Entwicklung "Spar" (Single Page App Rocketship) entwickelt, die effektiv die Asset-Pipeline von Rails ist, die für die Entwicklung von Single-Page-Apps optimiert ist. Wir werden in den nächsten Wochen Open-Sourcing auf unserer github Seite durchführen, zusammen mit einem Blogbeitrag, in dem erklärt wird, wie man es und die gesamte Architektur im Detail nutzen kann.

AKTUALISIEREN:

In Bezug auf die Bedenken der Leute mit Backbone denke ich, dass sie überbewertet sind. Backbone ist weit mehr ein organisatorisches Prinzip als ein tiefer Rahmen. Die Website von Twitter selbst ist ein riesiges Biest von Javascript, das jeden Winkelfall von Millionen von Nutzern und Legacy-Browsern abdeckt, Tweets in Echtzeit lädt, Müll sammelt, viele Multimedia-Inhalte anzeigt usw. Von all den "reinen" js-Websites gesehen, ist Twitter der merkwürdige out. Es hat viele eindrucksvoll komplizierte Apps gegeben, die über JS geliefert werden, die sehr gut gehen.

Und Ihre Wahl der Architektur hängt ganz von Ihren Zielen ab. Wenn Sie nach dem schnellsten Weg suchen, mehrere Kunden zu unterstützen und Zugang zu guten Front-End-Talenten zu haben, ist die Investition in eine eigenständige API ein guter Weg.

jsonapi doc

Ich bin dabei, eine Reihe von Web-Apps von Grund auf neu zu erstellen. (Siehe http://50pop.com/code für einen Überblick.) Ich möchte, dass sie von vielen verschiedenen Clients aus zugänglich sind: Front-End-Websites, Smartphone-Apps, Back-End-Webservices usw. Ich möchte also wirklich ein JSON-REST-API für jeden.

Außerdem arbeite ich lieber am Backend, also träume ich davon, dass ich mich ausschließlich auf die API konzentriere und jemand anderes für die Front-End-Benutzeroberfläche einstelle, egal ob Website, iPhone, Android oder eine andere App.

Bitte helfen Sie mir zu entscheiden, welchen Ansatz ich wählen sollte:

GEMEINSAM IN SCHIENEN

Erstellen Sie eine sehr standardmäßige Rails Web-App. Führen Sie im Controller den Befehl respond_with aus, um entweder JSON oder HTML zu verwenden. Die JSON-Antwort ist dann meine API.

Pro: Viele Präzedenzfälle. Große Standards und viele Beispiele, wie man die Dinge so macht.

Con: Die API muss nicht unbedingt dieselbe sein wie die Web-App. Ich mag es nicht, wenn / dann mit Switch-Ansatz antworten. Zwei sehr unterschiedliche Dinge mischen (UI + API).

REST-SERVER + JAVASCRIPT-SCHWERER KUNDE

Richten Sie einen JSON-REST-API-Server ein. Verwenden Sie Backbone oder Ember.js für clientseitiges JavaScript, um direkt auf die API zuzugreifen und Vorlagen im Browser anzuzeigen.

Pro: Ich liebe die Trennung von API und Client. Kluge Leute sagen, dass dies der richtige Weg ist. Großartig in der Theorie. Scheint modern und aufregend.

Con: Nicht viel Präzedenzfall. Nicht viele Beispiele dafür sind gut gelungen. Öffentliche Beispiele (twitter.com) fühlen sich träge und schalten sogar von diesem Ansatz ab.

REST-SERVER + SERVER-SEITEN-HTML-CLIENT

Richten Sie einen JSON-REST-API-Server ein. Erstellen Sie einen einfachen HTML-Website-Client, der nur auf die REST-API zugreift. Weniger clientseitiges JavaScript

Pro: Ich liebe die Trennung von API und Client. Aber einfaches HTML5 zu bedienen ist ziemlich sicher und nicht kundenintensiv.

Con: Nicht viel Präzedenzfall. Nicht viele Beispiele dafür sind gut gelungen. Frameworks unterstützen dies ebenfalls nicht. Ich bin mir nicht sicher, wie ich es angehen soll.

Vor allem nach Rat aus Erfahrung suchen, nicht nur in der Theorie.




Wir haben uns beim Bau von gaug.es für # 2 entschieden. Ich arbeitete an der API (Ruby, Sinatra, etc.) und mein Geschäftspartner, Steve Smith, arbeitete am Front-End (Javascript-Client).

Vorteile:

  1. Bewegen Sie sich schnell parallel. Wenn ich vor Steve arbeitete, konnte ich weiterhin APIs für neue Funktionen erstellen. Wenn er vor mir arbeitete, konnte er die API sehr einfach fälschen und die Benutzeroberfläche erstellen.

  2. API kostenlos. Der freie Zugriff auf die Daten in Ihrer App wird schnell zum Standardmerkmal. Wenn Sie von Grund auf mit einer API beginnen, erhalten Sie diese kostenlos.

  3. Saubere Trennung. Es ist besser, Ihre App als API mit Clients zu betrachten. Sicher, der erste und wichtigste Client ist zwar ein Web-Client, aber Sie können damit andere Clients (iPhone, Android) problemlos erstellen.

Nachteile:

  1. Rückwärtskompatibilität. Dies hängt eher mit einer API zusammen als mit Ihrer direkten Frage, aber sobald Ihre API da draußen ist, können Sie sie nicht einfach brechen oder Sie brechen alle Ihre Clients zwei. Dies bedeutet nicht, dass Sie sich langsamer bewegen müssen, aber es bedeutet, dass Sie oft zwei Dinge auf einmal machen müssen. Das Hinzufügen zu der API oder zu neuen Feldern ist in Ordnung, aber das Ändern / Entfernen sollte nicht ohne Versionierung erfolgen.

Ich kann mir jetzt keine weiteren Nachteile vorstellen.

Fazit: API + JS-Client ist der Weg zu gehen, wenn Sie planen, eine API zu veröffentlichen.

PS Ich würde auch empfehlen, Ihre API vollständig zu dokumentieren, bevor Sie sie veröffentlichen. Der Prozess der Dokumentation der Gaug.es-API hat uns wirklich geholfen

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




Ich arbeite gerade daran, ein riesiges CMS von Option 1 zu Option 3 zu konvertieren, und es läuft gut. Wir haben uns dafür entschieden, die Markup-Server-Seite zu rendern, weil SEO für uns eine große Sache ist und wir wollen, dass die Websites auf Mobiltelefonen gut funktionieren.

Ich benutze node.js für das Back-End des Clients und eine Handvoll Module, um mir zu helfen. Ich bin etwas zu früh dran, aber das Fundament ist gelegt, und es geht darum, die Daten durchzugehen und sicherzustellen, dass alles richtig ist. Hier ist, was ich benutze:

  • Express für die Gründung der App.
    (https://github.com/visionmedia/express)
  • Anfrage zum Abrufen der Daten.
    (https://github.com/mikeal/request)
  • Underscore-Vorlagen, die serverseitig gerendert werden. Ich benutze diese auf dem Client wieder.
    (https://github.com/documentcloud/underscore)
  • UTML umschließt Unterschablonen, damit sie mit Express arbeiten.
    (https://github.com/mikefrey/utml)
  • Upfront sammelt Vorlagen und lässt Sie auswählen, welche an den Client gesendet werden sollen.
    (https://github.com/mrDarcyMurphy/upront)
  • Express Expose übergibt die abgerufenen Daten, einige Module und Vorlagen an das Frontend.
    (https://github.com/visionmedia/express-expose)
  • Backbone erstellt Modelle und Ansichten auf dem Front-End nach dem Schlucken der Daten, die weitergegeben wurden.
    (https://github.com/documentcloud/backbone)

Das ist der Kern des Stacks. Einige andere Module, die ich hilfreich gefunden habe:

  • Fleck (https // github.com / treck / fleck)
  • Moment (https // github.com / timrwood / Moment)
  • Stift (https // github.com / LearnBoost / Stift)
  • smoosh (https // github.com / fett / smoosh)
    ... obwohl ich grunt suche (https // github.com / cowboy / grunt)
  • Konsolenablaufverfolgung (//github.com/LearnBoost/console-trace).

Nein, ich verwende kein coffeescript.

Diese Option funktioniert wirklich gut für mich. Die Modelle auf dem Backend sind nicht existent, weil die Daten, die wir von der API erhalten, gut strukturiert sind und ich sie wörtlich an das Frontend übergebe. Die einzige Ausnahme ist unser Layout-Modell, bei dem ich ein einzelnes Attribut hinzufüge, das das Rendering intelligenter und leichter macht. Ich habe dafür keine ausgefallene Modellbibliothek benutzt, nur eine Funktion, die bei der Initialisierung das hinzufügt, was ich brauche, und sich selbst zurückgebe.

(Entschuldigung für die seltsamen Links, ich bin zu viel von einem n00b für Stack-Überlauf, damit ich das posten kann)




Ich gehe normalerweise für die zweite Option, benutze Rails, um die API zu bauen, und den Rückgrat für die JS-Sachen. Sie können sogar ein Admin-Panel kostenlos mit ActiveAdmin bekommen . Ich habe Dutzende von mobilen Apps mit dieser Art von Backend ausgeliefert. Es hängt jedoch stark davon ab, ob Ihre App interaktiv ist oder nicht.

Ich habe auf der letzten RubyDay.it eine Präsentation über diesen Ansatz gehalten : http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

Um die Reaktionsfähigkeit der zweiten Option zu erhalten, sollten Sie pajax wie Github ausprobieren.




Ich mag # 3, wenn meine Website keine 100% CRUD-Implementierung meiner Daten sein wird. Was noch passieren wird.

Ich bevorzuge Sinatra und werde die App einfach in ein paar verschiedene Rack-Apps mit unterschiedlichen Zwecken aufteilen. Ich werde eine API-spezifische Rack-App erstellen, die das umfasst, was ich für die API benötige. Dann vielleicht eine User-Rack-App, die meine Webseite präsentiert. Manchmal wird diese Version die API bei Bedarf abfragen, aber normalerweise betrifft sie nur die HTML-Site.

Ich mache mir darüber keine Sorgen und mache nur eine Persistanzschichtabfrage von der Benutzerseite, wenn ich sie brauche. Ich bin nicht allzu sehr damit beschäftigt, eine vollständige Trennung zu schaffen, da sie normalerweise unterschiedlichen Zwecken dienen.

Hier ist ein sehr einfaches Beispiel für die Verwendung mehrerer Rack-Apps. Ich habe ein schnelles jQuery-Beispiel hinzugefügt, damit Sie die API-App sehen können. Sie können sehen, wie einfach es sein kann, mit Sinatra und mehrere Rack-Apps mit unterschiedlichen Zwecken zu montieren.

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




Für atyourservice.com.cy verwenden wir serverseitig gerenderte Vorlagen für Seiten, die speziell den se-Teil abdecken. Und die API für Interaktionen nach dem Laden von Seiten verwenden. Da unser Framework MVC ist, werden alle Controller-Funktionen auf die json-Ausgabe und die html-Ausgabe dupliziert. Vorlagen sind sauber und erhalten nur ein Objekt. Dies kann in Sekunden in js-Vorlagen umgewandelt werden. Wir pflegen immer die serverseitigen Vorlagen und konvertieren sie auf Anfrage einfach in js zurück.




REST-Server + JavaScript-lastiger Client war das Prinzip, dem ich in meinen letzten Arbeiten gefolgt bin.

REST Server wurde in node.js + Express + MongoDB implementiert (sehr gute Schreibperformance) + Mongoose ODM (großartig für die Modellierung von Daten, inklusive Validierungen) + CoffeeScript (ich würde jetzt statt ES2015 gehen), was gut für mich funktionierte. Node.js ist zwar im Vergleich zu anderen möglichen serverseitigen Technologien relativ jung, hat mir aber ermöglicht, eine solide API mit integrierten Zahlungen zu schreiben.

Ich habe Ember.js als JavaScript-Framework verwendet und die meisten Anwendungslogik wurde im Browser ausgeführt. Ich habe SASS (SCSS speziell) für die CSS-Vorverarbeitung verwendet.

Ember ist ein ausgereifter Rahmen, der von einer starken Gemeinschaft getragen wird. Es ist ein sehr leistungsfähiger Rahmen mit einer Menge Arbeit, die in letzter Zeit auf die Leistung konzentriert wurde, wie die brandneue Glimmer-Rendering-Engine (inspiriert von React).

Ember Core Team entwickelt FastBoot , mit dem Sie Ihre JavaScript-Ember-Logik serverseitig (node.js) ausführen und vorgerenderten HTML-Code Ihrer Anwendung (der normalerweise im Browser ausgeführt wird) an den Benutzer senden. Es ist großartig für SEO und Benutzererfahrung, da er nicht so lange darauf wartet, dass die Seite angezeigt wird.

Ember CLI ist ein großartiges Tool, das Ihnen hilft, Ihren Code zu organisieren, und es ist gut mit der wachsenden Codebasis skalierbar. Ember hat auch ein eigenes Addon-Ökosystem und du kannst aus verschiedenen Ember-Addons wählen. Du kannst Bootstrap (in meinem Fall) oder Foundation einfach nutzen und es zu deiner App hinzufügen.

Um nicht alles über Express zu bedienen, habe ich mich dafür entschieden, nginx für die Bereitstellung von Images und JavaScript-lastigen Clients zu verwenden. Die Verwendung von Nginx-Proxy war in meinem Fall hilfreich:

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: Ich liebe die Trennung von API und Client. Kluge Leute sagen, dass dies der richtige Weg ist. Großartig in der Theorie. Scheint modern und aufregend.

Ich kann sagen, es ist auch großartig in der Praxis. Ein weiterer Vorteil der Trennung der REST-API besteht darin, dass Sie sie später für andere Anwendungen erneut verwenden können. In perfekter Welt sollten Sie in der Lage sein, dieselbe REST-API nicht nur für Webseiten, sondern auch für mobile Anwendungen zu verwenden, wenn Sie sich dazu entschließen würden, eine solche zu schreiben.

Con: Nicht viel Präzedenzfall. Nicht viele Beispiele dafür sind gut gelungen. Öffentliche Beispiele (twitter.com) fühlen sich träge und schalten sogar von diesem Ansatz ab.

Die Dinge sehen jetzt anders aus. Es gibt viele Beispiele für REST API + viele Clients, die es verwenden.




Eine sehr nette Frage und ich bin überrascht, wie ich dachte, dass dies heutzutage eine sehr häufige Aufgabe ist, so dass ich genügend Ressourcen für dieses Problem haben werde, aber es stellte sich heraus, dass es nicht wahr ist.

Meine Gedanken sind wie folgt: - Erstellen Sie einige Module, die die gemeinsame Logik zwischen den API-Controllern und HTML-Controller haben, ohne JSON oder Rendern von HTML zurückzugeben, und dieses Modul sowohl in HTML-Controller und API-Controller, dann tun, was Sie wollen, so zum Beispiel :

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



Ich persönlich bevorzuge Option (3) als Lösung. Es wird in fast allen Websites verwendet, die ein ehemaliger (bekannter Name) Arbeitgeber von mir hat. Es bedeutet, dass Sie einige Front-End-Devs bekommen können, die alles über Javascript, Browser-Quirks und was nicht wissen, um Ihr Front-End zu kodieren. Sie müssen nur wissen, "curl xyz und du wirst etwas json bekommen" und los geht's.

In der Zwischenzeit können Ihre schwergewichtigen Back-End-Jungs die JSON-Anbieter aufschlüsseln. Diese Leute müssen nicht über die Präsentation überhaupt nachdenken und sich stattdessen um flockige Backends, Timeouts, fehlerfreie Fehlerbehandlung, Datenbankverbindungspools, Threading und Skalierung usw. kümmern.

Option 3 bietet Ihnen eine gute, solide dreistufige Architektur. Es bedeutet, dass das Zeug, das Sie aus dem Frontend ausspucken, SEO-freundlich ist, mit alten oder neuen Browsern arbeiten kann (und solchen mit JS ausgeschaltet), und wenn Sie wollen, könnte es noch Javascript-Client-seitiges Templating sein Dinge wie alte Browser / googlebot mit statischem HTML behandeln, aber JS-basierte dynamische Erfahrungen an Leute senden, die den neuesten Chrome-Browser verwenden oder was auch immer.

In allen Fällen, in denen ich Option 3 gesehen habe, handelt es sich um eine benutzerdefinierte Implementierung von PHP, die nicht besonders zwischen Projekten übertragen werden kann, ganz zu schweigen von Open Source-Land. Ich denke, PHP wurde vielleicht kürzlich durch Ruby / Rails ersetzt, aber die gleiche Sache ist immer noch wahr.

FWIW, $ current_employer könnte an einigen wichtigen Stellen Option 3 verwenden. Ich bin auf der Suche nach einem guten Ruby-Framework, in dem ich etwas aufbauen kann. Ich bin mir sicher, dass ich eine Ladung Edelsteine ​​zusammenkleben kann, aber ich würde ein einzelnes Produkt bevorzugen, das allgemein ein Templating, Curling, optionale Authentifizierung, optionale Memcache / Nosql verbundene Caching-Lösung bietet. Da finde ich nichts Konsequentes :-(




Related