Wat is Ruby on Rails?

Ruby on Rails is een framework voor het bouwen van webapplicaties, gemaakt door David Heinemeier Hansson en in 2004 vrijgegeven als open source. Het draait op de programmeertaal Ruby en neemt je vrijwel al het opzetwerk uit handen.

Rails is bekend geworden om één belofte: snel iets bouwen dat werkt. Basecamp, GitHub, Shopify en GitLab zijn ermee begonnen en draaien er nog altijd op. Hieronder staat hoe het in elkaar zit, wat je eraan hebt en wanneer je beter iets anders kiest.

Wat een framework is

Een framework is een verzameling kant-en-klare onderdelen plus een afspraak over hoe je ze gebruikt. Het verschil met een losse bibliotheek zit in wie de baas is. Rails bepaalt de indeling van je project en de plek waar je code hoort te staan, en jij vult in wat jouw toepassing eigen maakt.

In de praktijk merk je dat meteen. Bij Rails schrijf jij alleen het stuk dat uniek is voor jouw toepassing. Het verzoek binnenhalen, de sessie bijhouden, de database openen, het antwoord terugsturen: dat staat er al. Meer over dat onderscheid staat bij webontwikkelingsbibliotheken.

Waar Rails vandaan komt

Rails is niet bedacht als product. David Heinemeier Hansson bouwde het projectbeheerpakket Basecamp en haalde daar in 2004 de algemene onderdelen uit. Dat is te merken aan de keuzes: alles is gericht op wat een klein team met een echte applicatie nodig heeft.

De taal eronder is ouder. Yukihiro Matsumoto bracht Ruby in 1995 uit met als uitgangspunt dat programmeren prettig moet zijn om te doen. Ruby leest bijna als Engels en dat verklaart een deel van de aantrekkingskracht.

Daarna kwamen er versies met steeds een eigen accent. Rails 4 uit 2013 maakte de omgang met formuliergegevens strenger. Rails 5 uit 2016 voegde een modus zonder schermen toe, voor applicaties die alleen een API hoeven te zijn. Rails 7 uit december 2021 gooide de voorkant om en maakte JavaScript zonder bouwstap de standaard.

De laatste grote versie is Rails 8 uit november 2024. Die haalde losse hulpdiensten als Redis uit de standaardopstelling en verving ze door de database zelf, en voegde een generator voor inloggen toe.

De twee regels waar alles op rust

De eerste is dat afspraak boven instelling gaat. Noem je klasse Bestelling en je tabel bestellingen, dan weet Rails zonder dat je iets instelt dat die twee bij elkaar horen. Er is geen bestand waarin je die koppeling vastlegt.

Dat is de reden dat er bij Rails na een paar opdrachten een werkende applicatie staat, terwijl je bij andere talen eerst een uur bezig bent met inrichten. De prijs is dat je je aan de afspraken houdt. Wijk je ervan af, dan moet je het alsnog allemaal opschrijven.

De tweede regel is dat je jezelf niet herhaalt. Eén plek waar iets is vastgelegd, en de rest volgt daaruit. Voeg je een kolom toe aan een tabel, dan kent je model dat veld meteen.

Ik vind dat de sterkste kant van Rails, en tegelijk de reden dat het niet voor iedereen werkt. Je krijgt snelheid in ruil voor vrijheid. Wie graag alles zelf bepaalt, ergert zich aan de magie die op de achtergrond gebeurt.

Model, view en controller

Rails deelt je applicatie op in drie soorten bestanden. Die verdeling heet model-view-controller en je vindt hem in de mappen van elk Rails-project terug.

Het model is je gegevens en de regels eromheen, gekoppeld aan een tabel in je database. Hier staat dat een e-mailadres verplicht is, dat een bestelling bij een klant hoort en dat een bedrag niet negatief mag zijn.

De view is wat de bezoeker ziet. Een sjabloon met HTML waar de gegevens ingevuld worden.

De controller zit ertussen. Hij ontvangt het verzoek, vraagt het model om gegevens en kiest welke view eroverheen gaat.

De winst van die verdeling merk je pas na een jaar of twee. Als je weet dat rekenregels in het model horen, hoef je bij een fout niet te zoeken in welk van de veertig bestanden hij zit. Elke Rails-ontwikkelaar die je later inhuurt vindt de weg meteen.

Hoe Rails met je database praat

Het onderdeel dat je gegevens beheert heet Active Record. Het vertaalt Ruby-code naar databaseopdrachten, zodat je zelf geen SQL hoeft te schrijven. Een regel als Klant.where(plaats: "Utrecht") wordt onder water een zoekopdracht op je tabel.

