site-icon Hong Cheung
May 16, 2025

Décision finale sur la stack pour mon prochain grand projet - Appwrite + Capacitor + RxDB

J’essaie de comprendre comment tout auto-héberger pour pouvoir échapper au capitalisme, et ce n’est pas facile.

Les économies d’échelle et le capitalisme vont de pair. Plus l’entreprise est grande, moins cher et meilleur est le service qu’elle peut offrir. Je dois faire des sacrifices pour pouvoir dire non à ces monopoles.

J’ai passé mon temps à apprendre et à bricoler, j’espère vraiment que ça en valait la peine.

Ces dernières semaines, j’ai essayé beaucoup de stacks pour parvenir à une synchronisation multiplateforme et local-first. Cela inclut les plateformes natives, RN Expo, LegendState, Flutter, RxDB, Powersync, Appwrite, MongoDB, Realm et Supabase. Je me suis penché sur Brick, WatermelonDB, IndexDB, etc. J’ai aussi cherché à comprendre la différence entre toutes ces solutions et comment je peux les combiner. Par exemple, Expo avec LegendState et Supabase/Appwrite, Flutter avec Supabase + Powersync/ElectricSQl, etc.

Au final, je me suis dit que si j’utilise une plateforme quelle qu’elle soit, disons Flutter (de Google), RN (de Facebook) ou SwiftUI, Kotlin, etc., au choix. Cela reste une très grande dépendance à une plateforme. Si elle cesse de la maintenir, commence à facturer ou change ses politiques, je serai pris en otage. Surtout que si je passe mon temps à développer pour Apple afin d’enrichir leur App Store en publiant une excellente app avec leur SwiftUI, j’ai l’impression de travailler pour eux.

Je sais que certains développeurs vont simplement l’accepter. Ils utilisent ce qui leur est pratique pour lancer rapidement un MVP. Mais je ne veux toujours pas faire ça. Je ne veux pas utiliser Flutter avec Firebase simplement parce que c’est pratique, scalable et relativement rentable. En ignorant comment Google, l’entreprise, profile et traque les utilisateurs pour faire du profit sur notre dos, comme si nous étions idiots.

Par conséquent, j’en ai conclu que la seule solution, c’est le Web. Comme ça l’a toujours été. La technologie Web est stable, et je n’ai pas besoin de lire des pages de Conditions d’utilisation juste pour savoir que mon projet pourrait être fermé au hasard parce que je ne respecte pas leurs règles de monopole.

Si, au final, un framework multiplateforme nécessite de toute façon une compilation, construire d’abord une app web, puis l’envelopper avec Capacitor juste pour la publier sur l’App Store et le Google Play Store a parfaitement du sens. Car ils devraient de toute façon être traités comme une priorité de seconde classe.

Il n’a jamais été question de performance de l’appareil, d’API de l’appareil, ni de multithreading. C’est une question de fierté et de l’objectif d’accomplir quelque chose de grand.

abcd.com est identique à google.com, et je devrais commencer par là.

Précédent