Die Rails-Gems, die wir tatsächlich einsetzen: Redwerks Produktions-Gemfile

Sie benötigen Authentifizierung, Hintergrundverarbeitung, PDF-Export oder Stripe-Abrechnung? Jemand hat fast sicher ein Gem dafür veröffentlicht, und genau deshalb greifen Entwickler so oft zu Rails-Gems. Es ist auch der Grund, warum eine Gemfile zu einer Wartungsrechnung werden kann, für die sich niemand angemeldet hat.

Das Ausmaß des Ökosystems erklärt die Zuneigung. RubyGems.org, das offizielle Repository für Ruby on Rails Gems und jedes andere Ruby-Paket, beherbergt derzeit 193.910 Gems, 244.700 registrierte Benutzer und fast 255 Milliarden Downloads.

Von den zehn beliebtesten Ruby-Gems aller Zeiten sind die Spitzenreiter Bundler und ein Cluster von AWS SDK Gems, aber drei Kern-Rails-Bibliotheken schaffen es ebenfalls auf die Liste, wobei i18n, activesupport und rake jeweils über 1,3 Milliarden Downloads aufweisen.

Fügen Sie eine Zeile zu Ihrer Gemfile hinzu, führen Sie `bundle install` aus, und Sie erben Tausende von Arbeitsstunden von den Leuten, die diese Ruby-Bibliotheken pflegen. Dieser Artikel ist die ehrliche Version dessen, wie wir diese Erbschaft bei Redwerk behandeln: die Gems, die wir in der Produktion verwenden, wenn wir Ruby on Rails-Anwendungen für Kunden erstellen und pflegen, diejenigen, die wir streichen, und die Regel, die entscheidet, welche welche sind.

Jeder Rails-Gem ist auch eine Haftung

Ein Rails-Gem ist eine verpackte Bibliothek von Ruby-Code, die Sie in ein Projekt einfügen, um eine Funktion hinzuzufügen, ohne sie selbst zu erstellen. Jeder Gem in Ihrer Gemfile ist Code, von dem Sie abhängig sind, den Sie aber nicht selbst geschrieben haben, der von Personen gepflegt wird, die Sie nie getroffen haben, und der fehlerhaft, veraltet oder feindselig werden kann. Das ist keine Paranoia. Es ist die dokumentierte Realität moderner Software, in der Wiederverwendung der Standard ist und die Angriffsfläche mit ihr gewachsen ist.

Die Daten untermauern das. Im August 2025 deckten Forscher eine Kampagne von 60 bösartigen Gems auf, die sich als Tools zur Automatisierung sozialer Medien ausgaben, seit mindestens März 2023 aktiv waren und mehr als 275.000 Mal heruntergeladen wurden, bevor sie entfernt wurden. Allein die Aufrechterhaltung des Registries selbst ist nicht kostenlos, da Ruby Central schätzt, dass der Betrieb von RubyGems.org, einschließlich Server, Infrastruktur und bezahlter Maintainer, rund 500.000 US-Dollar pro Monat kostet. Nichts davon bedeutet, dass Gems schlecht sind. Es bedeutet, dass jeder eine Entscheidung ist, und Entscheidungen verdienen einen Prozess.

Wie wir entscheiden, ob ein Gem seinen Platz verdient

Die meisten Artikel deuten hier auf Instinkt hin, aber Instinkt überträgt sich nicht auf ein Team oder erklärt sich einem Kunden. Bevor ein Gem in eine Gemfile aufgenommen wird, durchlaufen wir ihn einer kurzen Checkliste. Das Ziel ist nicht, die Gem-Anzahl um ihrer selbst willen zu minimieren. Es geht darum, sicherzustellen, dass jede Abhängigkeit ihren Zweck erfüllt.

Wartungssignale: Veröffentlichungsfrequenz, das Verhältnis von offenen zu geschlossenen Issues und das Risiko des “Bus-Faktors”. Ein cleverer Gem mit einem Maintainer und einem Jahr Stille ist immer noch ein Risiko.
Gewicht und transitive Abhängigkeiten: Ein Gem zieht seine eigenen Abhängigkeiten nach sich, und Sie erben alle davon. Wir prüfen also, was stromabwärts ankommt, bevor wir uns festlegen.
Der “Kann Rails das schon?”-Test: Wir bevorzugen schlichtes, Standard-Rails, und wenn das Framework es abdeckt, nutzen wir das Framework.
Umkehrbarkeit: Wenn der Gem morgen aufgegeben wird, wie schwer ist es, ihn herauszureißen? Wir bewerten den “Lock-in” im Voraus.
Lizenzierung und Budget: Kostenlose vs. kostenpflichtige Tarife sind wichtig, wenn ein Kunde auf die Ausgaben achtet.
Sicherheitslage: signierte Releases, ein reaktionsschneller Maintainer und eine saubere Historie.
Passform für das Team: Die Entwickler, die die App übernehmen, müssen mit unseren Entscheidungen leben.

