ruby-on-rails tutorial - Ember.js oder Backbone.js für Restful-Backend





deutsch example (4)


Entgegen der landläufigen Meinung ist Ember.js kein "schwergewichtiger Ansatz" für Backbone.js. Sie sind verschiedene Arten von Werkzeugen, die auf ganz andere Endprodukte abzielen. Der Sweet Spot von Ember ist eine Anwendung, bei der der Benutzer die Anwendung über einen längeren Zeitraum, vielleicht den ganzen Tag, geöffnet hält und Interaktionen mit den Ansichten oder zugrunde liegenden Daten der Anwendung tiefgreifende Änderungen in der Ansichtshierarchie auslösen. Ember ist größer als Backbone, aber dank Expires , Cache-Control dies nur beim ersten Laden wichtig. Nach zwei Tagen täglicher Nutzung werden diese zusätzlichen 30k von Datenübertragungen überschattet, früher, wenn es sich bei Ihren Inhalten um Bilder handelt.

Backbone ist ideal für Anwendungen mit einer kleinen Anzahl von Zuständen, bei denen die Ansichtshierarchie relativ flach bleibt und der Benutzer dazu neigt, selten oder für kürzere Zeiträume auf die App zuzugreifen. Der Backbone-Code bleibt kurz und bündig, da er davon ausgeht, dass die Daten, die das DOM unterstützen, verworfen werden und beide Elemente im Speicher gesammelt werden: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Die kleinere Größe von Backbone macht es auch besser für kurze Interaktionen geeignet.

Die Apps, die Benutzer in beiden Frameworks schreiben, spiegeln diese Verwendung wider: Ember.js-Apps umfassen das Web-Dashboard von Square , Zendesk (zumindest die Agenten- / Ticketing-Oberfläche) und Groupons Scheduler : alle Anwendungen, in denen ein Benutzer den ganzen Tag arbeiten kann.

Backbone-Apps konzentrieren sich eher auf kurze oder gelegentliche Interaktionen, die oft nur kleine Abschnitte einer größeren statischen Seite sind: airbnb , Khan Academy , Foursquares Karte und Listen .

Sie können Backbone verwenden, um die Arten von Anwendungen zu erstellen, die Ember als Ziel hat (z. B. Rdio ), indem a) der Anwendungscode erhöht wird, um Probleme wie Speicherlecks oder Zombie-Ereignisse zu vermeiden (Ich empfehle diesen Ansatz nicht persönlich) oder b) durch Hinzufügen von Drittanbieter-Bibliotheken wie backbone.marionette oder Coccyx - es gibt viele dieser Bibliotheken, die alle versuchen, ähnliche überlappende Funktionalität bereitzustellen, und Sie werden wahrscheinlich am Ende Ihr eigenes Framework zusammenbauen, das größer ist und mehr Code benötigt als wenn du gerade Ember benutzt hättest.

Letztendlich hat die Frage "Was zu verwenden" zwei Antworten.

Erstens: "Was sollte ich im Allgemeinen in meiner Karriere verwenden?": Beides, genau so, wie Sie am Ende lernen werden, spezifische Werkzeuge für die Arbeit, die Sie in Zukunft tun werden. Du würdest niemals "Backbone oder D3?" Fragen; "Backbone oder Ember" ist eine ebenso alberne Frage.

Zweitens: "Was soll ich speziell für mein nächstes Projekt verwenden?": Kommt auf das Projekt an. Beide kommunizieren gleichermaßen einfach mit einem Rails-Server. Wenn Ihr nächstes Projekt eine Mischung von Seiten umfasst, die vom Server mit sogenannten "Inseln der Reichhaltigkeit" erzeugt werden, die von JavaScript zur Verfügung gestellt werden, verwenden Sie Backbone. Wenn Ihr nächstes Projekt die gesamte Interaktion in die Browserumgebung überträgt, verwenden Sie Ember.

Ich weiß bereits, dass ember.js im Gegensatz zu backbone.js eine schwerere Methode ist. Ich lese viele Artikel über beides.

Ich frage mich, welches Framework als Frontend für ein Rails Rest Backend einfacher funktioniert. Für backbone.js habe ich verschiedene Ansätze gesehen, ein Rest-Backend zu nennen. Für ember scheint es, dass ich einige weitere Bibliotheken wie "Daten" oder "Ressourcen" hinzufügen muss. Warum gibt es dafür zwei Bibliotheken?

Also, was ist die bessere Wahl? Es gibt nicht viele Beispiele, um das Frontend mit dem Backend zu verbinden. Was ist ein gutes Arbeitsbeispiel für einen Backend-Rest-Aufruf an dieses:

URI: ../restapi/topics GET-Authentifizierungsdaten: admin / secrect-Format: json




