Retour d’expérience sur les choix technologiques pour mon SaaS

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

Retour sur les technologies choisies il y a 2 ans pour créer le mobile, le web et le backend, avec un bilan rétrospectif C’était un SaaS très simple et assez générique, avec pour objectif de le lancer rapidement en bootstrapping avec un minimum d’efforts et de ressources Mes compétences en design étant limitées, je n’ai pas développé l’application mobile moi-même et je l’ai sous-traitée, en ne développant que le backend et le web Choix technologiques Application mobile J’étais un développeur .NET de longue date, mais je ne voulais pas développer avec Xamarin J’ai choisi Flutter pour prendre en charge iOS et Android en même temps En quelques semaines, une application fonctionnant sur les deux plateformes était prête, donc du point de vue du time to market, c’était excellent L’UI avait quelques défauts, mais dans un cas d’usage B2B comme le nôtre, c’était acceptable Flutter lui-même avait pas mal de bugs et de problèmes, mais rien de bloquant Je n’aimais pas particulièrement Dart comme langage, mais ce n’était pas un vrai problème. (De toute façon, ce n’est pas moi qui développais) Il aurait peut-être été préférable de rester simplement sur Xamarin ou de choisir React Native API La scalabilité n’était pas un enjeu majeur. Il suffisait de le fournir à quelques-uns des premiers clients J’ai donc totalement écarté Kubernetes, le serverless, etc., et développé simplement en monolithe C’était une application .NET unique mais modulaire, codée en F# et suivant une architecture Onion (pattern Ports & Adapters) J’ai aussi ignoré des choses comme GraphQL pour rester sur une approche REST à l’ancienne Résultat L’API est très solide et rapide. Presque aucun problème n’est survenu en production Je ne peux pas le prouver, mais je pense que l’essentiel de ce succès vient de l’approche d’"Applied Functional Programming" que j’ai utilisée Le code F# est aussi très beau, facile à lire et à comprendre Comme nous dépendons de très peu de bibliothèques open source, le fait que l’écosystème F# soit relativement petit et avance lentement n’a pas posé de problème Persistance J’utilisais SQL Server depuis longtemps, mais je ne voulais pas supporter des coûts de licence pour la base de données J’ai donc choisi PostgreSQL, utilisé par l’API sur un serveur de base de données unique, avec un léger mécanisme de file d’attente Le produit a fini par nécessiter un stockage BLOB, et j’ai simplement décidé d’utiliser le système de fichiers du serveur Résultat Ça fonctionne, tout simplement (It just works). Travailler avec Postgres est un plaisir Le type de données JSONB permet de combiner des techniques relationnelles et NoSQL d’une manière très stable et confortable Je doute qu’il soit nécessaire de mémoriser la syntaxe des requêtes JSON Stocker les BLOB directement sur disque est une décision importante, mais utiliser quelque chose comme AWS S3 n’aurait probablement pas apporté grand-chose avec un faible nombre d’utilisateurs Application web La décision technologique pour l’application web a pris assez longtemps Mon intuition me poussait à choisir Fable et F#, mais j’ai finalement décidé d’utiliser React et TypeScript pour construire une SPA Une des décisions importantes prises au début a été d’adopter Tailwind CSS Résultat React just works, TypeScript just works Comme avec Dart, je n’aime pas vraiment écrire du TypeScript, ni particulièrement en lire Cela dit, TS a d’excellentes fonctionnalités. Des fonctionnalités comme les discriminated unions me manqueraient presque en F# Globalement, l’expérience développeur est excellente. Les temps de build sont extrêmement courts (comparés à F#), et des packages existent déjà pour la plupart des problèmes d’UI complexes Même sous l’angle de la programmation fonctionnelle, le modèle global d’application de React reste compréhensible Tailwind CSS enlève une énorme charge Infrastructure Le choix est devenu facile une fois la décision prise d’aller vers un monolithe J’ai loué une machine Linux chez Hetzner, et fait tourner 3 conteneurs Docker : Postgres, l’API DotNet et Nginx Tout est buildé avec GitHub Actions et déployé automatiquement Résultat Déployer le client et le backend en même temps provoque un temps d’arrêt, mais pour l’instant il est court et négligeable L’ensemble du processus est léger, stable, et la structure de coûts l’est aussi. Hetzner est vraiment peu cher En résumé Je suis très satisfait des décisions actuelles J’ai davantage investi dans F# et le travail en programmation fonctionnelle que sur mes projets précédents Avoir trois langages dans le projet — F#, TypeScript et Dart — fait peut-être un peu trop Dotnet MAUI n’est pas aussi mature que Flutter, mais pourrait rester une option au lieu de choisir un autre langage qu’on n’utilise pas souvent

(thomasbandt.com)

18 points par xguru 2022-09-27 | 3 commentaires | Partager sur WhatsApp