Unsere Arbeitsregel ist einfach: Wenn niemand im Team erklären kann, warum ein Gem in der Gemfile ist, sollte er nicht da sein.

Es gibt keine einzelne korrekte Gemfile

Die richtige Gem-Liste hängt vom jeweiligen Projekt ab, was Listenartikel nie zugeben. Eine Agentur steht dem ständig gegenüber, da wir zwischen neuen Projekten, jahrzehntealten Codebasen und allem dazwischen wechseln. Es gibt keine universelle Ruby on Rails Gems-Liste, die für jede Situation passt.

Bei neuen Projekten verlassen wir uns auf moderne Rails-Standardeinstellungen und minimale zusätzliche Infrastruktur.
Bei übernommenen oder Legacy-Anwendungen prüfen wir, bevor wir hinzufügen, minimieren den Aufwand und respektieren die vorhandenen Muster.
Für budgetbewusste Kunden vermeiden wir kostenpflichtige Gem-Tarife und Zusatzdienste, wenn eine datenbankgestützte Option die Aufgabe erfüllt.
Für Compliance-intensive Kunden straffen wir die Sicherheitstools und halten Upgrade-Richtlinien konservativ.

Selbes Framework, andere Gemfile, je nach Projekt.

Das Fundament: Server, Datenbank und Hintergrundjobs

Einige Entscheidungen sind keine Debatte wert. Für den Webserver verwenden wir Puma, für die Datenbank PostgreSQL, und bei einem typischen Kundenprojekt wirft diese Entscheidung keine große Diskussion auf. Die wirklich interessante Entscheidung liegt bei den Hintergrundjobs.

Mit Rails 8 wurde die Hintergrundverarbeitung zu einer echten Weggabelung. Active Job ist die Queue-Abstraktion des Frameworks, und die praktische Frage ist, welcher Adapter dahinter sitzt. Die Entscheidung zwischen Active Job, Sidekiq und Solid Queue hängt normalerweise eher von der Infrastruktur und dem Umfang als von der Syntax ab.

Der Kompromiss zwischen Solid Queue und Sidekiq ist der Kernpunkt. Solid Queue wird als Standard für Rails 8 mitgeliefert und speichert Jobs in Ihrer bestehenden Datenbank mithilfe einer PostgreSQL- und MySQL-Sperrfunktion namens `FOR UPDATE SKIP LOCKED`. Es benötigt also kein Redis und keinen zusätzlichen Dienst. Das bringt Ihnen transaktionale Integrität, bei der ein Job und die Daten, von denen er abhängt, zusammen committet werden, sowie einfachere Operationen. Sidekiq ist Redis-basiert, kampferprobt und immer noch der Durchsatz-Champion, wenn Sie einige tausend Jobs pro Minute überschreiten. Wenn Sie den Vergleich umgekehrt betrachten, ist die Logik Sidekiq vs. Solid Queue identisch: Sie wägen die zusätzlichen Infrastrukturkosten und das transaktionale Risiko eines separaten Speichers gegen den reinen Geschwindigkeitsgewinn ab.

Für die meisten Kundenanwendungen, die unter tausend Jobs pro Minute verarbeiten, ist Solid Queue die richtige Standardeinstellung und weniger zu betreiben. Wenn ein Produkt wirklich im großen Maßstab läuft, verdient Redis seinen Platz. Als wir den PlusPlus Slack Bot neu entwickelten, brach die ursprüngliche Python-Version unter der Last zusammen, also haben wir sie in Ruby on Rails mit Redis, PostgreSQL und AWS neu entwickelt, und sie verarbeitet jetzt über eine Million Benutzeraktionen pro Minute. Das ist das Ausmaß, bei dem die schwerere Infrastruktur sich eindeutig auszahlt.

Die Datenebene: Active Record Extensions