Dat heeft twee voordelen. Je code blijft leesbaar, en Active Record zet de waarden die uit een formulier komen apart in de opdracht. Daardoor is een van de oudste aanvallen op websites, waarbij iemand databaseopdrachten in een invoerveld typt, standaard afgedekt.

Tabellen wijzig je met migraties: kleine bestanden waarin staat wat er moet veranderen, zoals een kolom erbij of een index erop. Je draait ze in volgorde en je kunt ze terugdraaien. Ze horen bij je code in versiebeheer, dus zet een collega het project op zijn eigen laptop, dan krijgt hij dezelfde tabellen als jij.

In ontwikkeling gebruiken de meeste mensen SQLite omdat het nul instellingen vraagt. In productie is PostgreSQL de gebruikelijke keuze. Sinds Rails 8 is SQLite ook op een echte server bruikbaar geworden, wat voor kleine toepassingen een hoop gedoe scheelt.

Routes, adressen en de zeven acties

Het routeringssysteem koppelt webadressen aan code. Alles staat in één bestand, config/routes.rb, en dat is bij een onbekend project meteen de plek waar ik kijk: je ziet er in dertig regels wat de applicatie kan.

Van adres naar actie

Een webadres bestaat uit een protocol, een domein en een pad, met eventueel nog een deel achter een vraagteken. Rails leest het pad plus de HTTP-methode van het verzoek. Hetzelfde adres met GET of met DELETE komt dus bij een andere actie uit.

Je kunt elk adres los opschrijven, maar dat doet vrijwel niemand. Eén regel met het woord resources maakt in één keer zeven routes aan: overzicht, detailpagina, formulier voor nieuw, opslaan, formulier voor wijzigen, bijwerken en verwijderen.

Die zeven staan niet toevallig zo. Ze volgen de manier waarop het web bedoeld is: een adres wijst een ding aan, en de methode zegt wat je ermee wilt. Sinds Rails 4 wordt PATCH gebruikt voor bijwerken, omdat je meestal een paar velden aanpast en niet het hele object vervangt.

Adreshulpen

Bij elke route hoort een hulpmethode met een naam, bijvoorbeeld klanten_path. Die gebruik je in je views in plaats van het adres uit te typen. Verander je later het pad, dan hoef je maar op één plek iets aan te passen en werken alle links nog. Handmatig ingetypte adressen zijn in elk project de eerste dingen die verouderen.

CRUD: de vier handelingen

Vrijwel elke webapplicatie doet vier dingen met gegevens: aanmaken, tonen, wijzigen en verwijderen. In het Engels create, read, update en delete, afgekort tot CRUD. Een boekingssysteem, een webshop en een ledenadministratie zijn onder de motorkap allemaal CRUD met regels eromheen.

Rails is daar bijzonder goed in. Met één opdracht, rails generate scaffold, krijg je een model, een tabel, een controller met de zeven acties en werkende schermen. Dat is ruwe bouw en geen eindproduct. Daarom werd Rails populair bij startende bedrijven: je kunt een idee in een week aan echte gebruikers laten zien in plaats van in een kwartaal.

Inloggen en rechten

Zodra een applicatie gebruikers heeft, heb je twee dingen nodig. Authenticatie is de vraag wie je bent, autorisatie is de vraag wat je mag.

Voor het eerste zit er in Rails al jaren een onderdeel dat wachtwoorden door een eenrichtingsberekening haalt voordat ze in de database gaan. Ze staan daar dus nooit leesbaar, en bij een lek kan niemand ze terugrekenen. Sinds Rails 8 zit er ook een generator in die complete inlogschermen met wachtwoordherstel neerzet. Daarvoor gebruikte bijna iedereen de gem Devise, die nog steeds veel wordt ingezet.

Voor rechten kies je meestal Pundit of CanCanCan. Daarmee leg je op één plek vast wie welk item mag zien en wijzigen, in plaats van in elke controller een reeks vragen. Zo voorkom je dat iemand door een nummer in de adresbalk te veranderen de gegevens van een ander ziet.

Dat laatste is meteen een AVG-punt. Werk je met persoonsgegevens, dan hoort bij passende beveiliging dat iemand alleen bij zijn eigen gegevens kan. Een lek dat ontstaat doordat een rechtencontrole ontbreekt, is een datalek dat je bij de Autoriteit Persoonsgegevens moet melden.

Gems: de bibliotheken van Rails

Kant-en-klare uitbreidingen heten gems. Er zijn er tienduizenden en ze doen alles: betalingen, PDF's maken, achtergrondtaken, beheerschermen, zoeken. Je noteert ze in een bestand met de naam Gemfile en de tool Bundler haalt ze op en legt de exacte versies vast. Daardoor draait jouw laptop dezelfde versies als de server.

