Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Ruby on Rails ist ein Full-Stack-Web-Framework, geschrieben in der Sprache Ruby. Es gibt Ihnen das ganze Backend in einem meinungsstarken Paket: Datenbankschicht, Routing, Controller, Templating, Hintergrundjobs und einen reifen Satz an Konventionen, wie sie zusammenpassen. 2004 veröffentlicht, prägte es, wie eine Generation von Web-Apps gebaut wurde.
Seine Kernidee ist Konvention vor Konfiguration. Rails nimmt sinnvolle Standards an, sodass Sie weniger Boilerplate schreiben und mehr von der Logik, die wirklich zählt. Ein kleines Team kann an einem Tag eine funktionierende, datenbankgestützte Anwendung auf die Beine stellen, weshalb Rails zum Framework hinter den frühen Shopify, GitHub und Basecamp wurde. Der objektrelationale Mapper, Active Record, lässt Sie mit Datenbankzeilen wie mit gewöhnlichen Ruby-Objekten arbeiten, und das Framework setzt stark auf lesbaren, ausdrucksstarken Code statt auf Zeremonie.
Rails ist standardmäßig ein monolithisches Framework, was Stärke und Grenze zugleich ist. Verglichen mit einem JavaScript-Stack wie Node mit getrenntem Frontend hält Rails alles an einem Ort und in einer Sprache auf dem Server, was kleine und mittlere Teams beschleunigt. Bei sehr großem Maßstab oder für aufwendige Echtzeit- und Nebenläufigkeitsarbeit können andere Stacks vorbeiziehen. Für die meisten CRUD-lastigen Produkte und internen Tools liefert Rails Funktionen noch schneller aus als fast alles andere.
Wir arbeiten mit Rails dort, wo Tempo bis zu einem funktionierenden Produkt zählt und die Domäne überwiegend aus Formularen, Datensätzen und Geschäftslogik besteht. Interne Tools, Admin-Plattformen, inhaltsgetriebene Apps, die Art individueller Webanwendung, die existieren und sich schnell rentieren muss, statt einen Benchmark zu gewinnen.
Rails hat seinen Platz und seine Grenzen. Es ist hervorragend für eine reifende Codebasis, die ein Team von Anfang bis Ende besitzt, und weniger naheliegend, wenn ein Projekt ab dem ersten Tag auf ein entkoppeltes Frontend oder Microservices zusteuert. Wenn wir eine Rails-App erben, besteht die Aufgabe meist darin, die Teile zu bändigen, die schneller wuchsen, als die Struktur sie halten konnte. Wir behalten die Konventionen, die sie produktiv machen, und räumen die Abkürzungen auf, die sie fragil machten.
Eine Rails-App zu bauen oder zu entwirren? Gehen wir es an.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















