Pigeonport

Project

Component Hub

Component Hub ist ein kleines Side-Project zur Organisation meiner Mikroelektronik-Bauteile. Es dient als Inventar- und Suchsystem, damit ich zukünftige Projekte leichter planen und umsetzen kann.

Component Hub

Falls du direkt zur Beschreibung des Component Hubs möchtest, kannst du hier klicken.

Die Hintergrundgeschichte

Vor ein paar Jahren habe ich angefangen, mit Mikroelektronik herumzuspielen. Angefangen mit einem All-in-one-Set von Elegoo und einem Arduino Uno – und keiner Ahnung, was man damit alles machen kann.

Die Begeisterung kam schnell, da ich mit Arduinos und Co. nun die Möglichkeit hatte, meine Software- und Informatik-Skills aus der Uni in die „echte Welt“ zu bringen. Ich habe direkt angefangen, mir Gedanken zu machen, wie ich mein Wohnheimzimmer smart machen könnte, und hatte endlose Ideen. So ist dann auch z. B. das LED-Controller-Projekt entstanden, worüber ich hier geschrieben habe.

Warum braucht man jetzt Software, wenn man Hardware bauen möchte?

Jeder, der mit Mikroelektronik angefangen hat und über das typische Starter-Set hinausgeht, kennt vermutlich das Problem mit der Organisation. Erst kauft man sich ein paar zusätzliche Module, Kabel, Sensoren, Controller. Zunächst nehmen diese nicht wirklich Platz weg, da sie direkt im nächsten Projekt verbaut werden, aber irgendwann fängt man an, größere Mengen zu kaufen, um Geld zu sparen. Dann bestellt man sich noch ein paar zusätzliche Teile, um Versandkosten zu sparen, und die Mystery-Box mit Random-Teilen klingt dann doch zu verlockend, um sie nicht auch noch dazuzupacken. Und so passiert es dann ganz schnell, dass man eine Box mit einem ganzen Haufen an Teilen hat und man selbst nicht mehr weiß, was man hat – und falls ja, wo das Teil ist, das man sucht.

Meine Lösung für das Problem war dann zunächst, mehrere Organizer zu kaufen. Mehrere kleine Boxen sind deutlich besser als eine große, denn so kann ich wenigstens alle gleichen Teile sortieren. Vor allem kann man sich so auch ungefähr merken, wo man welche Teile hat, und kann diese dann schneller finden, als wenn noch alle in einer Box zusammenliegen.

Stanley Organizer Setup

Trotzdem hatte ich dann oft das Szenario, dass ich ein bestimmtes Teil gesucht habe und 20 kleine Boxen aufmachen musste, bis ich das richtige gefunden habe. Das lag vor allem daran, dass die Boxen auch noch in bis zu drei Sektionen aufgeteilt sind und man daher immer nur eines der drei Teile direkt sehen kann. Und wenn man anfängt, auch mehr einzelne Teile zu kaufen anstelle von Modulen, sind diese noch schwerer zu erkennen und zu finden. Ein BC557B-Transistor, BC547B-Transistor oder 2N2222A-Transistor sehen auf den ersten Blick alle gleich aus. Und jedes Teil erst genau anzuschauen, welche kleine Inschrift darauf ist, war auf Dauer dann doch etwas zu aufwendig.

Eine Software als Second Brain

Es musste also eine Softwarelösung her, mit der ich schnell meine Teile finden und am besten noch tracken kann, wie viele ich aktuell davon habe. Es gibt einige Open-Source-Inventar-Management-Systeme wie z. B. Inventree, welche diese Anforderungen gut erfüllen, aber etwas Overkill für das wirken, was ich brauche. Eigentlich brauche ich auch nur eine einfache Suchfunktion über Einträge mit einem Inventar-Counter. Und wie jeder Softwareentwickler dachte ich mir: Wie schwer kann das schon sein, so ein kleines System kurz zu entwickeln?

KI-Disclaimer

Hier ist auch der perfekte Zeitpunkt, um einen KI-Disclaimer zu geben. Für die Planung und teilweise für die Umsetzung habe ich Agentic Coding in Antigravity mit Gemini 3.1 genutzt. Ich habe dieses Projekt dazu genutzt, mich mit der Arbeitsweise von Agentic Coding auseinanderzusetzen, um das ganze Thema rund um KI und Code besser einordnen zu können. Die Planung des Projekts und auch das Schreiben dieses Artikels wurden ohne Hilfe von KI durchgeführt. Lediglich für die Rechtschreibkontrolle und die Erstellung des Headline-Images wurde in diesem Artikel KI genutzt.

Ich weiß, dass KI-Coding noch ein sehr kontroverses Thema ist. Aber genau deswegen denke ich, ist es wichtig, dass jeder sich ein eigenes Bild davon macht, um qualitativ darüber sprechen zu können. Dieser Artikel soll sich aber um den Component Hub drehen. Später werde ich einen weiteren Artikel schreiben, in dem ich eine Auswertung und Bewertung der Nutzung von KI-Coding geben werde.

Anforderungen an den Component Hub