Die Gems in Ruby on Rails, die Ihre Datenebene berühren, verdienen besondere Aufmerksamkeit, da sie nahe an allem liegen. Die meisten Apps benötigen dieselbe Handvoll Funktionen: Paginierung, Soft Delete, Volltextsuche, zeitbasierte Gruppierung und JSONB-Modellierung. Jahrelang bedeutete dies, reflexartig nach einem Gem zu greifen.

Wir ordnen jedem Bedarf einen Kandidaten zu. Pagy ist leicht und schnell für die Paginierung. Pg_search nutzt PostgreSQL, anstatt einen Elasticsearch-Cluster anzubinden, den Sie noch nicht benötigen. Groupdate spart echte Zeit, wenn Sie Datensätze nach Tag, Woche oder Monat gruppieren.

Für dies benötigen Sie wahrscheinlich keinen Gem. Soft Deletion ist das klassische Beispiel, da ein `deleted_at`-Timestamp und ein Standard-Scope die meisten Fälle ohne Abhängigkeit behandeln, und das Überspringen des Gems subtile Fehler vermeidet, für die Soft-Delete-Bibliotheken bekannt sind. Modernes Active Record modelliert auch native JSONB-Spalten, also greifen Sie nur dann zu einer Erweiterung, wenn Ihre Abfragen die eingebauten Funktionen wirklich übersteigen.

Authentifizierung und Autorisierung

Leser verwechseln diese beiden ständig, daher hilft es, sie sauber zu trennen. Authentifizierung ist der Nachweis, wer ein Benutzer ist. Autorisierung ist die Entscheidung, was dieser Benutzer tun darf, sobald er angemeldet ist. Sie erfordern unterschiedliche Werkzeuge, und die Landschaft für erstere hat sich kürzlich verschoben.

Rails 8 hat einen integrierten Authentifizierungsgenerator ausgeliefert, der Sitzungen, Passwortverwaltung und Reset-Flows ohne Gem erzeugt. Für eine geradlinige Kundenentwicklung ist dieser native Generator jetzt unser Ausgangspunkt, und er eliminiert eine aufwändige Abhängigkeit, die wir früher automatisch hinzugefügt haben. Devise verdient immer noch seinen Platz, wenn ein Projekt sein ausgereiftes Ökosystem an Erweiterungen benötigt, wie z.B. bestätigte Konten, sperrbare Logins oder mehrere OmniAuth-Anbieter, bei denen eine Neuerstellung von Hand mehr kosten würde als die Abhängigkeit.

Für die Autorisierung standardisieren wir auf Pundit, welches die Berechtigungslogik in einfachen Ruby-Policy-Objekten hält, die ein neuer Entwickler in Minuten lesen kann. Klare, testbare Richtlinien sind bei einer App, die wir an ein Kundenteam zurückgeben, weitaus wichtiger als jede clevere Abfragesprache.

Frontend und Ansichten

Das Frontend ist die eigentliche Weggabelung, und wir wählen basierend auf dem Team und dem Produkt des Kunden, nicht auf der Mode. Es gibt zwei wirklich gute Wege, und der falsche Weg führt zu jahrelangen Reibereien. Die richtige Wahl hier hängt hauptsächlich davon ab, wer die App als nächstes wartet.

Hotwire hält Sie innerhalb von Rails, liefert weniger JavaScript und eignet sich für inhaltsorientierte und CRUD-intensive Apps, die ein Rails-Team besitzen wird. Inertia mit React ist sinnvoll, wenn das Produkt hochgradig interaktiv ist oder wenn der Kunde bereits React-Entwickler hat, die das Frontend betreuen werden.

Für die Ansichtsstruktur verwenden wir ViewComponent, um Markup testbar und wiederverwendbar zu halten, was sich für jeden auszahlt, der die Codebasis übernimmt. Bei der Asset-Pipeline bevorzugt Rails 8 Propshaft gegenüber dem älteren Sprockets-Setup, und für die meisten neuen Builds folgen wir dieser Standardeinstellung. Das Leitprinzip ist die Wartbarkeit für das Team, das mit der App lebt, nachdem wir gegangen sind.

APIs erstellen

Die meisten Kundenanwendungen setzen irgendwann eine API ein, und die dortigen Entscheidungen tauschen Vertrautheit gegen Leistung. Die Standardeinstellungen sind in Ordnung, bis sie es nicht mehr sind, und zu wissen, wann man wechseln muss, ist die Kunst. Wir versuchen, nicht für ein Problem zu optimieren, das die App noch nicht hat.

