Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe


Poster un commentaire

Les Azure App Service Plan?

Une Web Apps est structurée autour de deux choses:

  1. Un App Service Plan
  2. Un service Azure

 

Le service Azure est l’instance de notre web app, c’est facile à comprendre. Mais alors à quoi sert un App Service Plan?

C’est le thème que j’aborde dans cet article.

Lire la suite

Publicités


Poster un commentaire

MSI: une solution moderne pour accéder au Vault Azure

L’article précédent fut l’occasion de voir le service Key Vault en œuvre. Vous vous souvenez que l’authentification s’effectuait grâce à des credentials déployés dans les fichiers de configuration.

Ce qui est paradoxal, car Azure Key Vault est justement supposé servir à protéger ses données sensibles. On se retrouve là face à un classique problème de logistique du dernier kilomètre.

Le certificat résout (partiellement) le problème car la solution repose sur un élément déployé localement en dehors de l’application. Mais ce n’est clairement pas une solution complète. On veut que TOUT soit transparent pour l’appli et ne rien déployer de sensible sur le poste utilisateur.

 

C’est ici qu’intervient MSI (Managed Service Identity) qui va résoudre se problème et libérer le code et la configuration de toute référence explicite à des credentials. Nous gardons le vault, mais ajoutons MSI pour sécuriser l’authentification.

Vault + MSI est un pattern vers lequel Microsoft commence à pousser, il est donc important de le connaître si vous faîtes du dev sous Azure.

 

Voyez cet article comme la suite du précédent que je conseille de relire, ne serait-ce que pour être iso avec la configuration.

 

Dans ce premier exemple nous nous limiterons à son intégration dans le cadre d’une Web Apps. J’aborde le cas des solutions IAAS dans l’article qui suivra.

Lire la suite


Poster un commentaire

Les modules JavaScript: utilisation pratique

J’ai discuté les différentes architectures de module rencontrées en JavaScript dans un précédent article:

https://amethyste16.wordpress.com/2017/06/24/les-architectures-de-modules-en-javascript/

 

OK, maintenant j’ai créé une série de modules. Comment je les intègre de façon concrète dans un vrai projet?

Il y a je pense 3 options:

  1. Les chargeurs de module
  2. Les constructeurs de bundle
  3. Chargement via des <script>

La première installe dans le site lui-même un chargeur de module, comme par exemple RequireJS, qui s’occupera de charger le module et l’ensemble de ses dépendances.

La deuxième vise à rassembler dans un même fichier le module et l’ensemble de ses dépendances dans l’ordre qui convient. On créée un nouveau fichier, appelons le bundle.js, qui est le résultat de la « bundlelisation ». On n’a alors plus besoin de référencer de chargeurs de module, il suffit de référencer bundle.js directement.

La dernière est la méthode traditionnelle si je puis dire. On a N fichiers *.js à charger, on écrit N déclarations <script> et on gère à la main le bon ordre. C’est très simple, très utilisé, mais peut devenir vite laborieux.

Surtout cette méthode encourage guère à écrire des modules propres, c’est à dire avec une empreinte minimale sur le scope global. Laissons de côté cette méthode qui ne concerne en rien cet article.

Lire la suite


Poster un commentaire

Les architectures de modules en JavaScript

Les bonnes pratiques modernes de codage en JavaScript poussent de plus en plus vers la structuration du code en modules. En général on débute avec les modules est via certains patterns comme Revealling Pattern Module (RPM), mais il est important de connaître d’autres architectures plus performantes.

Les 4 plus fréquentes sont les suivants:

  1. Revealling Pattern module (UMD)
  2. CommonJS
  3. AMD
  4. Modules ES6

 

RPM est pour l’essentiel l’exploitation des capacités de closure proposées par les fonctions Javascript tandis que les modules ES6 sont des extensions du langage… mais des extensions assez récentes donc pas toujours supportées. On les trouvent mises en œuvre dans TypeScript par exemple.

 