Retour sur les technologies choisies il y a 2 ans pour créer le mobile, le web et le backend, avec un bilan rétrospectif
C’était un SaaS très simple et assez générique, avec pour objectif de le lancer rapidement en bootstrapping avec un minimum d’efforts et de ressources
Mes compétences en design étant limitées, je n’ai pas développé l’application mobile moi-même et je l’ai sous-traitée, en ne développant que le backend et le web

Choix technologiques

Application mobile

J’étais un développeur .NET de longue date, mais je ne voulais pas développer avec Xamarin
J’ai choisi Flutter pour prendre en charge iOS et Android en même temps
En quelques semaines, une application fonctionnant sur les deux plateformes était prête, donc du point de vue du time to market, c’était excellent
L’UI avait quelques défauts, mais dans un cas d’usage B2B comme le nôtre, c’était acceptable
Flutter lui-même avait pas mal de bugs et de problèmes, mais rien de bloquant
Je n’aimais pas particulièrement Dart comme langage, mais ce n’était pas un vrai problème. (De toute façon, ce n’est pas moi qui développais)
Il aurait peut-être été préférable de rester simplement sur Xamarin ou de choisir React Native

API

La scalabilité n’était pas un enjeu majeur. Il suffisait de le fournir à quelques-uns des premiers clients
J’ai donc totalement écarté Kubernetes, le serverless, etc., et développé simplement en monolithe
C’était une application .NET unique mais modulaire, codée en F# et suivant une architecture Onion (pattern Ports & Adapters)
J’ai aussi ignoré des choses comme GraphQL pour rester sur une approche REST à l’ancienne
Résultat
- L’API est très solide et rapide. Presque aucun problème n’est survenu en production
- Je ne peux pas le prouver, mais je pense que l’essentiel de ce succès vient de l’approche d’"Applied Functional Programming" que j’ai utilisée
- Le code F# est aussi très beau, facile à lire et à comprendre
- Comme nous dépendons de très peu de bibliothèques open source, le fait que l’écosystème F# soit relativement petit et avance lentement n’a pas posé de problème

Persistance

J’utilisais SQL Server depuis longtemps, mais je ne voulais pas supporter des coûts de licence pour la base de données
J’ai donc choisi PostgreSQL, utilisé par l’API sur un serveur de base de données unique, avec un léger mécanisme de file d’attente
Le produit a fini par nécessiter un stockage BLOB, et j’ai simplement décidé d’utiliser le système de fichiers du serveur
Résultat
- Ça fonctionne, tout simplement (It just works). Travailler avec Postgres est un plaisir
- Le type de données JSONB permet de combiner des techniques relationnelles et NoSQL d’une manière très stable et confortable
- Je doute qu’il soit nécessaire de mémoriser la syntaxe des requêtes JSON
- Stocker les BLOB directement sur disque est une décision importante, mais utiliser quelque chose comme AWS S3 n’aurait probablement pas apporté grand-chose avec un faible nombre d’utilisateurs

Application web

La décision technologique pour l’application web a pris assez longtemps
Mon intuition me poussait à choisir Fable et F#, mais j’ai finalement décidé d’utiliser React et TypeScript pour construire une SPA
Une des décisions importantes prises au début a été d’adopter Tailwind CSS
Résultat
- React just works, TypeScript just works
- Comme avec Dart, je n’aime pas vraiment écrire du TypeScript, ni particulièrement en lire
- Cela dit, TS a d’excellentes fonctionnalités. Des fonctionnalités comme les discriminated unions me manqueraient presque en F#
- Globalement, l’expérience développeur est excellente. Les temps de build sont extrêmement courts (comparés à F#), et des packages existent déjà pour la plupart des problèmes d’UI complexes
- Même sous l’angle de la programmation fonctionnelle, le modèle global d’application de React reste compréhensible
- Tailwind CSS enlève une énorme charge

Infrastructure

Le choix est devenu facile une fois la décision prise d’aller vers un monolithe
J’ai loué une machine Linux chez Hetzner, et fait tourner 3 conteneurs Docker : Postgres, l’API DotNet et Nginx
Tout est buildé avec GitHub Actions et déployé automatiquement
Résultat
- Déployer le client et le backend en même temps provoque un temps d’arrêt, mais pour l’instant il est court et négligeable
- L’ensemble du processus est léger, stable, et la structure de coûts l’est aussi. Hetzner est vraiment peu cher

En résumé

Je suis très satisfait des décisions actuelles
J’ai davantage investi dans F# et le travail en programmation fonctionnelle que sur mes projets précédents
Avoir trois langages dans le projet — F#, TypeScript et Dart — fait peut-être un peu trop
Dotnet MAUI n’est pas aussi mature que Flutter, mais pourrait rester une option au lieu de choisir un autre langage qu’on n’utilise pas souvent

3 commentaires

coremaker 2022-09-27

À long terme, le recrutement sera-t-il fluide ?

xguru 2022-09-27

Il s’agit probablement d’un service exploité par une seule personne. On dirait qu’il a privilégié ce qui lui serait le plus facile à maintenir lui-même plutôt que la question des effectifs.