rails et colonne vertébrale travaillant ensemble

Question

Je commence tout juste à regarder la structure MVC, j'ai d'abord regardé combien de backbone.js a travaillé, et maintenant je viens de terminer les rails pour les zombies, par le Code de l'École. Je sais que je n'ai pas creusé trop loin dans tout cela, mais j'avais une question pour commencer.

Pouvez-vous utiliser ces bibliothèques ensemble?

J'ai appris comment créer models, views, etc dans les deux, mais lors de la création d'une véritable application utilisez-vous les deux épine dorsale et les rails?

Si oui...

Lorsque vous utilisez un backbone.js modèle de contre une rails modèle?

Peut-être que je suis juste en train de venir de moi-même et de la nécessité de continuer à pratiquer et faire des tutoriels mais je n'arrivais pas à trouver quoi que ce soit directement sur ce.

Merci!

Answer 1

Avant toute chose, je vous suggère de prendre un coup d'oeil à thoughtbot de l' Backbone.js sur les Rails de la livre, qui est un excellent point de départ, bien que destiné à un intermédiaire à avancé public. J'ai acheté ce livre après avoir déjà travaillé avec des rails, mais comme un total backbone.js débutant et il a servi de moi très bien.

Au-delà de ça, il y a des problèmes fondamentaux avec la combinaison de ces cadres, qui vont au-delà des détails abordés dans ce livre et d'autres livres. Ci-dessous sont quelques choses que je vous suggère de vous y pensez, à partir de mes propres expériences de couplage RoR et backbone.js. C'est une longue réponse et s'écarte un peu de la nature de votre question, mais j'espère que ça peut vous aider dans la "big picture" le sens de la compréhension du problème auquel vous êtes confronté.

Rails: Framework Web vs API

La première chose que vous rencontrez lors de l'utilisation de backbone.js sur le haut d'une application rails est de savoir quoi faire au sujet de points de vue, mais c'est vraiment juste la surface d'un problème bien plus grave. Le problème va au cœur même de ce que cela signifie pour créer un service web RESTful.

Rails est mis en place au sortir de la boîte pour encourager ses utilisateurs à créer des services RESTful, par la structuration de routage en termes d'un ensemble de ressources accessibles à l'uniforme des URIs (définis dans votre routes.rb le fichier) par le biais de la norme HTTP actions. Donc, si vous avez un Post modèle, vous pouvez:

• Obtenez tous les messages en envoyant GET demande /posts
• Créer un nouveau poste en envoyant un GET demande /posts/new, remplissant le formulaire et en l'envoyant (un POST demande) /posts
• Mise à jour d'un post avec l'id 123 par l'envoi d'un GET demande /posts/123/edit, remplissant le formulaire et en l'envoyant (un PUT demande) posts/123
• Détruire un post avec l'id 123 par l'envoi d'un DELETE demande /posts/123

