Signoz et OpenTelemetry avec une app .net sous linux

Disclamer A l’heure ou j’écris cet article, le code source d’OpenTelemetry et Signoz sont en alpha/beta/pre-release.  Certaine lib sont en release officielle. J’édite au fur et à mesure certaine infos. Le code évolue et cet article aussi.  Il n’est certainement plus « à la page » lorsque vous lirez ces ligne.  Et de même, la doc officielle, celle de Microsoft et les ReadMe des repos ne sont pas tous mis à jours en temps et en heure.  C’est un sujet chaud pattate !!! Besoins Comme d’habitude, j’écris un article avec un vrai besoin et une application dans la vraie vie.  J’ai un serveur en prod et je souhaite le monitorer pour : observer son comportement (nombre de requêtes, % de CPU/RAM/Disk, periode d’activité/repos etc) analyser des problèmes, avoir accès aux logs sans ouvrir un terminal être alerté en cas de problème et pouvoir définir ces alertes avoir une vue d’ensemble avec des KPI de base   Contexte Depuis peu (qq années) on a la possibilité de faire tourner du .net sous linux. Ca change quoi allez vous me dire ?  Personnelement une question de coût. Un VPS (virual private server) sous linux c’est au moins deux fois moins cher que sous Windows (ça dépend avec quel fournisseur et les prix ont aussi évolué dans le temps). Mais aujourd’hui un VPS linux est utlra compétitif. Et j’ai pas de besoin cloud (même si j’y pense). Avec Windows on était habitué à installer des outils graphiques supplémentaires. Et meme de base on avait des outils de monitoring. Sous linux, c’est moins évident car on utilise principalement la ligne de commande. Et personnellement j’y retrouve pas mon compte. Même si on peut aussi mettre une interface graphique, c’est pas le but d’un serveur. Enfin, je voudrais pouvoir consulter ceci sans me loguer en ssh (depuis une interface web) et avoir des alertes email et sms serait top.  Actuellement je développe un nouveau produit (https://outquest.fr). Celui ci comporte un site web (game) et un site backoffice (qg). Le site officiel (outquest.fr) et le shop sont hébergés ailleurs (planethoster). J’ai une prod et un staging. (donc 4 site webs au final). J’ai commencé avec un serveur low cost à 2.99€/mois (Debian, 1 core,  2 Go Ram, 25Go SSD …) chez Ikoula. Franchement à ce prix la, ça marche bien pour faire tourner 4 sites webs.(avec que moi dessus hein !) Ces 4 sites web tournent sous 4 services kernel (autorestart) linux et géré par un serveur web frontal NGinx.  –> pour la config voir cet article J’ai de plus une CI/CD géré par azure devops (voir article Azure Devops) qui me permet via des pipelines de deployer automatiquement mon code sur les serveurs web respectif à chaque push git sur mes branches dev et master.  Ca a dla gueule ! Pour un mec tout seul (pour le moment) je sors la grosse artillerie. J’aurais pu partir direct avec un site web en prod et debuger dessus à l’ancienne. Mais j’aime bien apprendre à faire les choses bien :). Et justement, pour faire bien, la prochaine étape c’est le monitoring des serveurs (ya aussi les backups, je pense que j’en ferai un article à part).  Du coup j’ai voulu tester une solution qui me paraissait pas mal, un APM (Application Performance Management) : CheckMK.  Le souci c’est que j’ai vu trop gros (ce machin permet de gérer tout un parc informatique, plusieurs serveurs, node, kubernetes…) Et en l’installation, le machin à fait fondre mon serveur. Plus moyen d’y accéder pendant un temps et pas moyen de le redémarrer (j’ai contacté le support, ce qui m’a pris plusieurs jours, à ce prix la fallait pas attendre des miracles.) Le bon moment pour passer à un niveau supérieur.  A ce stade j’avais ma prod et mon staging sur la meme petite bécanne. Du coup je me dis qu’il faudra quand meme passer sur qq chose de plus sérieux pour la prod. J’ai donc opté pour un VPS OMGServ avec cette config :  Et une option payante supplémentaire de backup. (snapshots) CheckMK tourne déjà beaucoup mieux, mais comme je le disais c’est pas une solution pour moi. Ca install une bardé de trucs dont Apache2, qui fout la merde avec mon Nginx.  Après qq recherches, je suis tombé sur Signoz et OpenTelemetry. Et c’est ce qu’il me faut !   Signoz   Signoz est une interface web permettant de visualiser un ensemble de données sur votre serveur linux.  C’est une solution Open Source, récente et encore en dev. C’est un concurrent à DataDog (payant).  Elle permet de monitorer des applications et de fournir des éléments pertinents pour les devops.  Cette solution naît d’un constat. Les équipes techniques sont frustrées d’utiliser pleins d’outils différents provenants de sources de données elles aussi différentes pour voir leurs logs/metrics/traces …   De plus les outils existants sont « lourds », taillé pour de la grosse boite (faut bien vendre) avec des standards propriétaires et non générique.  Je n’ai pas de recul suffisant mais mon sentiment c’est que c’est compliqué et qu’un outil simple, uniformisé gratuit et open source manquait à ce niveau pour un niveau « intermediaire » (PME, TPME, indé) Un standard est en train d’émerger concernant toute ces données que l’on appelle OpenTelemetry. OpenTelemetry Encore un nouveau framework ? C’est quoi, une couche de plus ? OpenTelemetry c’est une collection d’outil, d’APIs et de SDKs permettant de mesurer, generer, collecter et exporter des données de télémetrie (metrics, logs et traces) afin de mieux analyser le comportement et les performances de nos applications.  Super mais qui porte le truc ? Est ce que c’est un projet qui va être adopté ? Oui, en tout cas par Microsoft : https://learn.microsoft.com/en-us/azure/azure-monitor/app/opentelemetry-overview Vu l’investissement de Microsoft pour les projets à succès Open Source, et vu le besoin, je pense qu’OpenTelemetry a de l’avenir.  Installer Signoz Il existe plusieurs façon d’installer Signoz, j’ai choisi pour ma part la version Standalone (https://signoz.io/docs/install/docker/) sur mon VPS linux Debian 11. Vous devrez télécharger le repo git : git clone -b main https://github.com/SigNoz/signoz.git puis vous rendre dans le répertoire suivant :…

Cloud VPS Hebergement asp.net Framework et Core

Je commence à avoir ma petite expérience concernant l’hébergement d’un site asp.net. Et je vais vous en faire part. Je n’ai qu’une contrainte, faire tourner asp.net. Donc ça implique Windows. Enfin jusqu’à ce que je fasse le deuil de mes sites asp.net qui n’ont pas été migrés en .net Core. On reviendra sur ce point plus tard.  J’en profite pour hoster qq site web vitrine pro, des sites de POCs, des projets perso et pro etc… J’ai du monter facile à une quinzaine de site web. Pendant un temps. VPS OVH 40€/mois J’ai du commencer à louer un serveur vers 2010, avec 1&1 qui s’est rebatisé IONOS. C’était pas top de mémoire. Je suis passé chez OVH et pendant presque 8 ans ça a bien tourné.  Un jour j’ai eu un udpate de Windows qu’a foutu la merde. Mon serveur ne voulait plus redémarrer, il restait coincé juste apres le login. Mode sans échec ne faisant rien. Bref, à distance, je pouvais rien faire. Et j’ai donc eu à faire avec le support d’OVH. Chose en 8 ans que je n’avais pas eu à faire.  C’est la que j’ai entendu parlé de la réputation désastreuse de ce support qui est fondé. Un ticket est traité avec lenteur voir meme laissé comme mort pour être automatiquement détruit dans le temps. Bref, mon serveur en caraf pendant plusieurs jours voir semaine, m’a ammené à étudier la concurrence.  L’offre VPS linux est toujours abordable. Le problème c’est l’ajout d’un serveur Windows. Ca a un coup. Qui je l’apprendrai plus tard, est plus cher chez les concurrents. Je trouvais aussi les performances du serveur OVH un peu à la ramasse. De plus il m’occroyait seulement 50Go (Windows en bouffant un tiers, voir la moitié) et je passais souvent du temps a faire du ménage. Bref, il me fallait un coup de pied au cul pour bouger. Cloud Azure Je suis développeur .net Microsoft depuis maintenant 20 ans. J’ai donc suivis Azure de près.  Pas assez car je pige toujours pas combien ça coute. Ca Microsoft l’a bien compris et donc il propose 12 mois gratos avec un maximum de 150€ / mois je crois. Ce qui laisse largement assez pour tester plein de truc.  C’est ce que j’ai fait. Seulement j’ai jamais mis mes sites dessus. Par paresse car tout marchait bien sur OVH. Donc je suis resté sur des essais seulement.  Mais je dois dire que c’est un sacré bordel Azure… Cloud AWS J’ai tenté l’expérience AWS. Ce que j’aimais bien c’est qu’on pouvait tout faire en ligne de commande (sur Azure aussi, mais je l’ai testé bien plus tard). Ce qui me pose problème avec AWS c’est le controle des couts. J’ai tenté de rester au maximum gratuit. Mais c’est facile de sortir des cases sans s’en rendre compte. J’ai donc laissé un site web + BD de tester tourner (sans visite) et ca m’a quand même couté 17€/mois.  Car c’est malheureux, mais tout est décomposé. Faut une base de donnée qui est un service a part. De la resource calcul, des firewalls, de la réplication si on veut bien faire… Bref, ça part d’un truc simple et on se retrouve avec une usine a Gaz. Sans maitrise des couts.  Le pire c’est que lorsque j’ai tout fermé, j’avais quand meme des factures à 0.01€. Ce qui me laissait un gout de beau bordel… VPS Scaleway Dedibox 60€/mois Dedibox m’a séduit. Au début. Déjà parce que je pensais qu’avec le même budget précedent chez OVH, dans les 40€/mois, j’allais avoir un serveur dédié et plus de ressource. C’était vrai. Sauf pour le prix. En effet l’option Windows est cher, et elle n’est pas fixe (par CPU je crois). Elle évolue avec le pack que l’on choisit. Bref j’ai augmenté mes couts. Je passe à 60€. J’avais aussi un nouveau projet ou je pensais avoir du traffic, donc j’ai anticipé une bonne bécane. Ca a servit à rien mais je pouvais pas le savoir. J’ai donc cherché ailleurs…   Hebergeur PlanetHoster 6€/mois J’y croyais pas trop, mais au final quelle surprise ! J’ai dégagé Dedibox qui me coutait trop cher, et je suis tombé sur PlanetHoster. On peut mettre autant de site que l’on veut, tant qu’on a un peu de resource (CPU, Mémoire, IO) En gros on part avec un pack pour 6€ on ceci :  8 CPU16 GB RAM16 MB/s I/O https://www.planethoster.com/fr/Hebergements-World Que l’on répartie sur ses sites comme on veut. Très pratique lorsque l’on s’attend à un pick de charge.  On peut jouer avec du python, node.js, Php et Ruby. Si ils ajoutent .net Core ça serait un must.  Mais j’ai gardé mes sites vitrines et qq POCs. De plus aujourd’hui les sites webs deviennent vite des apps mobile PWA SPA. Donc du JS. J’en ai qq une.  J’ai rajouté qq resources. En tout ca me coute 100€/an. C’est stable, très administrable. Le support répond et résoud les ticket surtout.  Mais bon, comment je fais tourner Asp.net Core ? Ha oui, car à ce stade j’ai laché tout mes anciens site Asp.Net Framework. Je me focalise maintenant sur .net Core.  VPS iKoula 4€/mois Retour au VPS ! Mais ce coup si fini Windows. Bonjour Linux.  Et que ca fait plaisir de voir ces couts aussi bas. Sans déconner, un serveur à 4€ par mois. C’est ouf.  Alors j’ai choisi iKoula, pour essayer. J’ai une offre pas cher. J’aurais pu revenir sur OVH mais ils m’ont trop déçu.  Alors la grosse différence avec les VPS d’avant, c’est que la plus d’interface graphique. Retour à la ligne de commande.   Faut tout monter à la main. Pas grave.  J’ai pas besoin de grand chose : dotnet pour faire tourner un serveur kestrel en proxy Nginx pour serveur web (qui sera devant le proxy kestrel) un firewall, histoire de pas tout laisser ouvert.  letsencrypt pour un certificat ssl. https://docs.microsoft.com/fr-fr/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-6.0   Une fois qu’on a payer sur iKoula, on nous propose de lacher une clé publique RSA pour le SSH. (facultatif). Ensuite il faut se connecter via…

Ocelot

Ocelot est un middleware pour .net core qui permet de créer une « gateway » (un point d’entrée) unique pour un ensemble de micro service. C’est une sorte de router. Par exemple, admetons que l’on est deux services Asp.Net Core (Orders, Customers) qui tournent respectivement sur : localhost:7001 localhost:7002 Chacun ayant un simple controler « racine » qui retourne n’importe quoi. Ils sont à ce stade joigniables uniquement via ces url. On veut maintenant qu’ils soient tous accesibles depuis localhost:7000 : localhost:7000/orders localhost:7000/customers Pour cela on va ajouter le middleware Ocelot https://ocelot.readthedocs.io/en/latest/introduction/bigpicture.html et le configurer avec un fichier de configuration suivant : { « ReRoutes »: [ { « DownstreamPathTemplate »: « /api/orders », « DownstreamScheme »: « http », « DownstreamHostAndPorts »: [ { « Host »: « localhost », « Port »: 7000 } ], « UpstreamPathTemplate »: « /orders », }, { « DownstreamPathTemplate »: « /api/customers », « DownstreamScheme »: « http », « DownstreamHostAndPorts »: [ { « Host »: « localhost », « Port »: 7000 } ], « UpstreamPathTemplate »: « /customers », }, ], « GlobalConfiguration »: { « BaseUrl »; « <http://localhost7000> » } } Et hope, on a nos deux services accessible depuis le même point d’entrée (gateway) localhost:7000 Plus de précision avec cette vidéo :

App Android Perso

[vc_row margin_top= »-30″ margin_bottom= »15″][vc_column offset= »vc_col-lg-8 vc_col-md-8 vc_col-xs-12″][vc_empty_space height= »40px »][vc_column_text] Trésors de Bretagne [/vc_column_text][vc_empty_space height= »16px »][vc_column_text]Petite application Android personnelle listant les monuments et lieux intéressants prêt de chez nous, en Bretagne. https://play.google.com/store/apps/details?id=fr.reactor.breizhmap[/vc_column_text][vc_empty_space height= »30px »][vc_column_text]Tâches effectuées :[/vc_column_text][vc_empty_space height= »16px »][vc_column_text][dt_list style= »1″ bullet_position= »top » dividers= »false »][dt_list_item image= » »]Conception/Design.[/dt_list_item][dt_list_item image= » »]Integration/Animation.[/dt_list_item][dt_list_item image= » »]Développement C# Xamarin.[/dt_list_item][dt_list_item image= » »]Lead dev/ops.[/dt_list_item][/dt_list][/vc_column_text][vc_empty_space height= »30px »][/vc_column][vc_column offset= »vc_col-lg-4 vc_col-md-4 vc_col-xs-12″][vc_empty_space height= »40px »][vc_column_text] Techniques [/vc_column_text][vc_empty_space height= »16px »][vc_progress_bar values= »%5B%7B%22label%22%3A%22D%C3%A9veloppement%20C%23%20Xamarin%20Android%22%2C%22value%22%3A%2290%22%7D%5D » options= »striped,animated » caption_pos= »top »][vc_empty_space height= »40px »][/vc_column][/vc_row]

Xamarin iOS retour d’expérience

  Vous avez tous pu constater le buzz récent autour de Xamarin. J’étais à deux doigts d’acheter une licence iOS qui m’aurait couté dans les 700€. Un brave de chez Xamarin m’a conseillé d’attendre la build de Microsoft, ce que j’ai fait. Un grand merci à ce monsieur de chez Xamarin sans quoi j’aurai été bien bien vénère, il m’a fait économiser beaucoup… Xamarin est donc gratuit ! Et c’est une excellente nouvelle. Car sans ça, les étudiants, les amateurs, les petit auto-entrepreneur comme moi voir même quelques TPE aurait bien eu du mal à se lancer sur cette techno. Microsoft rachète donc Xamarin et l’offre dans toutes ses éditions Visual Studio 2015 (community, pro et entreprise). Par contre le reste des offres de Xamarin, à savoir les cours via l’university Xamarin et son centre de test restent payant. Je comprends que Xamarin doit trouver son modèle économique, mais maintenant que Microsoft est derrière, j’espère que les cours seront gratuit. D’autant plus qu’ils font des efforts fou pour que les développeurs codent pour Microsoft. Donc pourquoi faire payer des cours sur une technos qui permettrait d’universaliser nos apps, dont celle sur WUP. Bref, l’academy de Microsoft est gratuite, j’imagine qu’a terme on aura des cours Xamarin dessus aussi. Autre bonne nouvelle, c’est l’arrivé depuis qq jours du simulateur iOS sur Windows. Oui oui, j’ai bien dit un simulateur iOS sur Windows. Il est inclu dans la version stable de Xamarin depuis début juin 2016. Je l’ai testé en version alpha puis stable depuis un mois. Et ca marche plutôt bien ! 1) Situation J’ai donc testé Xamarin iOS. J’ai une application (Trackus) que je développe depuis maintenant 2 ans sur divers plateformes (Windows Phone, Android, Web App, WUP), mais il me manquait iOS. Comment faire ? – Choix 1 : natif (Objective C ou Swift). Je préfère en générale cette approche. Coder en natif permet d’apprendre pas mal de chose, d’avoir des ressources (docs, communauté, billet Stackoverflow…). Mais ici je n’avais même pas le matériel. Et chez Apple ça coute un bras. De plus il faut tout réapprendre. Je bosse sur Windows depuis toujours. Et le mac… je connais pas ou mal. Je galère pour faire des trucs tout simple. Mon temps d’apprentissage va devoir impacter en plus l’OS et les outils de l’OS. Ca fait beaucoup pour un noob. – Choix 2 : Hybride (Cordova, Ionic). Pourquoi pas. J’ai passé un mois à me former sur AngularJS, Ionic aurait été un choix. Mais mon application nécessite de tourner en background, utilise des maps et le GPS… J’ai des doutes sur la fiabilité de tout cela en hybride. Peut être ai-je tort. Cela pourrait être un sujet prochain. Je n’ai pas vraiment étudier la question à fond. – Choix 3 : Xamarin iOS. C’est mon choix. Plus par curiosité qu’autre chose. Je suis les divers évolutions de Xamarin et le ressenti des développeurs. Cette techno est prometteuse. Mais dans les faits ? – Choix 4 : Xamarin Forms : autre solution, non étudié. Je voulais d’abord me rapprocher du natif et aborder éventuellement Xamarin Forms plus tard. Pour info, mon application (http://trackus.reactor.fr) propose de géo-localiser un utilisateur A et de permettre à un utilisateur B de le suivre sur une carte. J’utilise pour cela un code alphanumérique sur 6 chiffres qui va identifier un parcours. L’utilisateur A envoi ce code à l’utilisateur B qui peut alors suivre sa trace. Ce code est modifiable ce qui permet de garder un certain anonymat. J’ai donc un serveur qui permet d’échanger ces informations (Web API2 + Entity-Framework). Voici les apps déjà en prod (bêta): Web App : http://trackus.reactor.fr/pages/observer.html?code=AAAAAA Windows Phone (Silverlight) : https://www.microsoft.com/fr-fr/store/apps/trackus/9nblgggxzpg7 Windows 10 : https://www.microsoft.com/fr-fr/store/apps/trackus-10/9nblggh5xq6q Android : https://play.google.com/store/apps/details?id=fr.reactor.trackus Je trouve le sujet intéressant car il aborde d’autre sujet que la classique “liste de tâches” ou le flux RSS qu’on affiche en liste. Ici on a du GPS (droits utilisateurs), du offline/online à gérer (perte de réseau pendant un déplacement, stockage des données, gestion http REST), une tâche en background (cycle de vie) et la manipulation de maps (iOS, Google, Bing). Bref ya du boulot mine de rien. 2) à fond les ballons On y va on code. Ha oui, mais attends, d’abord le matériel… Peux importe ce que vous faites, si vous créez une app pour iOS il vous faudra un mac. Si vous êtes un peu short, il existe des solutions comme MacInTheCloud qui vous permet de louer un mac sur internet. Mais vous ne pourrez faire que du simulateur car impossible de brancher un device physique sur la machine. Sinon vous achetez un mac. Un mac mini fera l’affaire. J’ai acheté le mien sur le bon coin. Une pure affaire. Ca part comme des petits pains, donc sauter sur l’occasion. Vous avez donc un poste Windows, un poste Mac, branché sur le même réseau. C’est parti. Faut tout installer. Yen a pour un moment si comme moi vous tourner max à 2 Mbps (oui ca existe encore !). Il faut installer Xamarin sur le mac et installer Visual Studio 2015 update 2 + le kit simulateur. Tout est dis sur le site de Xamarin : https://developer.xamarin.com/guides/ios/getting_started/installation/ https://developer.xamarin.com/guides/cross-platform/windows/ios-simulator/ Quand tout est installé il faudra créer un projet iOS et tester la connexion avec le Mac (agent de build) Il faut que votre icone  soit verte. Sans ça pas de connexion avec le mac, donc pas de build ni de simulateur. Dans l’ensemble le setup se fait pas trop mal. Xamarin améliore grandement la simplicité car avant il fallait gérer l’agent de build à la main (voir précédent post sur le sujet). 3) Les mains dans le cambouis J’ai travaillé essentiellement sur Visual Studio avec le simulateur. Ce dernier propose pas mal de petites options intéressantes. Il y a même un simulateur de déplacement (à pied, en vélo et en voiture) ce qui permet de tester le GPS. Idéale dans mon cas. Il manque cependant un bouton pour couper le réseau ou un “dégradateur de réception 3G/4G” histoire de tester…

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…

MangoPay – Une API de gestion de paiement sur internet.

MangoPay est une solution de gestion de paiement sur internet, l’équivalent de son homologue US Paypal mais, cocorico, cette solution est Française. Enfin presque, car la société est basée à Luxembourg… En même temps pour une « pseudo » banque, cela reste logique. En effet MangoPay est une banque qui n’en est pas une. C’est plutôt un intermédiaire qui facilite les paiements et s’assure (avec les vraies banques) que les paiements soient effectués. En anglais on appelle cela un « Escrow » (sans déconner !). Un opérateur tiers.    Donc un « Escrow » ne se traduit pas par « escroc » (escrow vient du vieux français escroue, qui signifiait « bout de parchemin ») mais plutôt par « dépôt », « compte bloqué ». Il faut le voir comme un intermédiaire entre les clients de votre site e-commerce et les banques de ces clients. MangoPay permet à de jeune startup de créer un porte-monnaie virtuel en marque blanche. Bien évidement une commission est prélevée (1.8% + 0.18€ –> détail)   MangoPay se veut être une plateforme de paiement en ligne pour les Marketplaces, les plateformes collaboratives et les sites de crowdfunding. Bien évidement les workflows ne sont pas les mêmes suivant ces cas. En ce qui me concerne, je vais m’intérresser aux modèles des sites e-commerces. Ma problématique est de mettre en relation client et acheteur, tout en garantissant que l’acte d’achat se déroule proprement. Ceci implique de gérer le suivis des livraisons et des retours, voir même les échanges physiques réel.   Pour cela je vais utiliser l’API de MangoPay. Comme je vais devoir manipuler de l’argent, des cartes de crédits, des porte-monnaies, MangoPay met en place deux environnements, la production classique et le mode sandbox. C’est sur ce dernier que je vais tester mon application. En plus d’être « fictif » il permet de tester des cartes bancaires factice et donc d’ajouter de l’argent sur les portes-monnaies virtuels de mes utilisateurs, en ne déboursant pas un rond !   Mises en place de l’API – Inscription   https://docs.mangopay.com   Vous devez créer deux comptes, un pour la prod (pour plus tard, quand vous serez prêt) et un pour la sandbox. Je vous conseil de faire les deux tout de suite, comme ça c’est fait, et vous allez conserver ses informations dans votre coffre-fort.    Rendez vous sur cette page https://docs.mangopay.com/api-references/start-in-production/ pour l’inscription en prod, et sur cette page https://docs.mangopay.com/api-references/sandbox-credentials/ pour l’inscription en mode sandbox.   On vous demandera de créer un clientId, de donner le nom de votre société et un email (choisir aussi la monnaie Euro). L’important c’est d’avoir un email valide (pro de préférence) et un clientId que vous allez utiliser par la suite dans l’API. Vous allez ensuite valider votre inscription et recevoir un mot de passe (passphrase). NOTEZ ces informations et conservez les !   Ça y est, vous avez créé vos accès à l’API, maintenant passons à la doc.   Les bases de l’API :   Bien sur il faut se référer avant tout à la doc online. Plutôt bien faite, du moins il y a bcp d’info, mais pas forcément affiché dans le bon ordre selon moi. Ce n’est que mon avis, mais je vous propose de regarder ces pages dans cet ordre (cas e-commerce) :   https://docs.mangopay.com/marketplace-workflow/ (workflow pour les sites e-commerce) https://docs.mangopay.com/api-references/ (vous donne l’ensemble des requêtes possible) https://docs.mangopay.com/mangopay-dashboard/ (accès au dashboard)   Et arrêtez-vous la pour l’instant. Créez vous un accès sur le dashboard Sandbox et familiarisez vous avec quelques minutes. Il est vide à ce stade donc pas grand chose à voir.    L’important ici est de comprendre à quoi sert MangoPay et ce que vous voulez en faire. Ou trouvez l’information, les ressources et savoir utiliser les outils disponibles (dashboard).    Le code C#   L’Api fonctionne avec l’architecture REST. Les avantages : simple, sans état : indépendance client-serveur, pas de session, représentation compréhensible sous forme d’URI. Les inconvénients : le client doit conserver certaines données, augmentation du nombre de requêtes.    Une des pages de la doc conseille de commencer par créer un utilisateur (user), puis de lui associer un porte-monnaie (wallet). C’est ce que je vais vous montrer, mais en créant plutôt deux utilisateurs : John et Julie.    Tout d’abord, vous devez télécharger le SDK de votre langage de programmation préféré. Le SDK MangoPay est disponible sur GitHub en PHP, Python, Ruby, Java, .Net et JavaScript. Je vais continuer l’article en m’appuyant sur le SDK .net, mais sachez les noms des méthodes sont les mêmes dans toutes les versions (attention, j’ai pas tout vérifié), et parfois avec les mêmes fautes d’orthographe ! (ceci ma permit d’en conclure qu’effectivement le code est fortement similaire)     https://github.com/MangoPay   Note: j’ai commencé par utiliser la version compilé du package SDK .net dans une solution WebForm Asp.net. J’ai eu des soucis lors de l’exécution sur les libs Common.Logging.Core.dll et Common.Logging.dll. J’ai pas compris pourquoi alors j’ai téléchargé le code source de MangoPay.SDK et j’ai ajouté/créé un projet web directement dans leur solution. Ça compile et ça s’exécute correctement. Mais mieux, dans la solution fournit par le SDK on a un projet de Test, c’est une mine d’or pour comprendre comment fonctionne l’API. Je vous conseille fortement d’aller y faire un tour. J’ai autant appris avec les tests qu’avec la doc sur internet.    Il faut pour cela instancier l’API et lui passer les paramètres suivant :   MangoPayApi api = new MangoPayApi (); api.Config.ClientId = « myClientId » ; api.Config.ClientPassword = « XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX » ;   L’objet ‘api’ dispose d’une autre propriété importante : api.Config.BaseUrl. Par défaut c’est l’url de la SandBox. Donc si vous ne la spécifiez pas, vous serez par défaut sur le serveur de test.    Pour créer un utilisateur, voici les quelques lignes de code :   UserNaturalPostDTO user = new UserNaturalPostDTO (« john.doe@sample.org » , « John » , « Doe » , new DateTime (1975, 12, 21, 0, 0, 0), CountryIso.FR, CountryIso .FR); user.Occupation = « programmer » ; user.IncomeRange = 3; user.Address = « Some Address » ;   UserNaturalDTO john = api.Users.Create(user);   Remarque : MangoPay distingue deux types d’utlisateur, les UserNatural et les UserLegal. Pour faire simple, UserNatural est un utilisateur lambda, le client de base et UserLegal une personne morale, représentant une société. Ceci m’amène à vous parler du KYC Concept de MangoPay. KYC signifie « Know Your Customer », « Connais ton client ». Bon tout ça découle certainement de directive Européenne et est en lien étroit avec la lutte contre la fraude, le blanchiment d’argent et le financement du terrorisme (rien contre l’évasion fiscale ? étonnant…) Du coup MangoPay distingue…