Les startups fonctionnent dans une extrême incertitude. Vous ne savez pas si le produit aura du succès, mais vous devez le lancer pour le savoir. Dans ce scénario, la « meilleure pratique » du backend n'est pas la plus robuste ou la plus évolutive, c'est la plus agile.
Construire le backend d'une startup est l'art de choisir des raccourcis intelligents (Conscious Technical Debt) qui permettent d'accélérer sans rendre l'avenir irréalisable.
1. Monolithe d'abord
Oubliez les microservices. Sérieux. Les frais généraux liés à la gestion de 10 services différents, 10 déploiements, réseaux et journaux distribués tueront votre productivité.
- La pratique : Créez un backend unique (Monolith) bien organisé. Il est plus facile de tester, de déployer et de comprendre. Si un jour tu deviens Uber, tu te décomposes en microservices.
2. Choisissez des technologies « ennuyeuses »
N'utilisez pas la [2] nouvelle base de données publiée la semaine dernière sur Hacker News. Utilisez ce que l’équipe sait et ce que possède la communauté.
- Langages : Node.js, Python, Ruby, PHP.
- Base de données : PostgreSQL ou MySQL. Si vous rencontrez un problème dans Postgres, quelqu'un sur StackOverflow a déjà eu ce problème en 2012 et la réponse est là.
3. Infrastructure en tant que service (PaaS)
Ne perdez pas de temps à configurer le serveur Linux, le pare-feu et l'équilibreur de charge sur AWS EC2. Utilisez des plateformes comme Heroku, Render ou Vercel. Ils coûtent un peu plus cher, mais vous connectez GitHub et le déploiement se fait comme par magie. Le temps de votre ingénieur coûte plus cher que la différence sur votre facture cloud.
4. API de repos standard
N'inventez pas de modes API. Suivez le modèle REST. Utilisez correctement les verbes HTTP (GET, POST, PUT, DELETE). Utilisez les codes d'état (200, 404, 500). Cela facilite la vie de ceux qui consommeront l’API (le développeur de l’application) et de ceux qui la maintiendront par la suite.
5. Documentation automatique
Personne ne s’arrêtera pour rédiger un PDF de documentation. Utilisez des outils tels que Swagger (OpenAPI) qui lisent votre code et génèrent automatiquement une page de documentation API. Cela évite le message « Hé, quel est le point de terminaison de connexion ? » sur Slack toutes les 5 minutes.
Conclusion
Pour une startup, le code n’est pas un atout ; c'est un coût. L'actif est le produit qui se trouve entre les mains de l'utilisateur. Votre backend doit être simple, fonctionnel et facile à modifier. La perfection technique est l’ennemi de l’innovation rapide.
A lire aussi
-Backend pour les applications : architecture, technologies et bonnes pratiques -Backend pour les applications - Bonnes pratiques de mise à l'échelle