CommonJS et AMD c’est différent, il s’agit de spécifications. Pour les mettre en œuvre on doit utiliser un framework capable de gérer des modules au format CommonJS ou AMD. Différents chargeur de script existent à cet effet, mais certains sont plus typiques que d’autres.

CommonJS est étroitement lié à NodeJS par exemple, tandis que vous profiterez des joies de AMD avec RequireJS ou Angular 1. Mais cela ne se traduit pas par des barrières pour autant. Un chargeur de scripts est après tout lui-même un module.

Par ailleurs, les chargeurs de scripts sont souvent capables de prendre en charge plusieurs formats.

 

Mais pourquoi plusieurs définitions de modules?

C’est une question de choix personnel et les besoins ne sont pas forcément les même d’ailleurs. Les différents formats de modules ne correspondent pas à des bonnes pratiques ou des patterns en tant que tels. Il s’agit simplement d’implémentations différentes de l’idée de module.

Par exemple CommonJS charge les dépendances de façon synchrone ce qui n’est pas une option favorable dans un contexte Web où l’on préfèrera AMD ou ES6. ES6 n’est pas supporté par tous les navigateurs par contre.

 

Je propose de présenter une démonstration complète de ces 3 architectures dans cet article. Au menu:

  • Préparation de l’environnement de test
    Projet de test
    Serveur web
  • CommonJS
    Démo Node
    Démo Web avec SystemJS
  • AMD
    Démo Node avec RequireJS
    Démo Web
  • ES6

Lire la suite


Poster un commentaire

Patterns pour haute dispo et scalabilité d’une appli web – Partie VI

Utilisation des caches

Le cache est sans doute l’outil le mieux connu des développeurs et certainement le plus répandu. Il faut dire que l’efficacité est très grande et la mise en œuvre vraiment très simple. Il existe très peu de sites web qui se passent de cache et dans ce cas c’est probablement une erreur.

Mais avant de se lancer il y a tout de même un petit fond culturel utile à connaître:

  • Définition d’un cache
  • Mécanismes fondamentaux
  • Pattern cache-aside
  • Cache local, cache distribué
  • Création de cache maison
  • Redis
  • Accélérateur web
  • Quelques mauvaises pratiques

Lire la suite


Poster un commentaire

Patterns pour haute dispo et scalabilité d’une appli web – Partie V

Gérer les pannes matérielles

Le chapitre précédent nous a appris quelques stratégies adaptées au cas de pannes transitoires, c’est à dire qui vont se résoudre d’elles-même.

Mais il peut arriver que le problème soit plus sérieux ou en tout cas prenne beaucoup de temps à se résoudre, des heures plutôt que des minutes. Les stratégies de réitération, même avec un disjoncteur, n’est peut être pas la solution la plus adaptée.

 

Peut t’on protéger mieux l’application contre ce problème?

Je vais aborder deux solutions possibles:

  1. la redondance matérielle
  2. Le découplage des modules
  3. Usages d’une queue

Lire la suite


Poster un commentaire

Patterns pour haute dispo et scalabilité d’une appli web – Partie IV

Maîtriser les pannes transitoires

Les applications modernes sont construites à partir d’un certain nombre de briques, de modules, plus ou moins indépendants et en interaction permanente.

La question que je vais aborder est celle de savoir ce qui se passe si un de ces modules a une défaillance. La défaillance peut venir du module lui-même ou bien de sa connectivité. Savoir ce qui se passe, mais surtout quelles stratégies peut t’on mettre en place pour limiter les impacts pour votre client en souplesse et si possible de façon transparente.

Les points abordés dans cet article:

  • Erreurs transitoires ou permanentes
  • Pattern de réitération (transient fault handling pattern)
  • Pattern du disjoncteur (circuit breaker pattern)
  • Mise en œuvre pratique
  • Considérations pratiques

Lire la suite