Er zit een risico aan. Elke gem is code van iemand anders met volledige toegang tot je applicatie. Kijk wanneer de laatste versie uitkwam en houd het aantal beperkt. Ik heb vaker een project moeten redden dat vastliep op een verlaten gem dan op eigen code.

Koppelen met betaaldiensten en andere systemen

Een applicatie staat zelden alleen. Betalen, mailen, factureren, bezorgen: dat gaat via andere partijen, en Rails praat gewoon met hun API.

Bij betalen werkt dat overal hetzelfde. Je stuurt vanaf je server een verzoek met het bedrag en een verwijzing naar je eigen bestelling. De klant rekent af bij de betaaldienst. Daarna krijg je een bericht terug op een adres dat jij hebt opgegeven, en pas op dat moment zet je de bestelling op betaald.

Twee dingen gaan daar vaak mis. Mensen vinken de bestelling af zodra de klant terugkeert naar de site, wat je kunt vervalsen door zelf dat adres op te roepen. Of het bericht komt dubbel binnen en de bestelling wordt twee keer verwerkt. Beide los je op door alleen het serverbericht te vertrouwen en elke melding maar één keer uit te voeren.

In Nederland is Mollie voor kleine bedrijven vaak praktischer dan Stripe, omdat iDEAL hier de standaard is. Werk dat langer duurt dan een halve seconde, zoals een PDF maken of een reeks mails versturen, zet je in een achtergrondtaak. Anders staat de bezoeker te wachten op iets waar hij niets mee te maken heeft.

Snelheid en schaal

Rails heeft de naam traag te zijn. Ruby is als taal inderdaad langzamer dan Go of Java, en in de praktijk zit het probleem bijna nooit in de taal.

De database is meestal de boosdoener

De klassieke fout heet het n plus 1 probleem. Je haalt honderd bestellingen op en vraagt vervolgens per bestelling de klantnaam op. Dat zijn honderdeen zoekopdrachten waar er twee hadden kunnen volstaan.

Active Record kan die bijbehorende gegevens in één keer meenemen, en er zijn gems die je waarschuwen zodra het misgaat. Verder gelden de gewone regels: zet een index op kolommen waarop je zoekt, en kijk af en toe welke opdrachten het langst duren.

Caching en meer servers

Rails kan stukken van een pagina bewaren en hergebruiken. Een lijst met producten die één keer per dag verandert hoef je niet bij elk bezoek opnieuw op te bouwen. Vroeger had je daar Redis of Memcached bij nodig, een aparte dienst naast je applicatie. Sinds Rails 8 kan het ook in je gewone database, wat voor een kleine toepassing één systeem minder betekent dat je moet beheren en betalen.

Wordt het drukker, dan zet je er servers naast met een verdeler ervoor die het verkeer spreidt. Dat werkt alleen als je applicatie niets in het geheugen van één server bewaart. Sessies horen dus in een cookie of in de database, en geüploade bestanden op een opslagdienst en niet op de schijf van de webserver.

Sinds Ruby 3.1 uit 2021 zit er bovendien een just-in-time-compiler in de taal, YJIT genaamd, gebouwd door de mensen van Shopify. Vanaf Ruby 3.2 uit 2022 is die geschikt voor productie. Voor de meeste applicaties is dat een knop die je aanzet.

Waar je een Rails-applicatie draait

Hier zit voor Nederlandse ondernemers de grootste verrassing. Gewone webhosting is bijna altijd ingericht op PHP en MySQL. Een Rails-applicatie kun je daar niet zomaar neerzetten.

Je hebt een eigen server nodig of een platform dat de server voor je regelt. Heroku was jarenlang de standaard voor dat laatste, tot dat bedrijf eind 2022 zijn gratis pakketten stopzette en veel mensen wegtrokken. Sinds Rails 8 hoort er een eigen uitrolgereedschap bij, Kamal genaamd, waarmee je je applicatie in een container naar een gewone huurserver duwt.

Let bij die keuze op waar de server staat. Staan er persoonsgegevens van Nederlandse klanten in je database, dan bespaart een Europese locatie je een hoop uitzoekwerk, en met je hostingpartij sluit je een verwerkersovereenkomst. Reken op hogere kosten dan bij gedeelde hosting: je huurt een machine in plaats van een plekje.

Hoe veilig het is