Ich denke, dass Ihre Frage bald blockiert werden wird. Es gibt ein paar Konflikte zwischen den beiden Frameworks.

Grundsätzlich macht Backbone nicht viele Dinge, und deshalb liebe ich es: Sie müssen viel programmieren, aber Sie werden am richtigen Ort programmieren. Ember macht eine Menge Dinge, also solltest du besser aufpassen, was es macht.

Server Diskussion ist eine der wenigen Sachen, die Backbone tut, und es macht einen tollen Job damit. Also würde ich mit Backbone anfangen und dann Ember versuchen, wenn du nicht vollkommen zufrieden bist.

Sie können sich auch diesen Podcast anhören, wo Jeremy Ashkenas, Autor von Backbone, und Yehuda Katz, Mitglied von Ember, eine nette Diskussion führen




Um eine kurze, vereinfachte Antwort zu geben: Für ein REST-fähiges Backend sollten Sie im Moment Backbone verwenden.

Um eine komplexere Antwort zu geben: Es hängt wirklich davon ab, was Sie tun. Wie andere gesagt haben, ist Ember für verschiedene Dinge konzipiert und wird eine andere Gruppe von Menschen ansprechen. Meine kurze Antwort basiert auf Ihrer Einbeziehung der RESTful-Anforderung.

Im Moment ist Ember-Data (was der Standard-Persistenzmechanismus in Ember zu sein scheint) noch lange nicht produktionsbereit. Das bedeutet, dass es einige Bugs hat und, im Wesentlichen, keine verschachtelten URIs (/ posts / 2 / comments / 4556 zum Beispiel) unterstützt. Wenn REST Ihre Anforderung ist, dann müssen Sie dies vorläufig umgehen, wenn Sie sich für Ember entscheiden (dh Sie müssen es entweder hacken, warten, etwas wie "Ember-Data" von Grund auf selbst implementieren oder nicht verwenden) - sehr REST-konforme URIs). Glimm-Daten gehören nicht unbedingt zu Ember, also ist dies durchaus möglich.

Die Hauptunterschiede zwischen den beiden sind neben der Größe im Wesentlichen:

Ember versucht so viel wie möglich für dich zu tun, damit du nicht so viel Code schreiben musst. Es ist sehr hierarchisch und, wenn Ihre App auch sehr hierarchisch ist, wird es wahrscheinlich gut passen. Weil es so viel für Sie tut, kann es schwierig sein herauszufinden, woher Fehler kommen und warum unerwartetes Verhalten passiert (es gibt eine Menge "Magie"). Wenn Sie eine App haben, die sich natürlich in die Art von App einfügt, die Ember erwartet, dass Sie dennoch bauen, wird das wahrscheinlich kein Problem sein.

Backbone versucht, so wenig wie möglich für Sie zu tun, damit Sie nachvollziehen können, was vor sich geht, und eine Architektur erstellen, die zu Ihrer App passt (anstatt eine App zu entwickeln, die zur Architektur des von Ihnen verwendeten Frameworks passt). Es ist viel einfacher, damit anzufangen, aber wenn Sie nicht vorsichtig sind, können Sie sehr schnell ein Durcheinander bekommen. Es macht keine Dinge wie berechnete Eigenschaften, automatisch abbindende Ereignisse usw. und überlässt sie Ihnen, so dass Sie eine Menge Dinge selbst implementieren müssen (oder zumindest Bibliotheken auswählen müssen, die das für Sie tun), obwohl das ist eher der springende Punkt.

Update : Es scheint, dass Ember in letzter Zeit verschachtelte URIs unterstützt, also denke ich, die Frage hängt davon ab, wie viel Magie du magst und ob Ember architektonisch gut zu deiner App passt.




Leider gibt es viele Fehlinformationen und Missverständnisse rund um REST. Nicht nur Ihre Frage und die Antwort von @cmd reflektieren diese, sondern die meisten Fragen und Antworten zu dem Thema auf .

SOAP und REST können nicht direkt verglichen werden, da das erste ein Protokoll ist (oder es zumindest versucht) und das zweite ein Architekturstil ist. Dies ist wahrscheinlich eine der Quellen der Verwirrung, da Leute dazu neigen, REST jede HTTP-API aufzurufen, die nicht SOAP ist.

Der Unterschied zwischen SOAP und REST ist der Grad der Kopplung zwischen Client- und Serverimplementierungen. Ein SOAP-Client funktioniert wie eine benutzerdefinierte Desktop-Anwendung, die eng mit dem Server verbunden ist. Es gibt einen starren Vertrag zwischen Client und Server, und es wird erwartet, dass alles bricht, wenn eine Seite etwas ändert. Nach jeder Änderung müssen Sie ständig aktualisiert werden. Es ist jedoch einfacher festzustellen, ob der Vertrag befolgt wird.

