Gedanken zum Start dieses Blogs
In diesem Beitrag teile ich meine Gedanken zum Start dieses Blogs, vom eigentlichen Zweck über die Wahl des Frontend-Frameworks bis hin zum Headless CMS.
Ich habe meine ersten Gedanken zum Start dieses Blogs zusammengetragen.
【Zweck】
Indem ich über die von mir erworbenen Technologien blogge, möchte ich ein präzises und tiefes Verständnis dieser Technologien erlangen und als Bonus versuchen, den Blog zu monetarisieren, um die Serverwartungskosten zu decken. Daher gelten folgende Prioritäten:
- Aneignung der neuesten Technologien.
- Betriebskosten so gering wie möglich halten. Wenn die Ausgaben die Einnahmen übersteigen, wird die Fortführung schwierig.
- Aufwand abseits des Schreibens von Artikeln (z. B. Administrationsaufwand und Veröffentlichungsprozess) minimieren.
- Der Inhalt der Artikel soll primär technischer Natur sein, gefolgt von Hobbys.
【Überlegungen zur Betriebsumgebung】
Ich habe verschiedene Betriebsmethoden für den Start eines Blogs aufgelistet.
<Nachteile kostenloser Plattformen>
- Führt nicht zum Erlernen der neuesten Technologien.
- Kostenlose Plattformen blenden automatisch Werbung ein, wodurch Werbeanzeigen ohne eigenen Umsatzgewinn geschaltet werden. Zudem können unerwünschte Anzeigen erscheinen.
- Da es sich um eine vorgefertigte Blog-Plattform handelt, ist der administrative Aufwand wahrscheinlich minimal.
<Nachteile kostenpflichtiger Plattformen>
- Führt nicht zum Erlernen der neuesten Technologien.
- Das Problem ist, dass es Geld kostet. Die Wahrscheinlichkeit ist hoch, dass man aufgibt, ohne den Blog langfristig fortzuführen.
- Erfordert vermutlich den geringsten Aufwand.
<Eigenständig: WordPress + Heimserver + Cloudflare Tunnel>
- Nur Cloudflare Tunnel ist wirklich neuartig.
- Im Grunde kostenlos, daher ist die Fortführung einfach.
- WordPress selbst ist mittlerweile sehr funktionsreich geworden, was die Verwaltung (wie Artikel-Updates) verkomplizieren kann und einen gewissen Lernaufwand erfordert. *Liegt das im akzeptablen Bereich?
<Eigenständig: JS-Framework + GitHub + Headless CMS + Cloudflare Pages>
- Inhaltsverwaltung über ein Headless CMS (eine moderne CMS-Form) gepaart mit einem JS-Framework.
- Im Grunde kostenlos, wodurch das Ziel erreicht wird.
- Die Nutzung als SaaS ist komfortabel, aber wenn der Dienst eingestellt wird, steht man vor einem Problem. Erhöhte Wechselkosten und mehr Aufwand.
【Entwicklungsumgebung】
Basierend auf den obigen Überlegungen und den unten stehenden Framework-Informationen habe ich mich im Rahmen meiner Vorstudien für künftige Großprojekte dazu entschlossen, eine Blog-Website mit einem Frontend-Framework + Headless CMS + Cloudflare Pages zu erstellen.
<Zum Editor>
Für die Entwicklungsumgebung ist es üblich, eine integrierte Entwicklungsumgebung (IDE) zu installieren und Erweiterungen hinzuzufügen, die zur jeweiligen Programmierumgebung passen. VS Code ist optimal, aber da der extrem leichtgewichtige und schnelle Editor Zed inzwischen Astro-Erweiterungen implementiert hat, werde ich diesen verwenden.
<Desktop-Umgebung für die Entwicklung>
Die Code-Entwicklung erfordert die Integration mit anderen Cloud-Diensten wie npm (Node Package Manager) und GitHub. (Hinweis: npx steht für "Node Package Execute". Im Gegensatz to npm ist es ein Kommandozeilenwerkzeug, um Node.js-Pakete temporär auszuführen, ohne sie global zu installieren, was die Entwicklungsumgebung sauber hält.)
OS-Typ | Eigenschaften |
Linux | Es heißt, dass etwa 70 % der weltweiten Webserver auf Linux laufen. Es hat einen hohen Marktanteil im Serverbereich und bietet die meisten Entwicklertools. Allerdings ist die Ausgereiftheit der Desktop-GUI und der App-Support im Vergleich zu Mac oder Windows deutlich geringer, weshalb es sich weniger als primäre Entwicklermaschine eignet. |
macOS | Ursprünglich als Unix-ähnliches Betriebssystem entwickelt, ist es stark bei der Nutzung von Linux-Befehlen; die meisten Linux-Befehle können direkt verwendet werden. Die Desktop-Benutzeroberfläche ist hervorragend, weshalb macOS von vielen Entwicklern als Arbeitsgerät gewählt wird. |
Windows | Der Marktanteil im geschäftlichen und allgemeinen Bereich ist überwältigend. Da es sich auch gut für Gaming eignet, hält es den Spitzenplatz bei den Desktop-Betriebssystemen. Durch die Installation von WSL (Windows-Subsystem für Linux) lässt sich eine Linux-Umgebung unter Windows realisieren. Im Grunde läuft Linux als virtuelle Maschine mit gemeinsam genutzten Dateien – das Beste aus beiden Welten. Seit der Version 2.0 nutzen dies sehr viele Entwickler. |
Eine einfache Blog-Umgebung benötigt keine hochentwickelte Entwicklungsumgebung, daher reicht Mac oder Windows völlig aus. Um mir den Aufwand der WSL-Installation zu sparen, werde ich diesmal macOS verwenden.
【Dev Container】
Bei der Entwicklung im Team ist die Vereinheitlichung der Entwicklungsumgebung mittels DevContainers gängige Praxis. Allerdings erscheint mir die Einführung von DevContainers bei einem Projekt, das von einer einzigen Person entwickelt wird (wie bei diesem Blog), administrativ zu aufwendig, weshalb ich dieses Thema vorerst zurückgestellt habe.
【Eigenschaften von Frontend-Frameworks】
Normalerweise wird eine Sammlung nützlicher Funktionen und Bibliotheken, die nach einer bestimmten "Designphilosophie" für den Aufbau einer Website zusammengestellt wurden, als Framework bezeichnet. Wenn man dieser Designphilosophie beim Schreiben des Codes folgt, wird die Website-Entwicklung effizienter. Obwohl man die Philosophie verstehen und die Eigenheiten des Codes lernen muss, sorgt dies nach der Einarbeitung für Konsistenz im gesamten Implementierungscode. Der Code wird lesbarer, neigt zu weniger Fehlern und ist somit ein unverzichtbares Element für größere Websites.
Name des Frameworks | Entwickler | Eigenschaften |
React (Viele Nutzer) | Meta (Facebook) | Die Benutzeroberfläche wird komponentenbasiert verwaltet und das Rendering ist schnell, da über das Virtual DOM nur Änderungen aktualisiert werden. Es ähnelt eher einer UI-Bibliothek als einem vollständigen Framework. *Ich persönlich mag es nicht |
Vercel | Ein Full-Stack-Framework, das auf React aufbaut. Während React rein clientseitig ist, deckt Next.js auch die Serverseite ab, was optimalere Rendering-Methoden und einen schnelleren Seitenaufbau ermöglicht. *Aktuell veraltet! (Der CEO ist Müll, daher mag ich es nicht mehr) | |
Vue.js (Viele Nutzer) | Evan You | Für Einzelpersonen einfach zu erlernen mit geringen Einstiegshürden. Durch individuelle Kombinationen ist vieles möglich. Komponentenbasiert. Da es einfach strukturiert ist, lässt es sich gut mit verschiedenen Bibliotheken kombinieren. Es gibt viele Ressourcen im Web. Ich persönlich mag es. |
Alexandre Chopin u. a. | Ein Full-Stack-Framework basierend auf Vue.js. Besonders stark beim Erstellen von Websites als SPA (Single Page Application). | |
Astro Technology Company | Astro rendert die gesamte Seite in statisches HTML und erzielt eine hohe Performance, indem unnötiges JavaScript entfernt wird. Es ist so konzipiert, dass verschiedene UI-Frameworks wie React oder Vue gleichzeitig verwendet werden können. Eher für MPA als für SPA geeignet, der erste Seitenaufbau ist extrem schnell. Das optimale Framework für einen Blog. |
<Referenz>
- Ergebnisse der Migration von Next.js zu Astro
- React hat Derivate wie React Native, mit denen sich native Smartphone-Apps entwickeln lassen. Wenn man Dienste plattformübergreifend anbietet, sinkt der relative Lernaufwand.
- Für die plattformübergreifende Entwicklung für iOS und Android hat Googles Flutter jedoch derzeit mehr Aufwind als React Native. Da die Benutzeroberfläche geteilt wird, bleibt das Bediengefühl auf verschiedenen Geräten gleich, was besonders im geschäftlichen Bereich vorteilhaft ist. Daher sehe ich keinen Grund, React zwingend einzusetzen.
【Open-Source (Kostenlose) Headless-CMS】
Es gibt nicht viele Open-Source-Headless-CMS-Lösungen, die auf eigenen Servern betrieben werden können. Viele Anbieter stellen diese ähnlich wie microCMS als SaaS-Clouddienste bereit. Dennoch bietet Open Source enorme Vorteile, wenn man die Daten intern behalten möchte oder Lizenzgebühren bei einer Skalierung vermeiden will. Allerdings ist dafür ein eigener Server erforderlich.
Name | Eigenschaften |
Das wohl bekannteste Open-Source-Headless-CMS. MIT-Lizenz. Kostenlos für persönliche und kommerzielle Nutzung, bietet jedoch eine kostenpflichtige Enterprise-Version. *Der Kern basiert anscheinend auf React. | |
Sanity | Die Stärke liegt in flexiblen Datenschemata und kollaborativer Echtzeitbearbeitung. Stark bei dynamischer Inhaltsverwaltung. Cloudbasiert (SaaS). Kostenlose Stufe verfügbar. |
In JavaScript geschrieben, läuft auf Node.js. Lizenziert unter der MIT-Lizenz. Offizielles Docker-Image auf Docker Hub. Ein auf Blogs spezialisiertes Headless CMS mit einem Aufbau ähnlich wie WordPress. | |
Ehemals Netlify CMS. Lizenziert unter der MIT-Lizenz. Wenige deutschsprachige Artikel. Ein Git-basiertes Open-Source-CMS, das direkt mit dem Git-Repository verknüpft ist. | |
Wird von vielen Großunternehmen eingesetzt. In JavaScript implementiert, läuft auf Node.js. Wandelt bestehende SQL-Datenbanken direkt in performante APIs um. Erzeugt automatisch eine API-Struktur aus der Datenbankstruktur. | |
Basiert auf Python. Wird unter anderem von der NASA und Google genutzt. | |
Die Datenbank scheint auf MongoDB festgelegt zu sein. JavaScript-basiert. | |
Wird unter anderem von Unity verwendet. Apache-2.0-Lizenz. | |
Kommerzielle Entwicklung. | |
GPL-3.0-Lizenz. Speichert Daten in JSON-Dateien usw., ohne eine Datenbank zu verwenden. |
<Auswahl des Headless CMS>
Da es sich um einen persönlichen Blog handelt, der nur tragbar ist, wenn er kostenlos bleibt, reduz sich die Auswahl auf Open-Source-Systeme unter der MIT-Lizenz wie Strapi, Ghost oder Directus. Unter diesen scheint Strapi am flexibelsten für künftige Erweiterungen und E-Commerce-Projekte zu sein, weshalb ich mich dieses Mal dafür entschieden habe.
【Fazit】
So habe ich mich für die Kombination aus Astro + Strapi + AlloyDB (PostgreSQL) + TailwindCSS + Cloudflare Pages + MacBook Pro + Zed-Editor als technisches Fundament für diesen Blog entschieden. Der entscheidende Punkt dabei ist der Build-Ablauf.
- Strapi-Container auf dem Mac starten, Artikel erstellen.
- Beim Build-Prozess des Blogs statische Seiten und Bilder aus Strapi exportieren, sodass im Live-Betrieb kein Strapi-Server laufen muss (kein eigener Server im Internet nötig!).
- Die im Build-Prozess erzeugten statischen Daten gesammelt auf Cloudflare Pages hochladen (bereitstellen). Die Website besteht somit vollständig aus statischen Daten mit minimalem JavaScript. Die Ladezeit ist extrem schnell.
Der Clou ist, dass die Produktionsumgebung ausschließlich aus statischen Daten besteht. Man verwendet Strapi im Grunde nur zum Verfassen von Artikeln.