Rails heeft een goede naam op dit punt, omdat de standaardinstellingen de bekende gaten dichten. Tekst uit de database wordt onschadelijk gemaakt voordat hij in een pagina belandt. Formulieren krijgen een token mee waarmee wordt gecontroleerd dat het verzoek van je eigen site komt. En sinds Rails 4 moet je per formulier opschrijven welke velden je accepteert.

Die laatste maatregel kwam er na een incident in 2012, waarbij iemand via een formulier op GitHub gegevens kon aanpassen die daar niet voor bedoeld waren. Sindsdien is niets accepteren de standaard.

Wachtwoorden en sleutels van andere diensten horen niet in je code. Rails heeft daar sinds versie 5.2 uit 2018 een versleuteld bestand voor, waarvan de sleutel buiten je repository blijft. Er zit bij nieuwe projecten ook een scanner bij die je code doorloopt op bekende fouten.

Het grootste risico blijft achterstallig onderhoud. Een Rails-applicatie die drie jaar niet is bijgewerkt draait op versies met bekende lekken. Reken bij een eigen applicatie op een vast bedrag per jaar voor updates, net zoals je dat bij het beveiligen van een WordPress-website doet.

Wat een Rails-ontwikkelaar doet

Een Rails-ontwikkelaar bouwt de achterkant van een applicatie: de gegevens, de regels en de schermen eromheen. Bij Rails loopt dat werk verder door naar de voorkant dan bij veel andere opstellingen, omdat de pagina's op de server worden opgebouwd. Wat dat onderscheid inhoudt staat bij back-end ontwikkeling.

In de praktijk zoek je meestal iemand die beide kanten aankan, omdat een Rails-project zelden groot genoeg is voor twee gespecialiseerde mensen. Vraag bij het inhuren naar tests. Rails heeft een testkader ingebouwd en er is een populair alternatief dat RSpec heet. Een project zonder tests is bij elke wijziging een gok, en dat merk je pas als de bouwer weg is.

Waarom je Rails minder tegenkomt

Rails is niet dood, en het is wel voorbij zijn hoogtepunt. Rond 2010 was het de vanzelfsprekende keuze voor een nieuwe webapplicatie.

Daarna kwamen de JavaScript-frameworks op. Met Node.js aan de achterkant kon je voorkant en achterkant in één taal bouwen, en dat trok veel ontwikkelaars weg.

Er was ook een verhaal dat is blijven hangen. Twitter verplaatste in 2011 zijn zoekfunctie van Rails naar Java, en dat werd jarenlang aangehaald als bewijs dat Rails niet schaalt. Shopify draait er nog steeds op en verwerkt op zijn drukste dag meer bestellingen dan de meeste bedrijven in een jaar, dus dat argument is niet houdbaar.

Voor een Nederlandse ondernemer telt iets anders zwaarder: het aanbod. Er zijn hier veel meer mensen te vinden die PHP of JavaScript kennen dan Ruby. De vraag is niet of Rails goed is, maar of je over drie jaar nog iemand vindt die ermee overweg kan.

Wanneer je het kiest en wanneer niet

Waar het nog steeds loont

Bij een applicatie die snel moet staan en waar veel standaardwerk in zit: gebruikers, rechten, formulieren, beheerschermen. Daar is Rails uitzonderlijk snel, en dat verschil is groot genoeg om andere bezwaren te overstemmen.

Bij een klein team dat het al kent. Bekende techniek verslaat in de praktijk bijna altijd betere techniek.

En bij projecten waar de voorkant eenvoudig mag blijven. Sinds versie 7 zit er gereedschap bij waarmee je losse stukjes van een pagina kunt verversen zonder een apart JavaScript-project. Voor een beheerscherm of een boekingssysteem is dat ruim voldoende.

Waar je iets anders kiest

Voor een gewone website of webshop. Daar is een contentmanagementsysteem praktischer, want je klant wil zelf zijn teksten kunnen aanpassen zonder een ontwikkelaar te bellen. Wat de verschillen tussen de varianten van het bekendste pakket zijn, staat bij WordPress.com en WordPress.org.

Voor iets kleins dat op gewone hosting moet draaien, want de rekensom valt dan snel de andere kant op. En als je in Nederland makkelijk mensen wilt kunnen vinden. Dan liggen PHP met Laravel of JavaScript met Node meer voor de hand. Dat is geen technisch oordeel maar een zakelijk oordeel, en dat is bij een applicatie die tien jaar mee moet het oordeel dat telt.

Als je het wilt leren

Leer eerst Ruby zelf. De taal is prettig leesbaar en dat maakt de instap zacht. Je hoeft niet alles te kennen; blokken, hashes en het idee dat alles een object is brengen je een heel eind.

