Ein guter Start ist die halbe Miete..
Solch oder so ähnliche Aussagen treffen auch bei der Entwicklung von Web-Anwendungen zu. Wer zu Beginn schon mit den richtigen Werkzeugen, in der passenden Umgebung und mit einer soliden Grundlage startet, erspart sich später eine mühsame Restrukturierung der App. Design Patterns und Best Practices allgemein werden in Boilerplates oft sehr genau genommen, was dem Entwickler klare Vorgaben mit auf den Weg gibt.
Mit diesem Mindset habe ich mir das „ultimative Boilerplate für Produkte“ Pup von cleverbeagle.com angesehen. Hierbei handelt es sich um eine Vorlage zur Entwicklung einer Webanwendung auf Basis von Meteor, React, MongoDB und GraphQL. In weiterer Folge will ich die Frage beantworten, inwieweit uns Boilerplates bei der Entwicklung von Prototypen helfen und wann sie uns behindern.
Was hat Clever Beagle’s Tool Pup zu bieten?
Mit der Installation von Pup (aktuell in der Version v2.0.1) erhält man den lauffähigen Quellcode einer kleinen Webanwendung zur Verwaltung von Markdown Dokumenten. Die App enthält dabei Komponenten um folgende Aufgabenstellungen zu realisieren:
- Benutzerregistrierung per OAuth und Benutzerverwaltung über ein Admin Panel
- Aussenden von E-Mails, basierend auf HTML- und Text-Vorlagen
- Automatische Generierung eines Datenbanksets und dessen Indizierung
- Tabellendefinitionen per GraphQL und eigenem GraphQL Playground
- Erstellung einer Sitemap und SEO Metadaten mit App-Details
- Routing Setup für öffentliche und authentifizierte Anfragen
- Server-side-Rendering (SSR) zur schnelleren Darstellung im Browser
- Formularvalidierung
- Styling und Individualisierung über Bootstrap und styled-components
- Browser-Richtlinien zum Schutz vor XSS
- Datenexport, Kontolöschung und Zustimmungserklärung laut GDPR/DSGVO
- Lokales git Repository mit eigenen Linter Script Hooks
- Unit- und Ende-zu-Ende (E2E) Tests
- Konfiguration für Development/Staging/Production Settings
- Kompletter Workflow zum App Release und zur kontinuierlichen Integration inklusive DNS Einträge, SSL Zertifikat und Hosting auf Meteor Galaxy (Erfordert weitere Zugangsdaten)
Diese Liste wird laufend erweitert, da Pup hier stets bemüht ist, die Entwickler noch mehr zu entlasten und weitere Bereiche durch das Boilerplate abdecken zu lassen.
Die ELWMS
Die Vorteile beim Einsatz einer so umfangreichen Basis sind klar: Als Entwickler muss man sich um viele Dinge, die früher oder später ohnehin zu einer soliden Web Anwendung gehören, nicht mehr kümmern. Wenn das Boilerplate zu dem noch laufend weiterentwickelt wird, beantwortet es auch die Frage „Wie macht man das denn jetzt richtig?“ Denn im derzeitigen Javascript-Umfeld sind aktuelle und gut aufeinander abgestimmte Module und Bibliotheken sehr wichtig.
Pup richtet sich ganz klar an Web Anwendungen im Produktionsumfeld. Das heißt diese App kann auf Knopfdruck live gehen. Was ist jedoch, wenn wir gar keine „solide App“ entwickeln wollen? Wenn wir einen Prototypen erstellen, geht es meist um schnelle, nachweisbare Funktionalität, eventuell um etwas herzuzeigen oder um etwas zu testen. Die meisten dieser Prototypen verschwinden auch lange vor einem tatsächlichen Roll-Out oder werden in einer weiteren Phase von Grund auf neu entwickelt. In diesem Fall kostet uns ein zu umfangreiches Boilerplate eine Menge – eine Menge Zeit.
$ meteor npm install added 2111 packages from 905 contributors in 129.893s $ ...
Die Installation ist denkbar einfach – allerdings sehr umfangreich. Mit Pup werden über 2.100 npm Pakete installiert – das sind über 60.000 Javascript Dateien mit über 5.000.000 Zeilen Code. Ein „Kaltstart“ (nach meteor reset) der meteor-Entwicklungsumgebung dauert etwa 6 Minuten. Ab dann ist die Webapplikation auf der lokalen Maschine erreichbar. Der Node.js Service läuft, selbst ohne weiteres Zutun auf der Webseite, auf Hochtouren und benötigt auch nicht wenige Ressourcen:
Im Vergleich, ein leeres Meteor/React Projekt braucht auf unseren Entwicklungsmaschinen hierfür eine knappe Minute. Dies wird durch die Kompilierung, die Paketierung und das finale Deployment besser. Jedoch sind diese Punkte für die Entwicklung unseres Prototypen vorerst nebensächlich. Hier wollen wir ausprobieren und schnelle Erfolge feiern. Leider hindert uns der, an sich gute, Einsatz von Design Patterns und umfangreichen Verzeichnisstrukturen oftmals daran. Wir habens ausprobiert – für die Darstellung und Bearbeitung zwei zusätzlicher Listen im Frontend mussten insgesamt 20 neue Javascript und GraphQL Dateien angelegt und zwölf bestehende bearbeitet werden, um allen aufgestellten Coding Guidelines zu entsprechen.
Bei der Umsetzung eines Prototypen ist nun selbst abzuwägen, ob das Befolgen dieser Guidelines während der gesamten Entwicklungszeit Sinn macht oder nicht, um den späteren Umbau auf eine produktive App zu erleichtern.
Zusammengefasst: Die schlanke ELWMS
Boilerplates sind gut – im gesunden Maße und jedenfalls als Nachschlagewerk. Ein Prototyp muss nicht bei Null beginnen. Gerade im Node.js Umfeld gibt es eine Vielzahl an Vorlagen. Gleichzeitig darf die Entwicklung aber auch nicht durch zu viele Vorgaben behindert werden. Besser ist es mit einem möglichst kleinen Boilerplate zu starten und sich stückweise, sobald sich der Bedarf für ein weiteres Modul ergibt, Teile vom „ultimativen“ Pup Nachschlagewerk zu holen. Es mal auszuprobieren, um zu sehen was möglich ist, zahlt sich in jedem Fall aus! Ich denke es ist besser die Regeln zu kennen und selbst zu entscheiden sie nicht zu befolgen, als nicht zu wissen was falsch ist.
Vorschläge für Pup
Folgende Punkte sind mir beim Einsatz von Pup aufgefallen:
In der Dokumentation zum GraphQL Playground wird darauf hingewiesen: der aktuell authentifizierte User wird bei Abfragen nicht mitgeschickt. Damit sind keine Abfragen möglich, die einen solchen User benötigen. In der App betrifft das leider alle Daten – dadurch wird der Playground ziemlich funktionslos. Der Hinweis, dass man Daten erst ohne Authentifizierung bereitstellt und diese erst im nächsten Schritt einbaut, widerstrebt der Nutzung des Boilerplates.
Login über OAuth: diese werden laut Dokumentation über die Applikations Einstellungen gesteuert. Tatsächlich finden sich an mehreren Stellen im Quellcode jeweils eigene Listen mit angezeigten Möglichkeiten für Registrierung, Login und Callbacks.
Die Dokumentation auf der Webseite ist durchaus umfangreich – jedoch wird der tatsächlich eingesetzte Quelltext dadurch nicht immer klar. Im Quelltext des Boilerplates selbst finden sich wiederum kaum Kommentare oder Hinweise auf das zugrunde liegendes Kapitel, was bei Unklarheiten oft das händische Durchsuchen der gesamten Dokumentation erfordert. Im Vergleich dazu machen es die Meteor Tutorials besser, wobei hier die Codebasis klarerweise um ein Vielfaches kleiner ist.
Weiters sind auch Punkte aufgefallen die den Entwicklern schon bekannt sind und vielleicht bald erledigt werden. Dazu gehören die getrennte Datenvalidierung im Client und auf Datenbankebene und die Gesamtperformance der Web Anwendung.
Über qnipp
Wir beschäftigen uns mit dem Bau von Prototypen für Webanwendungen und mobile Apps und evaluieren daher regelmäßig Technologien und Werkzeuge in diesem Bereich. Wenn Sie Interesse an unseren Dienstleistungen haben, kontaktieren Sie uns unter office@qnipp.com.