Die Hauptanforderung an die Software war also, mir zu helfen, meine Komponenten schneller zu finden. Die MVP-Definition des Projektes war: 1. Man soll Komponenten hinzufügen können (idealerweise mit Bild), 2. man soll in der Lage sein, per Suche ein bestimmtes Teil zu finden, 3. man soll in der Lage sein, den Inventarstand zu tracken. Auf den ersten Blick sehr überschaubar von den Funktionen, daher dachte ich mir: Lass doch mal ein wenig mit dem Tech-Stack spielen – nur für den Fall, dass das Projekt irgendwann einmal doch etwas größer wird.

Bei der Entwicklung ist dann aufgefallen, dass doch noch einige weitere Features ganz interessant wären. Wenn man viel mit Mikroelektronikteilen arbeitet, sucht man sich oft die Datenblätter oder Beschreibungen der Produkte noch einmal heraus, damit man diese richtig nutzen kann. Daher wollte ich eine Möglichkeit haben, Links und Dateien zu den Komponenten hinzuzufügen, um immer schnell die richtige Dokumentation zu finden. Außerdem braucht man auch irgendeine Möglichkeit, die Kategorien und Drawer-Einträge zu organisieren und zu bearbeiten, wofür auch Seiten benötigt werden. Außerdem sollten die Komponenten auch eine Beschreibung haben, in die man idealerweise die Beschreibung des Herstellers einfügen kann, und einen dedizierten Notizbereich für eigene Anmerkungen.

Die wohl wichtigste Anforderung beim Prototyping war aber der Fokus auf Benutzerfreundlichkeit (Ease of Use). Der Hub soll dabei helfen, Komponenten zu organisieren und zu finden. Daher darf die Nutzung des Hubs auch nicht so kompliziert sein, dass man ihn nicht nutzen möchte.

Tech-Stack-Entscheidungen und Entwicklung

Wie in jedem Softwareprojekt sind auch hier irgendwann die Überlegungen gekommen, welchen Tech-Stack man nutzen kann für den Component Hub. Daher habe ich hier einmal meine technischen Entscheidungen dokumentiert, warum ich den Hub so geschrieben habe, wie er gerade existiert. Falls euch das nicht interessiert, könnt ihr direkt zum Ergebnis springen, um das fertige Ergebnis zu sehen.

Backend

Da ich aktuell alle meine Backends und Microservices in Kotlin schreibe, lag es nahe, es auch für dieses Projekt zu benutzen. Um dennoch etwas Neues zu lernen, habe ich mich anstelle des Ktor-Frameworks für dieses Projekt für Spring Boot entschieden. Das letzte Mal, dass ich aktiv mit Spring Boot gearbeitet habe, war 2021, und dort auch noch in der Java-Version. Mittlerweile hat Spring Boot ja 100-prozentigen Kotlin-Support, und ich wollte einmal schauen, wie man ein modernes Backend in Kotlin damit aufsetzen kann.

Frontend

Für das Frontend habe ich mich, wie bei allen meinen Projekten, für Vue mit TypeScript und Tailwind entschieden. Meiner Meinung nach hat Vue von den üblichen Frontend-Frameworks die leserlichste Struktur und Syntax und hat mir persönlich immer am meisten gefallen. Da das Frontend aber komplett entkoppelt von den Datenmodellen ist, kann man hier auch ein beliebiges Framework seiner Wahl nutzen, um ein eigenes Frontend zu entwerfen.

Große Teile des Frontends wurden mithilfe von Software-Agenten entwickelt. Ich habe bei diesem Projekt versucht herauszufinden, inwieweit man Agentic Development nutzen kann, um zu einem schnelleren Ergebnis zu kommen. Die Kernerkenntnis ist dabei gewesen, dass die Ergebnisse umso besser werden, je mehr Struktur und Richtung man den Agenten gibt.

Weiterhin habe ich PrimeVue als Component Library genutzt, um ein einheitliches Design zu erhalten. Ziel war es, dem KI-Agenten durch die Einschränkung auf PrimeVue eine Designstruktur vorzugeben, was tatsächlich zu einigermaßen guten Ergebnissen geführt hat.

Datenbank

Bei der Datenbank habe ich mich für Postgres entschieden. Durch meine Arbeit habe ich viel mit MariaDB zu tun und wollte gerne in meinem Hobbyprojekt meinen Horizont erweitern. Andere Projekte wurden in letzter Zeit immer mit einer NoSQL-Datenbank wie MongoDB umgesetzt. Daher hier einmal die Entscheidung, Postgres zu nutzen.

Da aber in Spring das Data-JPA-Modul genutzt wurde, haben die eigentlichen Datenabfragen nur eine sekundäre Rolle, da die meisten CRUD-Operationen bereits implementiert sind. Maßgeblich unterschiedlich werden die Anfragen erst, wenn konkretere Abfragen notwendig sind.

Außerdem gibt es Pläne, Transaktionen zu implementieren, um den Bestand der einzelnen Komponenten zu tracken. Diese starke Verbindung zwischen Datenobjekten war der Grund für eine SQL-Datenbank anstelle von NoSQL.

