Backend custom, oui non peut-être?

[luclu7]

Avantage du backend actuel (Appwrite)

• Tout est unifié !
  • Stockage (~S3)
  • BDD
  • Auth
    • Permissions
  • Serverless function
  • Push
• SDK pour web/serveur (utilisation simple)
• c'est pratique de pouvoir déployer les fonctions séparément

Problème avec le backend actuel (Appwrite)

• pas end-to-end type-safe
• le KV n'est pas très propre (la manière de faire du UNIQUE est pas terrible, surtout côté front après)
• pas en contrôle total sur certaines briques
  • BDD: difficile de faire des liens parfois, à la main (entre les utilisateurs standistes et leur stand, ainsi qu'entre les utilisateurs et leurs soumissions)
  • obligé de faire une fonction serverles pour récupérer la clé privée d'un utilisateur pour le staff
• besoin d'une fonction serverless dès qu'on veut un peu de code

Avantage avec un futur backend manuel

• Plus besoin de serverless function pour rien et de bricolage !
• Typage end-to-end donc meilleure expérience de dev

Problème avec un futur backend manuel

• c'est chiant de dev à la main ce qui a déjà été dev
• avoir le sujet du déploiement
• Plusieurs briques à gérer nous même

---

Besoin d'un nouveau backend

Si monolithe (le plus probable) :

• Stockage (S3: Minio? À la main?)
• BDD (Postgres)
• Monolithe:
  • Auth (Betterauth? À la main?)
    • Permissions
  • Push
• communication app/web: type safe (tRPC? SDK sur un OpenAPI?)

Du coup autre sujet: l'hébergement