Rückblick auf die Technologiewahl für mein SaaS

xguru · 2022-09-27T11:07:02+09:00

Ich halte fest, welche Technologien ich vor 2 Jahren ausgewählt habe, um Mobile/Web/Backend zu bauen, und ziehe ein Fazit dazu Es war ein sehr einfaches, generisches SaaS, daher war das Ziel, mit minimalem Aufwand und minimalen Ressourcen schnell zu bootstrappen Da meine Designfähigkeiten begrenzt sind, habe ich die Mobile-App nicht selbst entwickelt, sondern ausgelagert und nur Backend und Web entwickelt Technologiewahlen Mobile App Ich war lange Zeit .NET-Entwickler, wollte aber nicht mit Xamarin entwickeln Für die gleichzeitige Unterstützung von iOS/Android habe ich Flutter gewählt Innerhalb weniger Wochen stand eine App, die auf beiden Plattformen lief, also hervorragend aus Time-to-Market-Sicht Das UI hatte zwar ein paar Mängel, aber für einen B2B-Use-Case wie unseren war das vernachlässigbar Flutter selbst hatte viele Bugs und Probleme, aber nichts auf Show-Stopper-Niveau Dart als Sprache fand ich nicht besonders gut, aber das war kein Problem. (Ich habe es ja ohnehin nicht selbst entwickelt) Vielleicht wäre es besser gewesen, einfach bei Xamarin zu bleiben oder React Native zu wählen API Skalierung war nicht entscheidend. Es reichte, es nur einigen der ersten Kunden bereitzustellen Deshalb habe ich Kubernetes/Serverless usw. komplett ignoriert und einfach einen Monolithen gebaut Es war eine einzelne, aber modularisierte .NET-Anwendung, in F# geschrieben und nach der Onion-Architektur (Ports-&-Adapters-Muster) aufgebaut Auch Dinge wie GraphQL habe ich ignoriert und stattdessen einfach auf den altmodischen REST-Ansatz gesetzt Ergebnis Die API ist sehr robust und schnell. Im Betrieb treten fast nie Probleme auf Ich kann es nicht beweisen, aber ich denke, dass ein Großteil dieses Erfolgs auf meinen Ansatz mit "Applied Functional Programming" zurückgeht Außerdem ist F#-Code sehr schön, gut lesbar und leicht verständlich Da ich nur von sehr wenigen Open-Source-Bibliotheken abhänge, ist es kein Problem, dass das F#-Ökosystem relativ klein ist und sich langsam bewegt Persistence Ich habe lange SQL Server genutzt, wollte aber keine Lizenzkosten für die Datenbank tragen Deshalb habe ich PostgreSQL gewählt, das die API auf einem einzelnen DB-Server nutzt. Mit einem kleinen Queue-Mechanismus Das Produkt brauchte einen BLOB-Speicher, also habe ich mich entschieden, einfach das Dateisystem des Servers zu verwenden Ergebnis Es funktioniert einfach (It just works). Mit Postgres zu arbeiten ist angenehm Der JSONB-Datentyp macht es möglich, relationale und NoSQL-Techniken kombiniert zu nutzen. Auf sehr stabile und komfortable Weise Die JSON-Abfragesyntax muss man sich wohl nicht merken BLOBs einfach auf der Festplatte zu speichern ist eine größere Entscheidung, aber etwas wie AWS S3 hätte bei der kleinen Nutzerzahl wahrscheinlich keinen großen Nutzen gebracht Web App Die Technologieentscheidung für die Web-App hat ziemlich lange gedauert Mein Bauchgefühl sagte mir, ich solle Fable und F# wählen, aber am Ende entschied ich mich für React und TypeScript und baute eine SPA Eine wichtige frühe Entscheidung war die Einführung von Tailwind CSS Ergebnis React just works, TypeScript just works Genau wie bei Dart schreibe ich TypeScript nicht besonders gern und lese es auch nicht besonders gern TS hat aber einige großartige Features. Funktionen wie Discriminated Unions hätte ich auch gern in F# Insgesamt ist die Developer Experience hervorragend. Die Build-Zeiten sind extrem kurz (im Vergleich zu F#), und für die meisten komplexen UI-Probleme gibt es bereits Pakete Auch aus Sicht der funktionalen Programmierung ist das Gesamtmodell von React für Anwendungen nachvollziehbar Tailwind CSS nimmt enorm viel Last ab Infrastructure Mit der Entscheidung für einen Monolithen wurde die Wahl einfacher Ich habe bei Hetzner eine Linux-Maschine gemietet und darauf 3 Docker-Container betrieben: Postgres, DotNet API, Nginx Alles wird mit GitHub Actions gebaut und automatisch deployt Ergebnis Wenn Client und Backend gleichzeitig deployt werden, gibt es Downtime, aber derzeit ist sie kurz und vernachlässigbar Der gesamte Prozess ist schlank und stabil, und die Kostenstruktur ebenso. Hetzner ist wirklich günstig Fazit Ich bin mit den aktuellen Entscheidungen sehr zufrieden Ich habe in F# und funktionale Programmierung in größerem Umfang investiert als im vorherigen Projekt Drei Sprachen im Projekt, nämlich F#, TypeScript und Dart, sind etwas viel Dotnet MAUI ist nicht so ausgereift wie Flutter, könnte aber eine Option sein anstelle einer anderen Sprache, die man nicht oft verwendet

(thomasbandt.com)

18 Punkte von xguru 2022-09-27 | 3 Kommentare | Auf WhatsApp teilen