Deployment

Aktuell ist das Deployment sehr einfach gehalten. Ich verwalte meinen eigenen vServer von Netcup, auf dem meine ganzen Projekte liegen. Der Upload passiert aktuell noch manuell, ebenso wie das Neuerstellen und Starten der Docker-Container. Die Container liegen dabei hinter einem Proxy, welcher den Endpoint exposed.

Ein weiterer Plan ist es, eine CI/CD-Pipeline zu erstellen, welche dann die benötigten Images automatisch bei einem Release erstellt und zur Verfügung stellt. Die Umsetzung dafür ist mit GitHub Actions geplant. Auf dem vServer wird dann ein Listener eingerichtet, welcher regelmäßig nach neuen Versionen schaut und ggf. den existierenden Container neu erstellt.

Der Component Hub

Um dir einen Eindruck vom Endergebnis zu geben, findest du hier einen Rundgang durch die fertige Anwendungsoberfläche.

Hauptseite
1/5

Hauptseite

Im Slider könnt ihr die Hauptseiten vom Component Hub sehen. Vom Design her ist es nichts Besonderes, aber es ist nutzbar und daher ausreichend für mich.

Die Hauptseite gibt einen schnellen Überblick über alle verfügbaren Komponenten und bietet eine einfache Suchfunktion, wenn man ein bestimmtes Teil sucht. Die Detailseite enthält dann Informationen über die Komponente und die Dokumentation sowie Links zum Hersteller. Sowohl auf der Hauptseite als auch auf der Detailseite kann man den Bestand der einzelnen Komponenten ändern sowie erkennen, in welchem Drawer sich die Komponenten befinden.

Die Logik, um ein Bauteil zu finden, basiert auf der Drawer-Sektion: D32-S1 würde somit heißen, dass die Komponente im Drawer mit der Nummer 32 im vorderen Fach zu finden ist. Diese Logik sollte sich aber leicht anpassen lassen, oder die Sektionen lassen sich z. B. auch komplett weglassen.

Neue Komponenten kann man einfach hinzufügen, und die Felder für Links und Bilder unterstützen Drag-and-Drop sowie File-Uploads. Die Dateien werden dann im Backend abgelegt und zur Verfügung gestellt. So kann man beispielsweise Bilder oder auch Dokumentationen von Seiten wie AliExpress persistieren, bevor der Händler diese Komponenten nicht mehr anbietet.

Das letzte Feature ist der KI-Export. Ziel hierbei war es, die Informationen über die verfügbaren Komponenten in ein KI-freundliches Format zu bringen und diese einem Modell seiner Wahl übergeben zu können. So kann die KI Empfehlungen aussprechen, welche Teile für ein Projekt genutzt werden können, sollte man eine konkrete Idee haben oder eventuell Alternativen zu einer bestimmten Komponente suchen. Aktuell werden beim KI-Export eine Tabelle mit Part Name, Category und Stock ausgegeben.

Weitere Vision

Ich selbst habe den Component Hub jetzt seit mehreren Wochen in Betrieb und nutze ihn, um Komponenten für meine DIY-Projekte herauszusuchen und zu verwalten. Daher erfüllt er aktuell genau das, wofür ich ihn entworfen habe; dennoch lassen sich natürlich noch diverse Erweiterungen denken. Außerdem gibt es natürlich auch noch einige andere Quality-of-Life-Verbesserungen, die nach und nach umgesetzt werden können, wie z. B. eine bessere Suche.

Projekt-Management

Eine große Idee wäre, dass man direkt im Hub verschiedene Projektideen verwalten und Komponenten zuweisen kann. Hier wäre es dann denkbar, auch Komponenten zu Projekten hinzuzufügen, welche aktuell noch nicht im Hub vorhanden sind. Diese neuen Komponenten könnten dann direkt für eine Einkaufsliste markiert werden. Außerdem kommt es oft vor, dass man mehrere Versionen eines bestimmten Projekts bauen möchte. Hier könnte man die Komponenten dann über verschiedene Versionen hinweg tracken und verwalten. Außerdem wäre eine Integration für diesen Blog denkbar, über die Komponentenlisten exportiert werden können.

KI-Integration

Anstatt nur einen KI-Export anzubieten, könnte man überlegen, ob es möglich ist, eine Schnittstelle wie MCP zu integrieren, um einem LLM direkten Zugang zu allen Informationen zu geben. So könnte ein Agent genauere Informationen zu bestimmten Komponenten abrufen oder auch direkt mit dem Hub interagieren, um neue Komponenten anzulegen, Bestände zu verändern und Projekte zu planen.

Fazit

Ich hoffe, dir hat diese kleine Übersicht über den Component Hub gefallen. Schau dir gerne die Live Demo an oder schau beim Repo vorbei und probiere den Hub selbst einmal aus.

Für Verbesserungsvorschläge oder weitere Optimierungen bin ich immer sehr dankbar. Zusammen kann man immer die beste Software entwickeln.

Erstellt von Marvin Taube · Alle Rechte vorbehalten.

Design inspiriert von onWidget – AstroWind