Ein REST-Client ähnelt eher einem Browser. Es ist ein generischer Client, der weiß, wie man ein Protokoll und standardisierte Methoden verwendet, und eine Anwendung muss in diese passen. Sie verstoßen nicht gegen die Protokollstandards, indem Sie zusätzliche Methoden erstellen, Sie nutzen die Standardmethoden und erstellen die Aktionen mit diesen auf Ihrem Medientyp. Wenn es richtig gemacht wird, gibt es weniger Kopplung, und Änderungen können eleganter behandelt werden. Ein Client sollte einen REST-Service ohne Kenntnis der API eingeben, mit Ausnahme des Einstiegspunkts und des Medientyps. In SOAP benötigt der Client Vorwissen über alles, was er verwendet, oder er beginnt nicht einmal mit der Interaktion. Darüber hinaus kann ein REST-Client durch Code-on-Demand erweitert werden, der vom Server selbst bereitgestellt wird. Das klassische Beispiel ist ein JavaScript-Code, der die Interaktion mit einem anderen Dienst auf der Clientseite steuert.

Ich denke, dies sind die entscheidenden Punkte, um zu verstehen, worum es bei REST geht und wie es sich von SOAP unterscheidet:

  • REST ist protokollunabhängig. Es ist nicht an HTTP gekoppelt. So wie Sie einem FTP-Link auf einer Website folgen können, kann eine REST-Anwendung jedes Protokoll verwenden, für das ein standardisiertes URI-Schema existiert.

  • REST ist keine Zuordnung von CRUD zu HTTP-Methoden. Lesen Sie this Antwort für eine detaillierte Erklärung dazu.

  • REST ist so standardisiert wie die Teile, die Sie verwenden. Sicherheit und Authentifizierung in HTTP sind standardisiert, also verwenden Sie REST über HTTP.

  • REST ist nicht REST ohne hypermedia und HATEOAS . Dies bedeutet, dass ein Client nur den Einstiegspunkt-URI kennt und die Ressourcen Links zurückgeben sollen, denen der Client folgen soll. Jene phantastischen Dokumentationsgeneratoren, die URI-Muster für alles geben, was Sie in einer REST-API tun können, verpassen diesen Punkt vollständig. Sie dokumentieren nicht nur etwas, das dem Standard folgen soll, aber wenn Sie das tun, binden Sie den Client an einen bestimmten Moment in der Entwicklung der API, und alle Änderungen an der API müssen dokumentiert und angewendet werden. oder es wird brechen.

  • REST ist der architektonische Stil des Webs selbst. Wenn Sie eingeben, wissen Sie, was ein Benutzer, eine Frage und eine Antwort sind, Sie kennen die Medientypen, und die Website bietet Ihnen die Links zu ihnen. Eine REST-API muss das Gleiche tun. Wenn wir das Web so gestalten, wie es die Leute für REST halten, haben wir statt einer Homepage mit Links zu Fragen und Antworten eine statische Dokumentation, die erklärt, dass Sie den URI .com/questions/<id> müssen, um eine Frage zu .com/questions/<id> , ersetze die ID durch die Question.id und füge sie in deinen Browser ein. Das ist Unsinn, aber viele Leute denken, dass REST ist.

Dieser letzte Punkt kann nicht genug betont werden. Wenn Ihre Clients URIs aus Vorlagen in der Dokumentation erstellen und keine Links in den Ressourcendarstellungen erhalten, handelt es sich nicht um REST. Roy Fielding, der Autor von REST, hat in diesem Blogpost klargestellt: REST-APIs müssen hypertextgesteuert sein .

In Anbetracht dessen werden Sie feststellen, dass REST zwar nicht auf XML beschränkt ist, Sie jedoch für jedes andere Format ein Format für Ihre Links entwerfen und standardisieren müssen. Hyperlinks sind in XML Standard, nicht jedoch in JSON. Es gibt Entwurfsstandards für JSON, wie HAL .

Schließlich ist REST nicht jedermanns Sache, und ein Beweis dafür ist, dass die meisten Leute ihre Probleme sehr gut mit den HTTP-APIs lösen, die sie fälschlicherweise REST genannt haben, und niemals darüber hinausgehen. REST ist manchmal schwierig, besonders am Anfang, aber es zahlt sich im Laufe der Zeit mit einer einfacheren Entwicklung auf der Serverseite und der Widerstandsfähigkeit des Clients gegenüber Änderungen aus. Wenn Sie etwas schnell und einfach erledigen möchten, machen Sie sich keine Sorgen um REST. Es ist wahrscheinlich nicht das, wonach du suchst. Wenn Sie etwas brauchen, das für Jahre oder sogar Jahrzehnte online bleiben soll, dann ist REST für Sie da.





ruby-on-rails rest backbone.js ember.js frontend