Unsere ersten Schritte mit Vue.js

Unser CRM-System wird seit Jahren fast ausschließlich in PHP entwickelt. Frontend und Backend sind in einem großen Software-Produkt vereint. Zur Erstellung von Benutzeroberflächen setzen wir ein selbst entwickeltes GUI-Framework ein. GUI-Elemente werden in PHP-Objekten abgebildet und jeder dieser Komponenten kann über eine Visualizer-Klasse in HTML / CSS / Javascript übersetzt werden. Bei der Entwicklung von Benutzeroberflächen mit bestehenden GUI-Komponenten muss der Entwickler so nur PHP-Objekte erstellen und konfigurieren. Bei der Erstellung von neuen Komponenten ist hingegen HTML, CSS und Javascript-Wissen notwendig.

Wir haben uns vor Jahren unter anderem für dieses System entschieden, um Umsteiger aus anderen Programmiersprachen ohne Web-Kenntnisse gut integrieren zu können. Insbesondere der Umstieg von Sprachen wie C# und Java ist hinsichtlich der GUI-Entwicklung leicht möglich. Da die Bedeutung der Web-Entwicklung über die letzten Jahre immer weiter zugenommen hat, hat sich dieser Effekt mittlerweile umgedreht. Steigen neue Entwickler mit Web-Kenntnissen ein, ist der Einarbeitungsaufwand recht hoch. Zudem wird in Bewerbungsgesprächen immer häufiger nach neueren Technologien gefragt.

Ein weiteres Problem dieses Systems ist, dass es zwar mehrere Schichten innerhalb des PHP-Systems gibt, aber keine harte Trennung zwischen Backend und Frontend in Form einer API oder durch unterschiedliche Programmiersprachen vorhanden ist. Dadurch kommt es immer wieder vor, dass sich die Logik der Schichten vermischt und die Abhängigkeit der Programmlogik zum GUI zu hoch ist oder umgekehrt Programmlogik in GUI-Komponenten abgebildet wird.
Daher haben wir uns dazu entschieden, uns bei neuen Projekten von unserem GUI-Framework zu verabschieden und auf ein bestehendes GUI-Framework umzusteigen.

Abstimmungen in einer Diskussionsgruppe

Wenn wir Änderungen dieser Art anstoßen, fragen wir in den Entwicklungsteams, wer mit diskutieren und recherchieren möchte. In den ersten Abstimmungsrunden haben wir Rahmenbedingungen und Ziele festgelegt, die wir mit dem neuen System erreichen wollen.

Mit dem neuen System soll der Einsatz einer klaren API (REST / JSON / GraphQL) forciert werden, um Frontend und Backend klarer zu trennen. Unsere bestehende API ist über die letzten Jahre für uns und unsere Kunden immer wichtiger geworden, sodass wir durch den Einsatz für unser Kernprodukt die technische Qualität weiter forcieren wollen – im API-First-Ansatz sehen wir nur Vorteile.

Eine möglichst saubere HTML- und CSS-Struktur und die Nutzung von HTTP-Caching oder Browser-Datenbanken als Beispiel für aktuellere Browser-Technologien soll erzielt werden. Die generierte Struktur der aktuellen GUI-Komponenten ist durch einen hohen Anteil an Inline-Styles oft nur sehr schwer wartbar.

Das wichtigste Kriterium für uns war aber, dass eine Kompatibilität zur aktuellen Struktur gegeben sein muss. Es soll möglich sein einzelne Ansichten im aktuellen enterprise-GUI mit der neuen Technologie umzusetzen. Eine komplette Neu-Entwicklung des CRM-GUIs würde uns zu lange blockieren, da wir immer das Ziel setzen, einzelne Teilprojekte so schnell wie möglich für Kunden verfügbar zu machen.

Die engere Auswahl

Als Kandidaten für die GUI-Schicht kristallisierten sich schnell React.JS und Vue.js heraus. Mit beiden Bibliotheken haben wir die Entwickler aus unserer Diskussionsrunde testen lassen und Vor- und Nachteile recherchiert:

• Bei Vue.js überzeugten uns direkt die sehr simple HTML-Struktur und der modulare Aufbau. GUI-Komponenten können gut getestet und automatisch neu gerendert werden, wenn sich Eigenschaften ändern. 
• Der Einstieg in React war etwas komplexer, auch die HTML-Struktur selbst sieht schon auf den ersten Blick etwas umfangreicher als vergleichbare Vue.js-Stukturen aus.

Auch wenn React weiter verbreitet ist, haben wir uns daher für Vue entschieden – auch mit Blick auf unser Entwicklungsteam.

Das erste interne Testprojekt

Um den doppelten Umbruch (Vue.js als GUI-Framework und Entwicklung einer neuen API) auszutesten, haben wir uns dafür entschieden, ein Testprojekt außerhalb unserer CRM-Software unter genau den Bedingungen zu starten. Wir haben eine interne Datenbankstruktur zur Konfiguration unserer Webseiten, für die schon länger eine Benutzeroberfläche für unsere Administratoren entwickelt werden sollte. Diese Benutzeroberfläche entwickeln wir gerade mit Vue.js. Zur Anbindung wird eine GraphQL-API erstellt. In einem Zweierteam sammeln wir so Erfahrung mit Vue.js und GraphQL, ohne eine direkte Abhängigkeit zu unserem CRM-Produkt und anderen Projekten zu haben. Während der Umsetzung trifft sich die erwähnte Diskussionsgruppe regelmäßig, um Themen zu besprechen, die im laufenden Projekt aufkommen: Einsatz von Apollo GraphQL, Javascript oder Typescript, welche Änderungen müssen an unseren Entwickler-Setups vorgenommen werden und so weiter.

Sobald diese erste Oberfläche fertig ist, wollen wir mindestens ein weiteres Projekt außerhalb unseres CRMs umsetzen und danach die erste Oberfläche in unserem enterprise-GUI mit Vue.js realisieren. Um das aufgebaute Wissen nach und nach zu erweitern, werden wir immer neue Zweier- oder Dreierteams bilden, in denen immer ein Teammitglied bereits Erfahrung mit Vue.js oder GraphQL hat.

Ausblick

Die ersten Schritte sind mit dem Testprojekt getan. Endgültig überzeugt haben Euphorie und Freude der beiden Entwickler des Testprojektes. Auch von Mitarbeitern, die außerhalb von onOffice bereits Erfahrung mit Vue.js gesammelt haben, kommen viele positive Rückmeldungen, die nächsten Monate werden spannend.

Die kommenden Herausforderungen (Javascript-Kenntnisse aufbauen / Architektur-Schichten sind durch die verschiedenen Sprachen fester vorgegeben) haben wir im Blick. Darüber hinaus wollen wir Wissen durch interne und externe Schulungen aufbauen, um das Risiko des großen Umbruchs weiter zu minimieren.