Architecture micro-services

Bonjour,

Comme je vous disais dans l’article sur Hateoas, je vais maintenant vous parler de l’architecture micro-services. Nous verrons les points communs et les différences avec les autres types d’architecture.

Les points communs

L’architecture micro-service se base sur MVC (pour Model View Controller ou en français : Modèle Vue Contrôleur).
Sur ce point, pas de révolution, votre application aura toujours une partie pour l’accès aux données (Modèle), une partie qui sera le point d’entrée de votre application (Contrôleur) et la partie pages web (Vue).

Comme toute architecture, elle n’est pas liée à un langage particulier mais représente une façon de faire applicable à tout type de langage (sauf exception).

Les différences

Première différence, le contrôleur n’est pas un contrôleur web standard mais le plus souvent un contrôleur REST (basé sur les webservices de type REST).
Ca permet de renvoyer des pages html entières ou directement des flux json à la vue.

Deuxième différence, et la plus importante à mon avis, la responsabilité des contrôleurs.
Chaque contrôleur doit avoir une et une seule responsabilité. C’est-à-dire, gérer un seul type d’objet que ce soit pour la création, modification, affichage ou suppression. Et chaque fonction du contrôleur ne doit faire qu’une seule chose (l’ajout par exemple).

Si lorsque vous ajoutez un nouveau produit, vous souhaitez avoir la liste mise à jour, vous devrez faire deux appels au serveur. Le premier appel permettra l’ajout du nouveau produit et lorsque le retour est « Création OK », alors vous faites le deuxième appel au serveur qui lui servira à renvoyer la liste de tous les produits.
Si vous avez lu l’article précédent sur Hateoas, vous voyez l’intérêt de coupler ces deux notions. Ainsi le niveau de maturité 3 que représente Hateoas vous permettra de communiquer plus en détail avec le serveur et ainsi pouvoir découper vos actions de façon minimaliste.

Souvent avec les micro-services, les gens ne savent pas bien découper le travail et mélange les différentes actions dans une même fonction d’un même contrôleur. L’inconvénient est que la maintenance et les évolutions seront plus chères car plus compliquées.
En découpant de façon minimaliste la responsabilité d’une fonction (ce qu’elle doit faire), vous diminuez sa complexité et donc le cout de sa maintenance.
Imaginons que vous avez une fonction qui renvoie tous les produits et les sous-catégories, car vous n’avez pas respecté les micro-services. Maintenant il faut que vous ne renvoyez plus les sous-catégories car le client ne les veux plus dans cette page. Vous devez modifier plusieurs parties de votre fonction, ce qui augmente le risque de régression et d’impacts sur d’autres pages.
Dans le cas des micro-services, vous n’avez juste qu’à supprimer l’appel aux sous-catégories dans le javascript. Le risque de régression étant quasiment nul et la complexité pareil (sauf si votre JS est mal codé 🙂 ).

Troisième point, votre architecture coté serveur ressemble à vos urls.
C’est-à-dire que si vous avez store/product/ dans votre url, vos packages cotés serveurs auront la même architecture.
Cette logique est identique coté javascript si vous utilisez un framework du type angular.
L’avantage est que même sans connaitre l’architecture du projet, vous pouvez vous y retrouver facilement coté serveur si on vous a donné l’url de la page à modifier ou inversement si vous savez où est le contrôleur.

Voilà, c’était une petite présentation sur l’architecture micro-services, qui j’espère vous donnera l’envie d’en savoir plus et pourquoi pas de la mettre en place sur vos nouveaux projets (modifier l’architecture d’un projet déjà existant est souvent long, compliqué et couteux).

Likes(0)Dislikes(0)

Hateoas

Bonjour,

Aujourd’hui, je veux vous parler du niveau de maturité de maturité de communication de webservices rest : hateoas.
Cet article fera volontairement des raccourcis et sera vulgarisé.

Tout d’abord, il faut faire un petit résumé rapide sur les webservices.

Les webservices

