12. Conclusion

Nous avons écrit le client [Vue.js] de l'application [RdvMedecins]. Pour l'utilisateur, il offre les mêmes pages que l'application HTML du cours [NestJS] ; pour le développeur, tout a changé de place :

• le serveur ne fabrique plus de pages. Il expose une API JSON, dont le contrat (routes, corps, codes et clés d'erreur) a suffi pour écrire le client, sans jamais lire son code ;
• les pages, la langue, la mise en forme, les messages, la navigation se sont déplacés dans le navigateur ;
• la sécurité, elle, n'a pas bougé : c'est toujours le serveur qui authentifie (cookie [HttpOnly]), qui vérifie les rôles et les règles de gestion, et qui décide de ce qu'un patient a le droit de voir. Le client ne fait qu'afficher ce que le serveur lui envoie.

Le même serveur JSON pourrait servir d'autres clients : une application mobile, un client [Angular] ou [React], un script. C'est tout l'intérêt de séparer le client du serveur par une API.

Les notions de [Vue.js] rencontrées dans ce cours (composants, réactivité, routeur, stores, composables) sont celles de toute application [Vue.js]. Pour aller plus loin :

• la documentation officielle, en français : https://fr.vuejs.org ;
• les tests : [Vitest] pour les tests unitaires des composants et des composables, [Playwright] pour les tests de bout en bout (c'est avec lui qu'ont été faites les copies d'écran de ce document) ;
• [Nuxt], le framework construit sur [Vue.js], qui sait aussi fabriquer les pages côté serveur : on retrouverait alors, en partie, l'architecture du cours [NestJS].