Für die JSON-Serialisierung beginnen wir normalerweise mit Active Model Serializers oder Blueprinter und wechseln zu einer schnelleren Option wie Alba, erst wenn das Profiling zeigt, dass die Serialisierung die eigentliche Flaschenhalsschwelle ist. Wir behandeln REST-APIs als dokumentationsorientiert, generieren eine OpenAPI-Spezifikation, damit die anderen Teams des Kunden integrieren können, ohne unsere Controller reverse-engineeren zu müssen. Diese Disziplin zeigte ihren Wert bei Cleanagents, einer On-Demand-App für selbstständige Reinigungskräfte in Deutschland und Österreich, bei der die bestehende Plattform überhaupt keine APIs bereitstellte. Wir haben RESTful-APIs in Rails erstellt, um mit der Android-App zu kommunizieren, das Geocoder-Gem verwendet, um Auftragsorte aufzulösen, und dieses Geocoding in einen Hintergrundprozess verschoben, damit die App reaktionsfähig blieb.

GraphQL hat seinen Platz, wenn ein Kunde viele Verbraucher mit unterschiedlichen Datenanforderungen hat, wie z.B. mehrere Frontends, die ein Backend abfragen. Für eine einzelne App mit vorhersehbaren Endpunkten fügt es normalerweise Komplexität im Schema und Caching-Probleme hinzu, die eine einfache REST-API vermieden hätte. Wir empfehlen es, wenn das Produkt es erfordert, und wir raten Kunden davon ab, wenn es das nicht tut.

KI-Funktionen: Die Realität 2026

Viele Produkte möchten heutzutage ein Sprachmodell irgendwo im Stack haben, und Rails hat aufgeholt. Gems wie `ruby-openai` und das neuere `RubyLLM` machen das Aufrufen eines Modells und das Zurückbekommen strukturierter Ausgaben wirklich praktikabel. Die Kombination mit einem Ansatz für typisierte Ausgaben hält die Antworten vorhersehbar genug, um sie zu speichern und zu verarbeiten.

Der Vorbehalt, den die meisten Artikel überspringen, ist der wichtige. Hängen Sie keine KI-Abhängigkeiten an ein Produkt an, das sie nicht benötigt, und durchlaufen Sie jeden KI-Gem mit derselben Regel wie jede andere Abhängigkeit. Das Risiko ist nicht theoretisch. In Tests von Sonatype waren 27,8 % der Empfehlungen für Versions-Upgrades eines LLM-Gems auf Versionen bezogen, die nie veröffentlicht wurden, und einige wiesen auf tatsächlich kompromittierte Pakete hin. Ein KI-Codierungsagent, der zuversichtlich einen halluzinierten Gem empfiehlt, ist genau der Moment, um auf langweilige, verifizierte Entscheidungen zurückzugreifen.

Observability, Logging und Sicherheit in der Produktion

Für Apps, die wir pflegen, sind einige Kategorien nicht optional. Strukturiertes Logging mit Lograge, grundlegende Metriken und Fehlerverfolgung über etwas wie Sentry sind der Unterschied zwischen der Behebung eines Vorfalls in Minuten und dem Raten im Dunkeln. Diese Gems verdienen ihren Platz gerade deshalb, weil man sie nur bemerkt, wenn sie fehlen.

Die Abhängigkeitsprüfung gehört in die Pipeline, nicht ins Gedächtnis. Wir verwenden `bundler-audit`, um Gems mit bekannten Schwachstellen zu kennzeichnen, und Brakeman für die statische Sicherheitsanalyse, beides in CI integriert, sodass eine riskante Abhängigkeit den Build fehlschlagen lässt, anstatt die Produktion zu erreichen. Dies ist wichtiger für eine Agentur, die für Kunden liefert, als für ein Solo-Projekt, und es ist einer der Punkte auf unserer Checkliste für Ruby on Rails Code-Reviews, die wir als nicht verhandelbar betrachten.

Entwicklererfahrung und Tests

Die Testkultur dreht sich wirklich um die Qualität der App nach dem Ende unserer Beteiligung. Wir standardisieren auf RSpec mit FactoryBot für Fixtures, Capybara für System- und Browser-Tests und einen Profiler, wenn wir herausfinden müssen, wo die Zeit tatsächlich hingeht. Ziel ist eine Suite, der das eigene Team des Kunden vertrauen und die es erweitern kann.

