site-icon Hong Cheung
May 16, 2025

Endgültige Stack-Entscheidung für mein nächstes großes Projekt – Appwrite + Capacitor + RxDB

Ich habe versucht herauszufinden, wie ich alles selbst hosten kann, um dem Kapitalismus zu entkommen, und es war schwierig.

Skaleneffekte und Kapitalismus gehen Hand in Hand. Je größer das Unternehmen, desto günstiger und besser kann der angebotene Service sein. Ich muss einige Opfer bringen, um diesen Monopolen eine Absage zu erteilen.

Ich habe meine Zeit mit Lernen und Basteln verbracht und hoffe wirklich, dass es sich lohnt.

In den letzten Wochen habe ich viele Stacks ausprobiert, um plattformübergreifende, local-first Synchronisation zu erreichen. Dazu gehören native Plattformen, RN Expo, LegendState, Flutter, RxDB, Powersync, Appwrite, MongoDB, Realm und Supabase. Ich habe mir Brick, WatermelonDB, IndexDB usw. angesehen. Außerdem habe ich verstanden, worin sich all diese Lösungen unterscheiden und wie ich sie kombinieren kann. Zum Beispiel Expo mit LegendState mit Supabase/Appwrite, Flutter mit Supabase + Powersync/ElectricSQl usw.

Am Ende habe ich mir gedacht: Wenn ich irgendeine Plattform verwenden würde, sagen wir Flutter (von Google), RN (von Facebook) oder SwiftUI, Kotlin usw., was auch immer. Es bleibt immer noch eine starke Abhängigkeit von der Plattform. Wenn sie sie nicht mehr pflegen oder anfangen, Geld zu verlangen oder ihre Richtlinien ändern, bin ich ihnen ausgeliefert. Besonders wenn ich meine Zeit damit verbringe, für Apple zu entwickeln, um deren App Store durch die Veröffentlichung einer großartigen App mit ihrem SwiftUI aufzuwerten, habe ich das Gefühl, dass ich einfach für sie arbeite.

Ich weiß, dass manche Entwickler das einfach akzeptieren. Sie nutzen, was für sie bequem ist, um schnell ein MVP zu launchn. Aber das will ich trotzdem nicht tun. Ich will nicht Flutter mit Firebase verwenden, nur weil es bequem, skalierbar und relativ kosteneffizient ist. Und dabei ignorieren, wie Google als Unternehmen Nutzer profiliert und trackt, um aus uns Profit zu schlagen, als wären wir dumm.

Deshalb bin ich zu dem Schluss gekommen, dass die einzige Lösung das Web ist. Wie es schon immer war. Webtechnologie ist stabil, und ich muss nicht seitenweise Nutzungsbedingungen durchlesen, nur um zu wissen, dass mein Projekt vielleicht zufällig abgeschaltet wird, weil ich ihre Monopolregeln nicht befolge.

Wenn am Ende ein plattformübergreifendes Framework ohnehin kompiliert werden muss, ergibt es vollkommen Sinn, zuerst eine Web-App zu bauen und sie dann mit Capacitor zu umhüllen, nur um sie im App Store und im Google Play Store zu veröffentlichen. Sie sollten ohnehin als zweitrangig behandelt werden.

Es ging nie um Geräteleistung, Geräte-APIs oder Multithreading. Es ist eine Frage des Stolzes und des Ziels, etwas Großes zu erreichen.

abcd.com ist dasselbe wie google.com, und ich sollte von dort aus anfangen.

Zurück
Copyright 2026
Sitemap
Datenschutzerklärung
Nutzungsbedingungen

Theme von Astro-Yi