L’objectif d’un webservice est de permettre la communication entre deux machines sans qu’elles ne sachent quel langage de programmation chacune utilise.
Par exemple, un serveur java peut communiquer avec un serveur php sans que ça pose de problème. Le serveur qui met à disposition le webservice va dire ce qu’il attend en entrée comme format (XML pour la norme SOAP par exemple), les informations qui devront être obligatoirement renseignées, celles qui sont facultatives, etc. En sortie, il renverra un fichier, qui lui aussi qui sera normé.

Il existe deux normes de webservice : SOAP (basé sur les fichiers XML) et REST (basé sur le protocole HTTP).
L’avantage du REST est qu’il peut directement appelé par un navigateur web.

Les développeurs se sont dit : « hé, si on peut appeler les webservices REST depuis un navigateur, il y a moyen de développer une application web qui serait basé que sur des webservices REST. Et non plus des controleurs web d’un coté et webservices de l’autre. »
Et oui, avant on devait faire un controleur web qui renvoyait, par exemple, une page d’affichage de données et si un serveur distant devait également avoir accès à ces mêmes données, on devait faire un webservice qui lui renvoyait. Maintenant, on peut faire un seul et même point d’entrée : le webservice REST qui pourra renvoyer les données aussi bien au navigateur qu’à un autre serveur.

Oui, mais on doit pouvoir donner des informations sur les échanges entre les machines.
Si mon navigateur envoie des données qui ne sont pas attendues par le webservice, ce dernier doit pouvoir lui dire qu’il y a eu un problème.

C’est là qu’intervient les différents niveaux de maturité des webservices.

Les maturités des API webservices

Niveau 0

Dans ce niveau, le plus bas, tout se passe en POST (signifie normalement qu’on envoie des données au serveur) sur une même url et le serveur répondra toujours 200 (code pour OK), que la requête se soit bien passée ou non.

Le problème est que pour afficher des données, le POST ne sert à rien; et le code 200 renvoyé, quelque soit le vrai état de la requête coté serveur, n’est pas satisfaisant car ça peut cacher une erreur.

Niveau 1

Avec ce niveau, on appelle toujours le serveur en POST, mais là on va enrichir l’url en lui disant par exemple quel objet on cherche à avoir.
Ex, si on veut récupérer l’utilisateur 42, l’url sera du type :
www.monsupersite.fr/user/42
Si on cherche à avoir le produit 12, l’url sera du type :
www.monsupersite.fr/product/12
Si on veut avoir tous les utilisateurs, l’url sera du type :
www.monsupersite.fr/users

Ainsi, on voit que l’url commence à « dessiner » ce qu’on fait réellement sur le site.

Niveau 2

Là, en plus d’avoir des url différentes suivant ce qu’on fait, on demande au serveur des données d’affichage avec le mot GET, l’ajout d’un nouvel élément avec le code PUT, la modification avec POST et la suppression avec DELETE.
Le serveur en retour répondra avec un code différencié du style : 201 pour dire que la création s’est bien passée, 404 pour dire que la ressource n’a pas été trouvée, etc.

Niveau 3 : hateoas

L’objectif de ce niveau est d’en plus d’avoir un échange verbeux entre les machines (niveau 2, pour rappel), permet aussi d’envoyer des liens vers d’autres webservices liés à l’action qu’on vient de faire.
Par exemple, si on veut récupérer les informations d’un utilisateur, on fera :
Appel en GET vers l’url : www.monsupersite.fr/user/42
Le serveur renvoie 200 et en plus des liens vers le webservice qui liste les produits achetés par ce même utilisateur.
Le retour est du style :

[
{
"user" : {
"id" : 42,
"name" : "toto",
"email" : "toto@monsupersite.fr",
"links" : [
{
"rel" : "self",
"href" : "http://www.monsupersite.fr/user/42"
}
],
"products" : {
"links" : [
{
"rel" : "self",
"href" : "http://www.monsupersite.fr/user/42/products"
}
]
}
}
}
]

Ainsi, en plus d’avoir les informations liées à l’utilisateur directement, nous avons aussi le lien vers le webservice qui permettra de récupérer les produits achetés par ce même utilisateur.

Il peut bien sur avoir plus d’une sous partie dans le résultat renvoyé par le serveur.

