Cet article est le dernier dʼune série ayant pour but de présenter Serverpod. Ainsi nous avons précédemment démontré le développement dʼun backend complet(authentification, définition dʼun modèle de données et implémentation de endpoints) à travers une application fil rouge. Ainsi nous allons ici finaliser lʼexploration de cet ORM en reliant notre backend à notre application Flutter tout en concluant sur les forces et faiblesses de ce package.
V. Liaison du backend avec une application Flutter
Vous vous souviendrez que nous avions déclaré deux singletons lors de la mise en place de lʼauthentification au sein de notre projet Flutter ( lib/main.dart ) comme suit :
Au final nous avons déjà presque tout implémenté. En effet, maintenant que nous avons généré le code côté serveur avec la partie endpoint, nous pouvons utiliser notre singleton client pour appeler les méthodes de nos endpoints à nʼimporte quel endroit de notre application (ce singleton étant global au projet) :
Ainsi, vous pouvez interagir avec ces endpoints ou les personnaliser selon vos besoins pour intégrer votre propre interface utilisateur. Bien que je ne détaillerai pas ici ligne par ligne lʼimplémentation du frontend dʼune application Flutter, car nʼétant pas lʼobjectif principal de cet article, vous pouvez vous référer à mon projet GitHub (qui comprend les projets serveur, client et Flutter) pour un exemple dʼimplémentation complet.
Pour conclure ce chapitre, je vous invite à regarder une démonstration vidéo de mon implémentation de lʼapplication dʼexemple de cet article : lien vers la démo. Cette démonstration vous donnera un aperçu pratique de la façon dont le backend et le frontend peuvent être intégrés de manière efficace entre Serverpod et Flutter.
VI. Conclusion
En définitif, Serverpod est une alternative complète pour la mise en place dʼun backend avec Dart facilitant son intégration au sein dʼune application Flutter notamment pour des néophytes de ce domaine comme je le suis.
Dʼautant plus que même si cet article couvre un large éventail de ce quʼoffre Serverpod, de nombreuses autres fonctionnalités sont disponibles comme :
- la gestion de la pagination des objets
- la gestion des referential actions côté SQL
- la gestion du déploiement du server
- la gestion de scopes dʼauthentification (admin...)
- et bien dʼautres...
Cependant, ce package souffre que quelques inconvénients. En effet, il nʼy a pour lʼheure que peu de communauté autour de ce package. Par conséquent, il est parfois complexe de trouver des réponses à ses questions lorsque lʼon bute sur une implémentation (peu de discussion sur les forums...) comme jʼai pu notamment le souligner pour le cas des tests des endpoints avec Postman. Endpoints qui ne respectent pas réellement les meilleures pratiques API. Effectivement, il nʼy a pas de gestion de requêtage GET, POST, PUT, DELETE mais un même endpoint qui pourra jouer plusieurs méthodes en fonction des paramètres de son corps JSON. Deplus, on ne retrouve pas de gestion de tokens JWT pour lʼauthentification mais un autre système que nous avons détaillé dans cet article.
Néanmoins, les développeurs dernière ce package ont lʼair déterminé à améliorer Serverpod. En effet, ils font bonne réception des retours des développeurs. Par exemple une gestion des tokens JWT que nous abordions précédemment est prévue dans une prochaine version comme indiqué sur la roadmap du projet.
Ainsi, je pense que Serverpod est un package en devenir qui sera ravir les développeurs Flutter néophytes du domaines du backend sʼils cherchent à implémenter une application de A à Z. Enfin, à titre personnel, Serverpod mʼa permis de gagner en compréhension sur certains aspects backend et à appréhender de nouveaux concepts (transactions, relations...).
En somme, il ne nous reste plus quʼà continuer dʼexplorer Serverpod tout en surveillant son évolution.
Quentin Lebreton - Ingénieur Etudes et Développement Junior