GrowLyst ist mein Projekt, das Pflanzenzüchtern hilft, ihre Anbauten zu verwalten. Es richtet sich an Enthusiasten, die eine bessere Möglichkeit suchen, den Fortschritt ihrer Pflanzen zu protokollieren, Veränderungen zu verfolgen und vielleicht sogar aus ihrer eigenen Anbaugeschichte zu lernen.
In diesem Artikel zeige ich dir, wie ich die Serverstruktur für GrowLyst aufgebaut habe. Denk daran: Das Ganze ist noch in der Vorproduktion und kann sich im Laufe der Zeit ändern.
Es ist außerdem mein erstes richtiges Projekt – ich rechne also mit ein paar Fehlern auf dem Weg.
Django Link zu Überschrift
Die erste große Entscheidung war, welches Webframework ich nutzen möchte. Ich wusste, dass ich Python verwenden will, und Django wurde schnell zum Favoriten.
Es ist eines der beiden großen Python-Frameworks (das andere ist Flask), aber was mich letztlich zu Django gebracht hat, war, dass es viele Funktionen bereits mitbringt, die man bei Flask erst selbst hinzufügen müsste – zum Beispiel Authentifizierung, ein Admin-Interface und ein solides ORM.
Für mein erstes ernsthaftes Projekt wollte ich auf Nummer sicher gehen und mehr Zeit damit verbringen, Funktionen zu entwickeln, statt die Grundstruktur selbst zu verkabeln. Der einzige Nachteil, den ich bisher bemerkt habe, ist, dass Django etwas langsam sein kann. Mein Plan ist aber, mich zuerst auf die Features zu konzentrieren und die Performance erst kurz vor dem Release zu optimieren.
Celery Link zu Überschrift
Nachdem das Framework feststand, war klar, dass ich etwas brauche, um Hintergrundaufgaben zu erledigen – zum Beispiel Benachrichtigungen zu versenden oder Daten zu verarbeiten, ohne die App auszubremsen.
Celery war hier die logische Wahl, da es sich gut in Django integriert. Ich verwende Redis als Message-Broker, und ehrlich gesagt war ein Grund dafür auch, dass Render ein Schritt-für-Schritt-Tutorial dazu anbietet. Das hat den Einstieg deutlich einfacher gemacht.
GitHub Link zu Überschrift
Versionskontrolle war ein Selbstläufer. Ich habe GitHub schon früher genutzt – es ist zuverlässig und kostenlos für meine Zwecke. Außerdem lässt es sich nahtlos mit Render verbinden, was die Bereitstellung sehr einfach macht.
Der „Projects“-Bereich in GitHub ist nicht so mein Ding. In meinem Hauptjob mag ich den Workflow in Azure DevOps lieber, aber ich wollte mir weder die Zeit nehmen, das einzurichten, noch dafür bezahlen. Eine andere Möglichkeit wäre gewesen, einen Dienst wie Jenkins selbst zu hosten. Aber ich habe Jenkins schon einmal für eine Hausarbeit eingerichtet – und das ist einfach zu viel Aufwand, wenn man ein Projekt schnell umsetzen möchte. Ich bereue es nicht, mich für GitHub entschieden zu haben. Allein die Dienste, die ich jetzt schon nutze, halten mich genug auf Trab und lenken mich oft vom eigentlichen App-Entwickeln ab.
PostgreSQL Link zu Überschrift
Auch die Datenbankwahl war simpel. PostgreSQL integriert sich perfekt in Django, ist auf Render leicht aufzusetzen und hat einen sehr guten Ruf, was Zuverlässigkeit angeht. Zusammen mit der hervorragenden Dokumentation gab es keinen Grund, etwas anderes zu nehmen.
Flutter Link zu Überschrift
Für die mobile App plane ich, Flutter zu verwenden. Damit kann ich Apps für Android und iOS aus einer einzigen Codebasis entwickeln, was enorm Zeit spart.
Mit der mobilen App habe ich noch nicht begonnen – eventuell würde ich sie sogar auslagern, auch wenn mir die Idee nicht besonders gefällt und es sowieso zu teuer wäre.
Ich weiß, dass ich Django auch hätte weglassen und direkt eine plattformübergreifende App mit Flutter entwickeln können. Aber ein Grund, warum ich Django für das Backend gewählt habe, war einfach, dass ich es lernen wollte. Und am Ende ist der Zeitverlust gar nicht so groß, weil die Verarbeitung sowieso auf den Backend-Servern passiert, wenn man meine Webservice-API nutzt. Die mobilen Apps werden also sehr frontend-orientiert sein.
Render Link zu Überschrift
Am Ende muss alles irgendwo laufen – und hier kommt Render ins Spiel. Es ist modern, einfach zu bedienen und nicht mit endlosen Menüs und Einstellungen überladen.
Für die Bildspeicherung nutze ich AWS S3-Buckets. Das Einrichten war anfangs etwas knifflig, aber sobald alles lief, war es unkompliziert. Render hat vielleicht nicht so viele Funktionen wie AWS oder andere große Cloud-Anbieter, aber es bietet alles, was ich brauche. Und das direkte Deployment von GitHub ist unglaublich einfach.
Hugo Link zu Überschrift
Hugo ist ein Tool, um schnell statische Websites zu erstellen. Auch diese Website, auf der du dich gerade befindest, wurde mit Hugo gebaut.
Der Workflow ist sehr einfach, und die kostenlosen Templates sehen richtig gut aus. Deshalb werde ich Hugo auch nutzen, um die statische Seite für GrowLyst zu bauen, auf der die Dokumentation und Anleitungen stehen werden.
Fazit Link zu Überschrift
Das ist der aktuelle Tech-Stack und die Serverstruktur von GrowLyst. Da wir noch in der Vorproduktion sind, kann sich bis zum Launch noch einiges ändern – besonders im Bereich Performance und Mobile-Entwicklung.
Für den Moment lautet das Ziel: weiterbauen, weiterlernen und irgendwann an den Punkt kommen, an dem GrowLyst etwas ist, auf das Pflanzen-Enthusiasten (mich eingeschlossen) wirklich zählen können.