Comme il s’agit d’un degré de maturité proposé par une personne, Leonard Richardson, il ne s’agit pas d’un standard. Donc chacun peut faire ce qu’il veut.
A mon sens, l’intérêt de Hateoas est d’autant plus important si on l’utilise dans le cadre d’une application basée sur l’architecture microservices (qui sera expliqué dans le prochain article).

Les promises en javascript

Aujourd’hui, il s’agit d’un article un peu plus technique, car je vais vous parler des promises (promesses en français) en javascript.

L’objectif n’est pas de faits un tuto sur le sujet mais plus de vous faire les découvrir. Il existe plein de très bons tutos sur le sujet sur le web.

Les promises, qu’est-ce que s’est ?

Il s’agit d’une nouveauté EMACScript 6, dernière norme javascript, ce qui signifie que pour IE vous pouvez oublier. 😊

L’intérêt des promises d’avoir, entre autre, un état fait et un échec. Vous lancez des appels ajax et vous pouvez dire dans votre code d’exécuter tel code en cas de retour de vos appels. Ca permet d’avoir des appels asynchrones mais de pouvoir facilement traiter leurs retours.
Votre code gagne ainsi en lisibilité mais aussi en efficacité.

Si vous souhaitez l’utiliser mais avec des navigateurs plus vieux, il existe la libraire Q qui permet la rétrocompatibilité (d’après ce que j’ai pu tester) mais aussi un tableau de promises. Ainsi lorsque toutes vos promises sont revenus, vous pouvez lancer le code voulu.

En résumé, si vous faites une nouvelle application web, je vous conseille de vous intéresser aux promises avant de commencer à code, ainsi qu’à la librairie Q. Ça devrait fortement vous faciliter la vie.

Likes(0)Dislikes(0)

Customiser une balise select

Mise à jour du 15/01/2014 à 16h49 : Evitez d’utiliser une image comme background pour le select car Chrome ne l’affiche pas contrairement à la couleur.

Article initiale : Bonjour à tous,

Je me suis pris la tête pour arriver à customiser un select. Je me suis dis que ça pourrait vous intéresser, aussi je vous partage mes trouvailles.

Pour ceux qui ne connaissent pas le select c’est ça : .
Par défaut, un select n’est pas super sexy. Et ce n’est pas très facile de le modifier.

Voyons ensemble comme le rendre un peu plus sympa.

Code HTML


<!DOCTYPE HTML>
<head>
<meta name="charset" content="UTF-8"/>
<link rel="stylesheet" type="text/css" href="urlDuFichier/nomDuFichierCSS.css" title="style1"/>
</head>
<body>
<form action="urlDuTraitementDesDonnes" method="POST">
<select id="monSelect" name="monSelect">
<option value="1">Oui</option>
<option value="0">Non</option>
</select>
</form>
<body>

Là rien de bien exceptionnel, c’est une page web basique.

Partie CSS

Coté CSS, on va customiser le select ainsi (on le met dans « nomDuFichierCSS » qu’on a mis dans la balise link rel du head coté html):

select{
background : #DAEAF9;
border : 1px solid black;
border-radius : 5px;
padding : 3px;
}

On met une image de fond pour le select ou une couleur, c’est l’utilité du background. Si vous mettez une image, mettez aussi une couleur en fin de la ligne au cas où. En général, je vous conseille la couleur à l’image. Ensuite, on met un bord d’un pixel d’épaisse, continu et noir. C’est l’utilité du border. Le border-radius, lui sert à arrondir les coins du select.
Le padding nous permet d’avoir un petit espace intérieur de 3pixel.

Voila ce que ça donne :

Notre select est un peu plus joli, mais ce bleu n’est pas du meilleur effet. On peut le surcharger, en partie, grâce au css suivant.

option:hover{
background : img('UlrDeLimageDeFond.jpg') #CouleurRGB;
}

Ce qui nous donne :
select
La souris était sur le Oui quand j’ai fait l’imprim écran (moins chiant que de modifier les styles WordPress 🙂 ).
select2
Cet imprim écran a été fait quand la souris n’était plus sur un option.

Donc quand la souris est sur un option, on n’a plus le fond bleu, mais si on met la souris ailleurs, il revient.

