Ich habe eine Erinnerung daran, mit Leuten zu reden, die Ruby on Rails so weit benutzt haben und sie dann aufgeben mussten, als sie an Grenzen stießen, oder fanden, dass es letztendlich zu starr war. Ich vergesse die Details, aber es hat vielleicht mit der Verwendung von mehr als einer Datenbank zu tun.
Was ich also gerne wissen möchte, ist, welche Features / Anforderungen außerhalb von Ruby on Rails liegen oder zumindest solche Verrenkungen erfordern, dass es besser ist, ein anderes flexibleres Framework zu verwenden, auch wenn Sie etwas an Eleganz verlieren müssen oder schreiben Sie einen zusätzlichen Code.
Rails (nicht Ruby selbst) ist stolz darauf, "Opinionated Software" zu sein.
Was dies in der Praxis bedeutet, ist, dass die Autoren von Rails eine gewisse Zielgruppe (im Grunde genommen) haben und gezielt darauf zielen. Wenn das X-Feature für diese Zielgruppe nicht benötigt wird, wird es nicht hinzugefügt.
Ganz oben auf meinem Kopf, Dinge, die Rails explizit nicht unterstützen, die Leute interessieren könnten:
Das heißt, es ist sehr einfach, Rails mit Plugins zu erweitern, und es gibt Plugins, die alle oben genannten Funktionen zu Rails hinzufügen, und noch viel mehr, also würde ich diese nicht wirklich als Grenzen zählen.
Der einzige andere Nachteil ist, dass Rails gebaut werden, um CRUD-Webanwendungen mit MVC zu erstellen. Wenn Sie versuchen, etwas zu tun, das KEINE CRUD-Web-App ist (wie Twitter, das tatsächlich ein Messaging-System ist, oder wenn Sie verrückt sind und ein Modell wie ASP.NET-Webformulare verwenden möchten), werden Sie ebenfalls auf Probleme stoßen. In diesem Fall ist es besser, keine Schienen zu verwenden, da Sie im Wesentlichen versuchen, ein Boot aus Fahrradteilen zu bauen.
Aller Wahrscheinlichkeit nach sind die Probleme, denen Sie begegnen werden, nicht nur mit einem schnellen Plugin oder einem Tag oder zwei Coding behoben, sondern sind alle Probleme mit der zugrundeliegenden C-Ruby-Laufzeit (Speicherlecks, grüne Threads, Mist-Performance) usw.).
Ruby on Rails unterstützt keine zweiphasigen Commits, die erforderlich sind, wenn Ihre datenbankgestützte Anwendung sofortige Konsistenz garantieren UND Sie zwei oder mehr Datenbankschemas verwenden müssen.
Für viele Webanwendungen würde ich behaupten, dass dies kein gewöhnlicher Anwendungsfall ist. Man kann durchaus eine mögliche Konsistenz mit zwei oder mehr Datenbanken unterstützen. Oder man könnte sofortige Konsistenz mit einem Datenbankschema unterstützen. Der erste Fall ist ein großes Problem, wenn Ihre App eine große Menge an Transaktionen unterstützen muss (beachten Sie den technischen Begriff :). Der letztere Fall ist typischer, und Rails geht es gut.
Ehrlich gesagt, würde ich mir keine Sorgen machen, dass Ruby on Rails (oder ein anderes Framework) so lange verwendet werden kann, bis Sie echte Probleme mit der Skalierbarkeit haben. Erstellen Sie eine Killer App zuerst und sorgen Sie sich dann um die Skalierbarkeit.
KLARIFIZIERUNG: Ich denke an Dinge, die Rails schwer haben würde zu unterstützen, weil es eine grundlegende Änderung in seiner Architektur erfordern könnte. Ich werde großzügig sein und einige Dinge einbeziehen, die Teil des Edelstein- / Plugin-Ökosystems sind, wie zum Beispiel die Erzwingung von Fremdschlüsseln oder SOAP-Services.
Mit zweiphasigen Commits meine ich den Versuch, innerhalb eines transaktionalen Kontextes zwei Commits zu physisch unterschiedlichen Servern zu machen.
Anwendungsfall # 1 für eine zweiphasige Festschreibung: Sie haben Ihre Datenbank gruppiert, sodass Sie über zwei oder mehr Datenbankserver verfügen und Ihr Schema auf beide Server verteilt ist. Möglicherweise möchten Sie beide Server aktivieren, da Sie ActiveRecord eine "Fremdschlüsselzuordnung" ermöglichen möchten, die die verschiedenen Server durchquert.
Anwendungsfall # 2 für ein zweiphasiges Commit: Sie versuchen, eine Messaging-Lösung zu implementieren (Entschuldigung, ich bin J2EE-Entwickler bei Tag). Der Nachrichtenproduzent wird an den Messaging-Broker (ein Server) und an die Datenbank (ein anderer Server) gebunden.
Habe auch eine gute Diskussion über die Limits von ActiveRecord gefunden.
Ich denke, es gibt hier eine größere "Meta-Frage", die beantwortet werden könnte und das heißt "wann ist es in Ordnung, auf externe Bibliotheken zu setzen, um die Entwicklungszeit zu beschleunigen?"
Third-Party-Bibliotheken sind oft großartig und können die Entwicklungszeit drastisch reduzieren, aber es gibt ein großes Problem, Joel Spolsky nennt dies "das Gesetz der undichten Abstraktionen". Wenn Sie das auf Google nachschlagen, wird sein Beitrag zuerst erscheinen. Im Wesentlichen bedeutet dies, dass der Trade-off in der Entwicklungszeit bedeutet, dass Sie keine Ahnung haben, was unter den Deckungen passiert. Wenn also etwas kaputt geht, sind Sie völlig festgefahren und haben nur sehr eingeschränkte Methoden zum Debuggen. Das bedeutet auch, dass Sie, wenn Sie eines der Features, die in RAILS einfach nicht unterstützt werden, wirklich brauchen, haben Sie keinen weiteren Schritt, außer das Feature selbst zu schreiben, wenn Sie Glück haben. Viele Bibliotheken können dies schwierig machen.
Wir wurden in meinem Entwicklerladen durch dieses Problem schlecht verbrannt. Unsere Lösungen funktionierten bei normaler Auslastung gut, aber wir stellten fest, dass die von uns verwendeten Drittanbieter-Abonnementbibliotheken der Belastung, die wir hatten, nicht mehr standhalten konnten, sobald unsere Website eine große Anzahl gleichzeitiger Benutzer erreichte. Dies versetzt uns in einen sehr schwierigen Ort. im Wesentlichen müssen wir den gesamten Abo-Service selbst neu schreiben, mit Blick auf die Leistung. Das bedeutet, dass wir die gesamte Zeit, die wir mit der Verwendung der Bibliothek verbracht haben, verschwendet haben.
Bibliotheken von Drittanbietern können für kleine bis mittelgroße Anwendungen ideal sein; Sie können die Entwicklungszeit drastisch reduzieren und Komplexitäten verbergen, die in den frühen Entwicklungsphasen nicht notwendig sind. Aber schließlich werden sie Sie einholen und Sie werden Ihre Lösung wahrscheinlich neu schreiben oder neu konstruieren müssen, um das "Gesetz der undichten Abszektionen" zu umgehen.
Orions Antwort ist richtig. Es gibt einige harte Grenzen für AR / Rails: Bereitstellen unter Windows, AR-Konnektoren, die nicht häufig verwendet werden, z. Firebird,), aber selbst die Dinge, die er erwähnt hat, mehrere Datenbanken und DB-Server, es gibt Edelsteine und Plugins, die solche aus Legacy, Sharding und anderen Gründen ansprechen.
Die wirkliche Einschränkung ist, wie zeitaufwendig es ist, immer auf dem Laufenden zu sein, woran die Entwickler arbeiten und welche Probleme es gibt, wieviele Blogs da sind und wieviel Mailing-Listen es gibt.
Tags und Links ruby ruby-on-rails