Ich halte fest, welche Technologien ich vor 2 Jahren ausgewählt habe, um Mobile/Web/Backend zu bauen, und ziehe ein Fazit dazu
Es war ein sehr einfaches, generisches SaaS, daher war das Ziel, mit minimalem Aufwand und minimalen Ressourcen schnell zu bootstrappen
Da meine Designfähigkeiten begrenzt sind, habe ich die Mobile-App nicht selbst entwickelt, sondern ausgelagert und nur Backend und Web entwickelt

Technologiewahlen

Mobile App

Ich war lange Zeit .NET-Entwickler, wollte aber nicht mit Xamarin entwickeln
Für die gleichzeitige Unterstützung von iOS/Android habe ich Flutter gewählt
Innerhalb weniger Wochen stand eine App, die auf beiden Plattformen lief, also hervorragend aus Time-to-Market-Sicht
Das UI hatte zwar ein paar Mängel, aber für einen B2B-Use-Case wie unseren war das vernachlässigbar
Flutter selbst hatte viele Bugs und Probleme, aber nichts auf Show-Stopper-Niveau
Dart als Sprache fand ich nicht besonders gut, aber das war kein Problem. (Ich habe es ja ohnehin nicht selbst entwickelt)
Vielleicht wäre es besser gewesen, einfach bei Xamarin zu bleiben oder React Native zu wählen

API

Skalierung war nicht entscheidend. Es reichte, es nur einigen der ersten Kunden bereitzustellen
Deshalb habe ich Kubernetes/Serverless usw. komplett ignoriert und einfach einen Monolithen gebaut
Es war eine einzelne, aber modularisierte .NET-Anwendung, in F# geschrieben und nach der Onion-Architektur (Ports-&-Adapters-Muster) aufgebaut
Auch Dinge wie GraphQL habe ich ignoriert und stattdessen einfach auf den altmodischen REST-Ansatz gesetzt
Ergebnis
- Die API ist sehr robust und schnell. Im Betrieb treten fast nie Probleme auf
- Ich kann es nicht beweisen, aber ich denke, dass ein Großteil dieses Erfolgs auf meinen Ansatz mit "Applied Functional Programming" zurückgeht
- Außerdem ist F#-Code sehr schön, gut lesbar und leicht verständlich
- Da ich nur von sehr wenigen Open-Source-Bibliotheken abhänge, ist es kein Problem, dass das F#-Ökosystem relativ klein ist und sich langsam bewegt

Persistence

Ich habe lange SQL Server genutzt, wollte aber keine Lizenzkosten für die Datenbank tragen
Deshalb habe ich PostgreSQL gewählt, das die API auf einem einzelnen DB-Server nutzt. Mit einem kleinen Queue-Mechanismus
Das Produkt brauchte einen BLOB-Speicher, also habe ich mich entschieden, einfach das Dateisystem des Servers zu verwenden
Ergebnis
- Es funktioniert einfach (It just works). Mit Postgres zu arbeiten ist angenehm
- Der JSONB-Datentyp macht es möglich, relationale und NoSQL-Techniken kombiniert zu nutzen. Auf sehr stabile und komfortable Weise
- Die JSON-Abfragesyntax muss man sich wohl nicht merken
- BLOBs einfach auf der Festplatte zu speichern ist eine größere Entscheidung, aber etwas wie AWS S3 hätte bei der kleinen Nutzerzahl wahrscheinlich keinen großen Nutzen gebracht

Web App

Die Technologieentscheidung für die Web-App hat ziemlich lange gedauert
Mein Bauchgefühl sagte mir, ich solle Fable und F# wählen, aber am Ende entschied ich mich für React und TypeScript und baute eine SPA
Eine wichtige frühe Entscheidung war die Einführung von Tailwind CSS
Ergebnis
- React just works, TypeScript just works
- Genau wie bei Dart schreibe ich TypeScript nicht besonders gern und lese es auch nicht besonders gern
- TS hat aber einige großartige Features. Funktionen wie Discriminated Unions hätte ich auch gern in F#
- Insgesamt ist die Developer Experience hervorragend. Die Build-Zeiten sind extrem kurz (im Vergleich zu F#), und für die meisten komplexen UI-Probleme gibt es bereits Pakete
- Auch aus Sicht der funktionalen Programmierung ist das Gesamtmodell von React für Anwendungen nachvollziehbar
- Tailwind CSS nimmt enorm viel Last ab

Infrastructure

Mit der Entscheidung für einen Monolithen wurde die Wahl einfacher
Ich habe bei Hetzner eine Linux-Maschine gemietet und darauf 3 Docker-Container betrieben: Postgres, DotNet API, Nginx
Alles wird mit GitHub Actions gebaut und automatisch deployt
Ergebnis
- Wenn Client und Backend gleichzeitig deployt werden, gibt es Downtime, aber derzeit ist sie kurz und vernachlässigbar
- Der gesamte Prozess ist schlank und stabil, und die Kostenstruktur ebenso. Hetzner ist wirklich günstig

Fazit

Ich bin mit den aktuellen Entscheidungen sehr zufrieden
Ich habe in F# und funktionale Programmierung in größerem Umfang investiert als im vorherigen Projekt
Drei Sprachen im Projekt, nämlich F#, TypeScript und Dart, sind etwas viel
Dotnet MAUI ist nicht so ausgereift wie Flutter, könnte aber eine Option sein anstelle einer anderen Sprache, die man nicht oft verwendet

3 Kommentare

coremaker 2022-09-27

Wird die Personalbeschaffung langfristig reibungslos funktionieren?

xguru 2022-09-27

Das ist vermutlich ein Service, der von einer einzelnen Person betrieben wird. Es wirkt so, als hätte er eher danach entschieden, was für ihn selbst leichter zu warten ist, als nach dem verfügbaren Personal.