Seite 3: Wenn MVC, dann IHP?

Inhaltsverzeichnis

IHP erfindet das Web-Development-Rad nicht neu, sondern der Zutatenmix folgt dem Beispiel vergleichbarer Frameworks wie Ruby on Rails, Phoenix, Play und Django:

• Model-View-Controller-Architektur,
• RESTful API mit CRUD-Semantik,
• datenbankzentrierter Ansatz mit einer ORM-ähnlichen Übersetzungsschicht,
• Convention over Configuration,
• Codegenerierung und
• Live Reloading.

Gerade der Rückgriff auf bekannte Konzepte und Vorgehensweisen erleichtert den Einstieg aus Haskell-fernen Gefilden. Niemand muss grundsätzlich neue Abstraktionen und Denkweisen lernen. Wer ein wenig Erfahrung mit einschlägigen Webframeworks hat, wird sich in IHP schnell zurechtfinden.

Der Paketmanager Nix wird gewinnbringend eingesetzt und bleibt dabei dezent im Hintergrund. Das Einbinden neuer Haskell-Pakete beispielsweise bedarf keiner tieferen Auseinandersetzung mit dem Tool. Weitere übliche Anwendungsfälle wie das Einbinden von konkreten Paketversionen oder Integrieren zusätzlicher Werkzeuge in die Entwicklungsumgebung zeigt die Dokumentation beispielhaft.

Der Einsatz von Haskell als Programmiersprache geht auf: Das Typsystem hilft Programmierfehler zu vermeiden, und die Code-Basis ist übersichtlich und verständlich. Eingefleischten Haskell-Entwicklerinnen und Entwicklern werden der MVC-Schnitt, die Namenskonventionen und weitere technische Details vielleicht nicht recht schmecken. Auch die Autorin hat ihre Reise zwischendurch genervt unterbrochen. Lässt man sich aber auf IHP ein, ist Haskell mit all seinen Freiheiten ganz nah. Und wenn alle Stricke reißen, bleibt der Notausstieg über die Wai-Middleware.

In Sachen Deployment hat sich mit dem Jahreswechsel einiges getan: Lange Zeit war die IHP Cloud die einzige kostenfreie Möglichkeit, um die eigene App zu veröffentlichen. Diese wurde im Februar diesen Jahres zugunsten anderer Optionen eingestellt. Neben der Docker-basierten Deployment-Option, die weiterhin der zahlenden IHP-Kundschaft vorbehalten ist, bietet IHP mittlerweile eine Anbindung an Shipnix. Wer einen Webserver sein Eigen nennt, kann die Anwendung alternativ per nix-build bauen und selbst betreiben. Alle Informationen zu den verschiedenen Möglichkeiten finden sich im Deployment Guide.

Insgesamt ist IHP eine interessante Option, wenn man einigermaßen mit funktionaler Programmierung vertraut und ein MVC-Web-Framework das Mittel der Wahl ist. Es ist nicht erforderlich, sich in die Tiefen von Haskell einzuarbeiten. Ausprobieren lohnt sich.

Das persönliche Fazit der Autorin: Für einfache Domänen und besonders dort, wo eine gerade Strecke von der Datenbank in ein (vorwiegend formularbasiertes) Webinterface erforderlich ist, wird sie in Zukunft auf IHP setzen. In diesem Sinne tatsächlich: Wenn MVC, dann IHP.

Bianca Lutz
verdient seit mehr als zehn Jahren ihre Brötchen als Softwareentwicklerin. Anfang 2022 ist sie ins Lager der funktionalen Entwicklung übergelaufen und bahnt sich seitdem ihren Weg durch Haskell-Code – Backend Webentwicklung – und robbt sich an Nix heran. MVC-Web-Frameworks kennt sie vor allem aus Zeiten, als man PHP und jQuery noch unter der Überschrift Webseitenmodernisierung in ein Angebot schreiben konnte. Ein kurzer Ausflug in die TypeScript-Welt hat Bianca das Fürchten gelehrt und ihr bewiesen, dass das Backend doch eher ihre Heimat ist, zumindest wenn es um komplexe Domänen geht.

(rme)