Wir verwenden Bullet, um N+1-Abfragen in der Entwicklung aufzufangen, bevor sie zu Verlangsamungen in der Produktion werden, denn nichts untergräbt das Vertrauen in eine übernommene Codebasis schneller als eine Seite, die aus keinem ersichtlichen Grund langsam lädt. Gute Abdeckung und klare Abfragemuster sind das, was einen Übergang tatsächlich zu einem Übergang macht und nicht zu einem “Auf Wiedersehen und viel Glück”. Diese Wartbarkeit ist das eigentliche Ergebnis.

Die Rails-Gems, die wir tatsächlich ausliefern: Redwerks Produktions-Gemfile

Eine Gemfile über Jahre hinweg gesund halten

Der Teil der Arbeit, der die Arbeit einer Agentur definiert, ist die Aufrechterhaltung einer gesunden Gemfile lange nach dem Start. Wir behandeln Wartung als Routine und nicht als Rettungsmission, denn kleine und häufige Updates sind weitaus günstiger als der Versionssprung alle drei Jahre, der zu einer mehrmonatigen Migration wird. In der Praxis bedeutet dies einige feste Gewohnheiten:

Audit nach Zeitplan: Wir überprüfen Abhängigkeiten in einem festen Rhythmus, anstatt darauf zu warten, dass etwas kaputt geht. Wir führen `bundle outdated` und `bundler-audit` in CI aus, sodass veraltete Gems und bekannte Schwachstellen bei jedem Build angezeigt werden.
Schrittweise aktualisieren: Patch- und Minor-Versionen werden regelmäßig eingespielt, und Major-Versionen werden bewusst mit dem zuerst gelesenen Changelog geplant, sodass kein Upgrade eine Überraschung darstellt.
Die Routinearbeit automatisieren: Tools wie Dependabot oder Renovate öffnen Update-Pull-Requests für uns, was den Backlog sichtbar hält und die Diffs klein genug macht, um sie zu überprüfen.
Auf Aufgabe achten: Wir kennzeichnen Gems mit einem einzelnen Maintainer oder langer Stille und ersetzen sie dann gezielt, bevor eine nicht gewartete Abhängigkeit ein Rails- oder Ruby-Upgrade blockiert.
Ruby und Rails aktuell halten: Das Bleiben bei unterstützten Versionen des Frameworks und der Sprache vermeidet Sicherheits- und Kompatibilitäts-Endpunkte, die mit End-of-Life-Releases einhergehen.
Aussortieren, was niemand rechtfertigen kann: Jede Prüfung ist auch eine Gelegenheit, Gems zu entfernen, die niemand erklären kann, was die Angriffsfläche und die Wartungslast gleichzeitig reduziert.
Auf die Testsuite verlassen: Eine solide Abdeckung ist das, was all das oben Genannte sicher macht, da es uns ermöglicht, mit Zuversicht statt mit Hoffnung zu aktualisieren.

Bei übernommenen Kundenanwendungen zeigt sich die Wirkung dieser Disziplin. Die Apps, die nach fünf Jahren noch angenehm zu warten sind, sind diejenigen, bei denen jemand die Gemfile ehrlich gehalten hat, und diese Arbeit ist im Laufe der Zeit weitaus wichtiger, als sie jemals in einer Feature-Demo gezeigt wird.

Bauen Sie es mit einem Team, das wirklich Rails ausliefert

Eine gute Gemfile ist ein Zeichen für technisches Urteilsvermögen, und Urteilsvermögen ist es, was Sie wirklich einstellen, wenn Sie eine Agentur beauftragen. Bei Redwerk haben wir Jahre damit verbracht, Rails-Anwendungen zu erstellen und zu pflegen, bei denen Abhängigkeitsentscheidungen reale Konsequenzen hatten. Die Fallstudien erzählen diese Geschichte besser als jede Feature-Liste.

Wir haben den PlusPlus Slack Bot von einem Python-Prototyp, der nicht skalieren konnte, zu einem Rails-System umgebaut, das über eine Million Aktionen pro Minute verarbeitet. Wir haben das Backend und die RESTful-APIs für Cleanagents erstellt, damit eine Android-App selbstständige Reinigungskräfte in Deutschland und Österreich bedienen konnte. Und bei Adfectious, einer mobilen Werbeplattform, haben wir die Architektur und eine Banner-Verarbeitungs-Engine entworfen, mit Installationscode, der über Ruby on Rails, PHP, ASP, C# und JSP ausgeliefert wurde. Wenn Sie eine neue Rails-Entwicklung starten oder sich fragen, ob Ihre aktuelle Gemfile Ihnen hilft oder Sie kostet, kontaktieren Sie uns, und wir werfen einen Blick darauf.