Volg daarna de officiële handleiding op de site van Rails. Die wordt goed onderhouden en is uitgebreider dan de meeste betaalde cursussen.

Bouw meteen iets dat je zelf wilt hebben. Een cursus afmaken levert minder op dan één keer vastlopen op een echt probleem en er weer uitkomen.

Veelgestelde vragen over Ruby on Rails

Is Ruby hetzelfde als Ruby on Rails?

Nee. Ruby is de programmeertaal, Ruby on Rails is een framework dat in die taal is geschreven. Je kunt Ruby prima gebruiken zonder Rails, bijvoorbeeld voor scripts of gereedschap op de opdrachtregel. Andersom kan niet.

Is Ruby on Rails dood?

Nee. Er verschijnen nog steeds grote versies, de laatste in november 2024, en bedrijven als Shopify en GitLab draaien er hun hele bedrijf op. Wat wel klopt is dat het aandeel in nieuwe projecten is gedaald en dat je in vacatures veel vaker PHP of JavaScript ziet.

Kan ik Ruby on Rails op gewone webhosting draaien?

Meestal niet. Nederlandse gedeelde hosting is ingericht op PHP en MySQL. Je hebt een eigen server nodig, een container-omgeving of een platform dat dat voor je regelt. Reken op hogere maandkosten dan bij een WordPress-site.

Is Ruby on Rails moeilijk te leren?

De taal is een van de vriendelijkste die er is, het framework is dat minder. Rails doet veel op de achtergrond, en zolang je niet weet wat er gebeurt voelt dat als magie.

Wat is het verschil tussen Rails en Laravel?

Laravel is het bekendste PHP-framework en heeft veel van Rails overgenomen, tot de indeling van de mappen aan toe. Het verschil zit in de taal eronder en in het aanbod aan mensen. Voor een Nederlands bedrijf is Laravel meestal de veiligere keuze, omdat je makkelijker iemand vindt.

Wat is het verschil tussen Rails en Django?

Django is het vergelijkbare framework voor Python. Het grootste zichtbare verschil is dat Django een compleet beheerscherm meelevert waarmee je meteen je gegevens kunt bewerken, terwijl Rails je die vrijheid zelf laat invullen. Kies Python als je ook iets met data-analyse wilt, want daar is dat ecosysteem sterker.

Welke database gebruik ik bij Rails?

PostgreSQL is de gebruikelijke keuze in productie. MySQL werkt ook. SQLite is prima om mee te ontwikkelen en sinds Rails 8 voor kleinere toepassingen ook op een echte server bruikbaar.

Is Ruby on Rails traag?

Ruby is als taal langzamer dan Go of Java, maar bij een trage Rails-applicatie ligt de oorzaak vrijwel altijd bij de database of bij te weinig caching. Sinds Ruby 3.2 uit 2022 zit er bovendien een compiler in die het rekenwerk merkbaar versnelt.

Wat is een gem?

Een gem is een kant-en-klaar stuk Ruby-code dat je in je project opneemt, vergelijkbaar met een plugin. Je zet de naam in je Gemfile en de tool Bundler haalt de juiste versie op. Er zijn gems voor betalingen, inloggen, achtergrondtaken en vrijwel alles wat vaker voorkomt.

Kan ik een webshop bouwen met Ruby on Rails?

Dat kan, en voor een gewone webshop raad ik het af. Een bestaand pakket geeft je betaalmethoden, verzendkoppelingen en btw-regels al kant-en-klaar. Bouwen op maat wordt pas interessant als je iets verkoopt dat niet in een standaardwinkel past.

Heb ik JavaScript nodig als ik Rails gebruik?

Minder dan bij de meeste andere opstellingen. Rails bouwt pagina's op de server op en levert sinds versie 7 gereedschap mee waarmee je delen van een pagina kunt bijwerken zonder een apart JavaScript-project. Voor een echt interactieve interface, bijvoorbeeld een tekenprogramma of een editor, ontkom je er niet aan.

Wat kost het om een Rails-applicatie te laten bouwen?

Dat hangt volledig af van wat de applicatie moet doen, en de bouw is niet de grootste kostenpost. Reken op onderhoud, hosting en updates zolang het ding draait. Vraag bij een offerte altijd wat er na oplevering gebeurt met beveiligingsupdates en wie de code in beheer heeft.

Kan ik later van Rails naar iets anders overstappen?

Dat kan, en het is een herbouw en geen omzetting. Je gegevens neem je mee, want die zitten in een gewone database. De code schrijf je opnieuw. Dat is een reden om bij de start goed na te denken over de taal, want die keuze zit er voor de hele levensduur in.