Zurück zum Blog
Blog

Laravel Ingest – Release-Fails und neue Synergien

2026-02-08
4 min Lesezeit

Im letzten Beitrag hatte ich groß angekündigt: "Beim nächsten Mal: Vorstellung von Laravel Ingest".

Nun, wer sich auf meiner Seite umsieht, wird merken: Das Projekt ist bereits online. Ich spare mir an dieser Stelle also die tiefen technischen Details (die könnt ihr dort oder in der Dokumentation nachlesen). Stattdessen erzähle ich euch heute die Geschichte hinter dem Release – und warum man manchmal erst scheitern muss, um den besseren Weg zu finden.

Aber erst mal: Alles neu hier! 🎨 Wie im letzten Artikel erwähnt, bin ich beruflich im React-Lager gelandet. Mein alter Blog lief auf Ghost, was super war, aber ich sah keinen Mehrwert mehr darin. Vor allem wollte ich meine Projekte (wie eben Ingest) nahtlos als Subpages integrieren und nicht auf eine externe Plattform verlinken. Also habe ich die letzten Tage genutzt, Vue "Lebewohl" gesagt und die komplette Seite mit React und Next.js neu gebaut.

Die Idee zu Laravel Ingest kam nicht aus dem Nichts. Im letzten Beitrag hatte ich von dem internen CRUD-Modul erzählt, das ich auf der Arbeit entwickelt habe. Es hat mich extrem angefixt, Tools zu bauen, die anderen Entwicklern Arbeit abnehmen – einfach eine Config definieren und die Magie passiert im Hintergrund.

Das Problem: Das CRUD-Modul gehört der Firma und wird die Welt der Open Source nie sehen. Ich wollte aber unbedingt etwas Eigenes publishen. Etwas, das ich vorzeigen kann. Und wenn ich ganz ehrlich bin: Ich wollte endlich das Starstruck Achievement auf GitHub freischalten 😅.

Inspiriert von der Arbeit im 9-5 Job und der Architektur meines CRUD-Moduls, wollte ich dieses Prinzip auf ein anderes Problem übertragen: Daten-Importe. Das Ziel war ein Framework, das sich genauso einfach anfühlt und robust ist.

Refined wurde das Konzept mit Gemini 3 Pro. Und das ist gefährlich. Sehr gefährlich. Man kommt vom Hundertsten ins Tausendste. Gemini spuckt Ideen aus, man denkt "Geil, das muss auch noch rein!", und plötzlich hat man eine Roadmap bis 2030. Mit meinem ADHS-Hirn ist das Fluch und Segen zugleich: Ich sprinte sofort los. Ich will Code sehen. Das führt zwar zu schnellen Ergebnissen, wurde mir diesmal aber (fast) zum Verhängnis.

Mein Anspruch war hoch: Da ich auf der "grünen Wiese" startete, musste der Code perfekt sein. Immer formatiert, statisch analysiert (Larastan Level 5+ versteht sich) und zu 100% getestet. Es war teilweise ein Krampf, das durchzuziehen, aber dank viel Copy-Paste-Ping-Pong mit der KI stehen jetzt auch eine saubere README und Dokumentation.

Der Code war fertig, die Pipeline grün. Zeit für den Masterplan. Ich wollte das Internet mit meinem Tool fluten: Artikel auf dev.to und Medium, Submission bei Laravel News und Posts in r/php und r/laravel auf Reddit.

Ich hatte alles vorbereitet, die Artikel veröffentlicht und bin zufrieden ins Bett gegangen. Am nächsten Morgen der Realitätscheck: 2 Aufrufe auf dev.to und 1 Read bei Medium. Wow! Der Durchbruch sieht anders aus.

Noch "besser" lief es auf Reddit. Während der Post in r/php durchging, scheiterte ich in r/laravel grandios an den Regeln. Zu wenig Karma. Ich habe also verzweifelt versucht, unter den neusten Posts schlaue Kommentare zu schreiben, um Karma zu farmen. Ergebnis: Genau 2 Upvotes. Immer noch zu wenig für die High Society des Laravel-Subreddits. 🤦‍♂️

Aber dann passierte etwas Spannendes im r/php Thread. Ich bekam eine Handvoll Upvotes und Kommentare. Einer davon war von Robert, dem Creator von Flow PHP.

Nach kurzer Recherche (die ich vor meinem ADHS-Sprint hätte machen sollen) fiel mir auf: Flow PHP macht im Grunde genau das, was ich auch mache. Ich hatte mir groß "ETL" (Extract, Transform, Load) auf die Fahne geschrieben und mühsam eine eigene Engine gebaut. Hätte ich vorher mal fünf Minuten gegoogelt, hätte ich einfach Flow als Engine nehmen und meinen Laravel-Wrapper drumherum bauen können.

Nach einem kurzen Austausch mit Robert haben wir festgestellt, dass wir beide profitieren können. Er hätte gerne eine native Laravel-Integration für Flow, und ich habe keine Lust, mich auf ewig um die tiefen Details einer ETL-Engine zu kümmern, wenn es schon eine bessere, ausgereifte Lösung gibt.

Das Ergebnis meines gescheiterten Releases ist also ein neuer Punkt auf der Roadmap: Flow PHP als Engine für Laravel Ingest. Ich kann mich auf die Developer Experience (DX) in Laravel konzentrieren, und Robert liefert die Power unter der Haube.


Manchmal muss man eben erst das Rad neu erfinden, um zu merken, dass man eigentlich nur einen besseren Reifen brauchte. Schaltet auch beim nächsten Mal wieder ein, wenn es heißt: Wie ich meinen kompletten Code lösche und durch Flow PHP ersetze. 😂👋

Tags
Vorheriger Artikel

Coding Chronicles [5]: Nach 2 Jahren Funkstille

Weitere Artikel lesen