Retour d’expérience sur Angular JS + Web API 2 + Oauth2
Démo live Listy : http://listy.reactor.fr Pour la petite histoire, on m’a demandé de faire un devis concernant une application web. Normalement on ne commence pas le travail tant qu’on a pas un acompte et surtout un cahier des charges bien ficelé. Surtout lorsque le client n’est au final plus trop sur de lui… qu’il doit réfléchir. Bref vous l’avez compris, j’ai travaillé à perte. Mais j’ai beaucoup gagné en compétence… En effet le sujet est simple : créer une liste d’envie sur internet. Il en existe déjà quelques une plus ou moins abouties. Le principe consiste à faire une liste de course avec des liens web et de sortir une liste au final à partager avec ses amis. Au premier abord, pas un énorme intérêt. Dans mon cas personnel j’adhère à l’idée pour noël, au lieu d’acheter des cadeaux pourris (chose que l’on fait quand même pour le fun), on se fait une liste d’objets utiles ou qui peuvent nous intéresser, chacun s’organisant comme il veut pour offrir le ou les cadeaux en question. J’avais besoin d’un projet comme celui ci pour enfin me former sur Angular. Entre temps j’ai fait une conf sur Angular 2 et bon… je tombe mal on va dire. Mais l’expérience en valait la peine. Ici je vais vous présenter ce que j’ai fait, les méthodes utilisées, les softs, plateformes… et surtout ce qui m’a posé problème en vous donnant les solutions. 1) Architecture : Je voulais une architecture qui me permet de totalement découpler les services de l’application. Un peu d’historique : 1) Il y a quelques années, et ça se fait encore bien sur, on avait un site web (Asp.net WebForm) hébergé sur un IIS qui avait sa propre base de donnée. Du all in one. Très pratique. En effet pour accéder aux données on pouvait directement taper dans la BD pour afficher une donnée. Depuis les développeurs ont structuré leurs applications en ajoutant des couches, notamment la couche d’accès aux données (DAL) et une couche métier. Avantage : plus propre, réutilisable, maintenance plus simple, on peut changer de BD sans tout péter…Inconvénient, plus compliqué pour un débutant, plus de code donc un peu plus lourd à maintenir (oui c’est aussi écrit en avantage…) 2) On a vu ensuite apparaitre dans Visual Studio le modèle MVC. Depuis on ne parle que de lui. D’ailleurs j’ai cru lire quelque part que Microsoft allait laisser tomber WebForms dans ces prochaines versions de Visual Studio. J’ai personnellement mit du temps à m’y mettre. C’est une autre façon de concevoir son application qui a aussi ses avantages et inconvénients. Mais l’intérêt majeure face aux WebForms, c’est que l’on peut y faire des tests. J’en parlerai pas ici, c’est pas mon fort. La encore on avait tendance à accéder aux BD directement, soit en mode crado, soit via une couche. 3) Puis les sites webs ont proposé des fonctionnalités que l’on aurait bien vu dans nos mobiles, dans une application. Problème : comment accéder à nos données ? Sur le site web, on a quelques éléments de sécurité et fonctionnalités « intégrés » de façon native (la session, le système de fichier, droit utilisateurs, …) ce que j’appelle du all in one. Mais la le client, c’est à dire l’application mobile est totalement déconnecté de mon environnement de production. Qui plus est, sur un OS potentiellement différent et potentiellement dangereux, pas stable, hostile… pire entre les deux on a INTERNET le mal absolut si j’en crois mon ancien employeur Jaques Séguéla… Qui depuis à compris qu’il pouvait se faire du blé alors il a changé d’avis. Bref, comment faire ? Pour cela un web service était nécessaire. Jusque la j’avais travaillé avec SOAP. Mais bon SOAP c’est pas vraiment une archi, c’est plutot un protocole. Et puis SOAP c’est chiant. Depuis on ne parle plus (ou presque) que de REST. REST (Representational State Transfer) comme son nom ne l’indique pas est sans état (en fait dans le titre on parle d’état d’une ressource, et non de l’application). Ceci à des conséquences pour l’expérience utilisateur, surtout pour les « sessions » car en faite il n’y en a pas ! Vous pouvez laisser votre application dans un état et la retrouver dans le même état quelques temps après. En général, par exemple avec Asp.net WebForm, votre temps de sessions par défaut était de 20 min. Les développeur avait tendance à stocker pas mal de chose dedans. C’était très pratique mais on perdait tout ou presque à la fin de session (sauf bricolage ou stockage en BD). Ici pas de session. Cela va avoir un impact pour la sécurité de nos données (nous le verrons plus tard). Mais surtout, enfin pour moi, l’expérience utilisateur va en être affecté positivement : suivant le niveau de sécurité voulut, on peut maintenir un équivalent « session » sur plusieurs heure, voir jour. Comme sur Facebook ou l’on a pas besoin de se reconnecter toutes les heures. Un autre intérêt de REST c’est qu’au niveau maintenance et évolution des serveurs c’est plus simple à gérer. Mais le gros gros intérêt de REST, c’est qu’il vous permet de gérer n’importe quel type de client. Ici nous parlerons d’un client web Angular.js, mais rien ne vous empêche de créer une app Native Android ou un client Windows 10, le serveur n’aura besoin d’aucun update ! Il est prêt pour tout, ce qui change du tout au tout par rapport à un site php ou asp.net. (moins vrai avec la dernière version d’Asp.net qui combine MVC et API2) Coté client la encore, de la souplesse. J’utilise Angular principalement pour des raisons de formation, mais aussi pour éventuellement reprendre ce code et l’utiliser avec Ionic ! Ce formidable framework est basé sur Angular et propose de déployer son app, grâce à Cordova, sur plusieurs OS mobile comme iOS, Android ou Windows Phone. Donc vous l’aurez compris, utiliser ce genre d’architecture permet de voir loin ! 2) La construction Pour l’IDE, j’ai opté pour Visual Studio 2015, normal vu que je…