L'essentiel à retenir sur cet aspect de Rails, c'est qu'il est fondamentalement apatrides: peu importe ce que je faisais auparavant, je peux créer un nouveau Post simplement par l'envoi d'un POST de la demande avec une forme valide de données à l'URI correct, disons /posts. Bien sûr il y a des bémols: j'ai peut-être besoin d'être connecté (avoir un cookie de session de m'identifier), mais dans l'essence de Rails n'est pas vraiment ce que je faisais avant, j'ai envoyé cette demande. J'ai pu la suivre jusqu'en mettant à jour un autre post, ou par l'envoi d'une action valide pour toutes les autres ressources mises à ma disposition.

Cet aspect de la façon dont les Rails sont conçus, il est relativement facile de transformer un (Javascript-lumière) Rails d'applications web en un API: les ressources vont être semblables ou identiques, le framework web de retour HTML des pages que l'API (généralement) retourne les données en JSON ou XML format.

Backbone.js: Une nouvelle dynamique de la couche de

La dorsale est également basé sur Reposante ressources. Chaque fois que vous créez, mettez à jour ou de détruire un backbone.js modèle, vous pouvez le faire via le standard HTTP actions envoyé à Uri qui supposent une bonne architecture du type décrit ci-dessus. Cela le rend idéal pour l'intégration avec des services RESTful comme RoR.

Mais il est un point subtil pour être souligné ici: backbone.js s'intègre de façon transparente avec les Rails de l'API. C'est-à-dire, si vous enlevez le code HTML de points de vue et juste utiliser Rails pour servir Reposant ressources, l'intégration avec la base de données, d'effectuer la gestion de session, etc., ensuite, il s'intègre très bien avec la structure backbone.js prévoit le code côté client. Beaucoup de gens estiment qu' il n'y a rien de mal avec l'aide de rails de cette façon, et je pense que dans beaucoup de façons, ils sont de droite.

Les complications surviennent mais à partir de la question de quoi faire avec cette autre partie de Rails que nous venons de jeter: le point de vue et ce qu'ils représentent.

Stateful les humains, les apatrides, les machines

C'est en fait plus importante que l'on peut d'abord sembler. HTML vues représentent les apatrides interface que les humains utilisent pour accéder à l'Reposant ressources à votre service fournit. Faire loin avec eux vous laisse avec deux points d'accès:

1. Pour les êtres humains: un riche, côté client interface fournie par le backbone.js couche (stateful)
2. Pour les machines: une axée sur les ressources RESTful API fournie par les rails de la couche (stateless)

Notez qu'il n'y a plus d'un apatride (RESTful) interface pour les humains. En revanche, dans un traditionnel application rails avec une API, nous avons eu quelque chose de plus près à ceci:

1. HTML des ressources pour les humains (stateless)
2. JSON/ressources XML (API) pour les machines (stateless)

Les deux derniers interfaces pour accéder aux ressources sont beaucoup plus près de la nature les uns des autres que les deux précédents. Pensez juste à par exemple des rails respond_with, qui tire parti des similitudes pour l'envelopper de divers Reposant intervenants dans une méthode unifiée.

Travailler ensemble

Cela peut sembler très abstrait et à côté de la question, je sais. Pour essayer de le rendre plus concret, considérons le problème suivant, qui est de revenir à votre question sur l'obtention d'rails et backbone.js à travailler ensemble. Dans ce problème, vous souhaitez:

• Créer un service web avec un client riche expérience côté à l'aide de backbone.js, avec des rails que l'extrémité arrière de servir de ressources au format JSON.
• Utiliser pushState afin de donner à chaque page dans l'application d'une URL (par exemple, /posts/123) qui peut être accessible directement (dans la barre du navigateur).
• Pour chacune de ces Url, également servir d'une page HTML pour les clients sans javascript.

Ce ne sont pas inhabituelles exigences d'un système moderne de service web, mais ils créent un défi complexe. Pour rendre une longue histoire courte, il vous faut maintenant créer deux "orientés vers l'humain" couches:

1. Dynamique côté client (interface backbone.js les modèles et les vues)
2. Apatrides HTML de ressources (Rails HTML vues)

La complexité de réellement faire cela conduit de nombreux aujourd'hui à abandonner la dernière de ces deux et en offrant un riche client-côté de l'interface. Ce que vous décidez de le faire dépend de vos objectifs et ce que vous voulez atteindre, mais il vaut la peine de réfléchir à ce problème avec soin.

Comme autre référence possible pour le faire, je te suggère de jeter un oeil sur O'Reilly Services Web RESTful. Il peut paraître étrange de recommander un livre sur le REPOS à une question sur les Rails et Backbone.js mais en fait, je pense que c'est l'élément clé qui correspond à ces cadres de travail très différents ensemble, et une compréhension plus complète vous aidera à tirer parti des forces des deux.

Answer 2

Oui, vous pouvez utiliser les deux côtés. La dorsale est pour le stockage et la manipulation de données dans le navigateur client. Il a généralement besoin d'un serveur de parler, et de récupérer les données à partir de. C'est là que Rails est en. Vous pouvez avoir une application web sans un code côté client. Est une ossature pour la construction de sites qui se sentent plus comme des applications--pensez à Gmail ou Pandora.

Je conseille juste d'apprentissage Rails en premier. Une fois que vous pouvez obtenir des pages statiques chargement et le style comme vous le souhaitez, puis comprendre épine Dorsale de la place aura plus de sens

Answer 3

J'ai utilisé des rails comme un serveur d'arrière-plan pour servir un assez grand site web, ce qui inclus quelques une page apps (construit dans la colonne vertébrale).

Je vous suggère de l' backbone-on-rails gem. L'idée est que votre serveur rails va servir jusqu'à l'épine dorsale de l'app comme une balise script dans l'un de vos points de vue. Vous gardez votre colonne vertébrale application elle-même dans les rails app/assets le dossier.

Épine dorsale comprend des rails de routage conventions, et vous avez juste besoin de donner un chemin d'accès à une api json que les rails près de générer pour vous avec rails generate resource.

Autre que la synchronisation entre les modèles, votre épine dorsale des applications et des rails, les applications sont assez distincts. L'épine dorsale et les Rails n'ont pas tout à fait le même modèle MVC, mais de les amener à coopérer est assez facile.