Coding Chronicles [5]: Nach 2 Jahren Funkstille
Es ist verdammt ruhig geworden hier im Blog. Die letzte "Coding Chronicle" ist eine gefühlte Ewigkeit her und auch meine Ausflüge in die Welt von Node.js und Strapi liegen schon etwas zurück. Der Grund dafür ist simpel: Das Leben und die Arbeit kam dazwischen.
Im selben Jahr, in dem ich meine Docker-Setups optimiert habe, stand nämlich ein großer Tapetenwechsel an: Ich habe meinen Arbeitgeber gewechselt und bin von STAUDACHER zu Condat gegangen.
Die gute Nachricht vorweg: Ich bin Laravel treu geblieben. Das Backend bei Condat setzte glücklicherweise auf mein Lieblings-PHP-Framework. Das Spannende daran war, dass das System noch sehr "formbar" war, also konnte ich aktiv mitgestalten.
Die ersten Wochen und Monate war ich fast ausschließlich damit beschäftigt, eine einheitliche Modul-Struktur festzulegen und die bestehenden Module dort zu integrieren. Zusätzlich dazu sind satte 1703 Tests entstanden. Zukünftigen Refactorings steht also nichts mehr im Weg 😅.
Während ich mich im Backend wie zu Hause fühlte, gab es im Frontend für mich als leidenschaftlichen Vue-Entwickler einen kleinen Kulturschock. Firmenweit wird hier nämlich React eingesetzt.
Mein erster Gedanke beim Blick in den Code:Warum muss das alles so kompliziert sein?
Hooks, State-Management, JSX – auf den ersten Blick wirkte alles viel verbauter als die Eleganz von Vue. Natürlich habe
ich (vielleicht etwas zu optimistisch) gefragt, ob wir nicht auf Vue setzen wollen. Aber scheinbar hatte die Firma das
Experiment "Vue" in der Vergangenheit schon einmal gewagt und sich dagegen entschieden. Da ließ sich also nichts machen.
Mittlerweile habe ich meinen Frieden damit gemacht. Ich lerne React, auch wenn mein Herz wohl immer ein bisschen mehr für Vue schlagen wird.
In meinen letzten Artikeln ging es viel um Server, Docker und Traefik. Bei Condat gibt es dafür eine eigene DevOps-Abteilung. Das ist einerseits purer Luxus, weil man sich nicht mehr selbst um jeden Server-Restart kümmern muss. Andererseits fehlt mir das Basteln während der Arbeitszeit ein wenig.
Aktuell habe ich dort nur einen Fuß in der Tür, da mein Fokus stark auf Backend-Konzepten inkl. der Umsetzung lag. Aber ich bin mir sicher, dass ich mir von den Jungs und Mädels dort noch eine Menge abschauen kann, sobald der Projektalltag es zulässt.
Nachdem ich mich eingelebt und die Modul-Struktur etabliert hatte, fiel mir auf, dass wir (wie fast alle Entwickler) immer wieder den gleichen Boilerplate-Code für APIs schrieben: Controller anlegen, Requests validieren, Ressourcen transformieren, Swagger-Docs schreiben...
Also habe ich ein internes CRUD-Modul entwickelt mit der Idee: Man gibt im Model einfach eine Config an (z.B. welche
Felder filterbar sind, wer was darf) und das Modul erledigt den Rest.
Es generiert automatisch RESTful-API-Endpunkte, kümmert sich um Validierung via Interface, erlaubt komplexe Filterung
und spuckt am Ende sogar die fertige Swagger-Dokumentation aus. Einmal durch den Wizzard viaphp artisan crud:scaffold
und der Endpunkt steht in unter einer Minute.
Da das Ganze aber proprietärer Firmencode ist, darf ich das Modul leider nicht veröffentlichen. Aber es hat mich angefixt, wieder mehr eigene Tools zu bauen.
Deshalb habe ich mir ein neues Package ausgedacht, an dem ich gerade in meiner Freizeit arbeite und das ich diesmal als Open Source veröffentlichen werde. Es geht um Daten-Imports – also quasi das Gegenstück zum Ausspielen von Daten.
Das war mein Update nach zwei Jahren Funkstille. Schaltet auch beim nächsten Mal wieder ein, wenn es heißt: Vorstellung von Laravel Ingest 👋