Voilà comment modifier un select, sans pour autant passer par des div ou des ul li couplés à du js voir du jquery. L’avantage de cette méthode est que le select reste facilement utilisable sur mobile, contrairement à beaucoup d’autres méthodes.
J’espère que ça pourra en aider certains d’entre vous.
Pour information, cette solution ne fonctionne pas sous IE7.

Likes(0)Dislikes(0)

Bonnes pratiques de développement : 1er partie – les sessions

Bonjour à tous,

Aujourd’hui, je fais un petit article sur le développement, et plus particulièrement l’utilisation des sessions.
Je pense que pour beaucoup d’entre vous qui font du développement c’est une notion bien connu, mais ça ne fait pas de mal de faire une piqûre de rappel.

La session : quézako ?

La session est une période de temps durant laquelle le client est connecté de façon unique sur un serveur.
Pour cela, très souvent, nous (les développeurs) mettons des informations liées au client dans la session du serveur afin de pouvoir savoir qui réalise l’opération.
Exemple en php :
$idUser = $_SESSION['idUser'];
Dans l’exemple ci-dessus, on récupère l’identifiant unique de l’utilisateur présent en session

Les sessions sont indispensables dans tout site actuel. Cependant, ça devient vite fourre tout.

La bonne utilisation des sessions

La session ne doit en principe stocker que les informations qui servent partout sur le site. Habituellement, il s’agit du numéro d’identifiant de l’utilisateur de la base de données. En effet, ce nombre permet de savoir qui est la personne, puisqu’il est unique (un peu comme votre numéro de sécurité sociale).
Si un site affiche sur toutes ses pages le nom de la personne, alors il peut être intéressant de le mettre en session aussi afin de ne pas faire des requêtes en base à chaque chargement de pages. Encore qu’il existe d’autres solutions que la session dans ce cas (la mise en cache par exemple).

Le problème est que très souvent des développeurs inexpérimentés se servent de la session comme un fourre tout.

    Quelques exemples véridiques de session fourre tout :

  • la liste de résultat d’une recherche mise en session. Pas les critères de la recherche, mais bien la liste de résultats. o_O
  • la liste des communes des départements
  • des formulaires entiers
  • etc
  • Les impacts d’une mauvaise utilisation

    Cette partie va plus porter sur le fonctionnement java, mais reste vrai en général.
    Le problème de mettre tout et n’importe quoi en session, c’est qu’elle est stockée en mémoire vive et reste rempli tant que l’utilisateur est connecté. S’il se déconnecte, la session se vide, mais s’il ne le fait pas (ferme son navigateur par exemple), la session reste en mémoire tant que le time out du serveur n’est pas arrivé (très souvent c’est 30min).
    Si vous n’avez qu’un utilisateur sur votre site, mettre tout en session n’est pas un problème, votre serveur tiendra la charge. Mais maintenant imaginez un site comme chronodrive. S’ils utilisent à tort la session, le serveur tombera très rapidement.
    J’ai déjà vu sur certains projets sur lesquels j’intervenais, des serveurs qui tombaient à cause de la trop grosse utilisation de la mémoire par le processus java dû à une mauvaise gestion de la session.

    Les remèdes

    Si vous en êtes au début de votre développement, préférez les requetes en base ou l’utilisation du cache pour les informations non essentielles.
    Il vaut mieux avoir une base de données bien pensée, avec des requêtes optimisées, qu’une session qui récupère la moitié de la BDD à cause des temps d’accès.

    Si vous avez déjà développé votre site et que ce dernier ne tient pas la charge, vous avez deux solutions : la première vous essayez de mettre en place un cache et vous allégez la session. La deuxième, vous n’avez qu’à tout recoder. j’exagère un peu mais j’ai déjà eu affaire à des projets où ça a été la seule solution. En effet, la session était une vrai poubelle et la BDD n’était pas optimisée. Aussi dès qu’il y avait 10 utilisateurs en simultanés sur le site, ce dernier s’effondrait.

    Pour conclure, la session est un outil très pratique, mais elle ne doit servir qu’à stocké des informations indispensables au bon fonctionnement du site. Quand ça dépasse une dizaine de variable (et encore, là je suis très généreux) c’est qu’il y a un problème dans votre site et que vous devriez le repenser (revoir son architecture, la BDD, etc).

    Likes(0)Dislikes(0)