Bonne année 2015
jeudi 1 janvier 2015
jeudi 25 décembre 2014
mercredi 24 décembre 2014
[POC] Oauth
Vous avez tous vu, au moins une fois, sur un site Internet le bouton de “connexion Facebook” ou “connexion Google".
Mais qu’y a-t-il derrière ? Dans la grande majorité des cas, il y a le protocole Oauth en version 1.0a ou en version 2.
Je ne vais pas faire d'explication de texte sur le protocole car d’autres s’en sont chargés pour moi et je les en remercie.
Par contre, je vais vous donner un lien vers deux dépôts GitHub qui contiennent les parties utiles pour la mise en oeuvre du protocole avec Symfony2.
La partie serveur Oauth (facebook/google/etc…) et serveur de ressource : https://github.com/macintoshplus/OauthServerApp
La partie cliente (le site Internet) : https://github.com/macintoshplus/OauthClientApp
Pour la partie cliente, il est possible de faire le même travail (connexion de l'utilisateur et récupération de ses informations) de deux manières différentes :
1) en obtenant du serveur de ressource les informations sur l’utilisateur et ne rien stocker en local. Pour cela j’utilise le package "hwi/oauth-bundle". Il sera nécessaire d’interroger le serveur de ressource pour rafraîchir les données de l’utilisateur connecté.
2) en obtenant du serveur de ressource les informations sur l’utilisateur et les sauvegarder localement. Les informations peuvent donc être utilisées pour relier l’utilisateur à ses données sur votre site. Pour stocker localement les données j’ajoute à "hwi/oauth-bundle" le très populaire "friendsofsymfony/user-bundle".
Quel est votre retour d'expérience Oauth ?
Personnaliser le nom de la table de l'eventstore de Broadway
Dans le cas fort probable où vous devez personnaliser le nom de la table où Broadway stocke les évènements, voici comment redéfinir le service :
YAML :
my_project.event_store.dbal
class: Broadway\EventStore\DBALEventStore
arguments: [@doctrine.dbal.default_connection, @broadway.serializer.payload, @broadway.serializer.metadata, 'mon_event_store']
broadway.event_store:
alias: my_project.event_store.dbal
Vous pouvez également en profiter pour changer la connexion doctrine à la base de données. Attention toutefois, le changement ne s'appliquera pas à la commande d'initialisation de la table. La commande Symfony utilise la connexion "default".
C'était mon astuce du jour. Et vous, en avez-vous une ?
YAML :
my_project.event_store.dbal
class: Broadway\EventStore\DBALEventStore
arguments: [@doctrine.dbal.default_connection, @broadway.serializer.payload, @broadway.serializer.metadata, 'mon_event_store']
broadway.event_store:
alias: my_project.event_store.dbal
Vous pouvez également en profiter pour changer la connexion doctrine à la base de données. Attention toutefois, le changement ne s'appliquera pas à la commande d'initialisation de la table. La commande Symfony utilise la connexion "default".
C'était mon astuce du jour. Et vous, en avez-vous une ?
mardi 23 décembre 2014
4 mois avec Broadway
Voilà maintenant 4 mois que j’utilise au quotidien la librairie Broadway pour la gestion de l’EventStore dans un projet en production.
Il y a maintenant plus d’un million d’agrégats et il en est prévu quasiment 5 millions.
Comment cela réagit-il ?
Le système réagit très bien, même en cas de décalage de version entre l’EventStore et le ReadModele.
MS SQL Serveur encaisse plutôt bien la volumétrie, sachant qu’un agrégat a, au minimum, 10 events au cours de sa vie.
Quelles sont les difficultés rencontrées ?
La principale difficulté est liée à l’une des contraintes du projet qui demande l’usage intensif des scripts pour les traitements. Cela nécessite une gestion poussée des transactions SQL afin de limiter les problèmes d'annulation de transaction. En effet, l'EventStore est stocké en base de données et dispose d'une connexion distincte de celle du ReadModel.
Pour le stockage des Events, une transaction ne contient qu’un seul Event (selon le principe de l’Event sourcing, un Event non enregistré ne peut pas être émis sur le bus) alors que la transaction pour le Read Model est enregistrée à la fin du traitement batch effectué sur l’agrégat.
Dans tous les cas, si votre EventStore et votre ReadModel sont dans la même base de données, je vous conseille d'utiliser deux connexions distincte afin d'éviter des problèmes lors de ROLLBACK.
Une autre difficulté rencontrée est la faible résilience du bus de commande. En effet, si le Command Handler ou l'agrégat émet une Exception, les commandes émises ensuite ne seront pas traitées.
Dans mon cas, une commande est envoyée, son traitement dans le Command Handler lève une exception. Le script principal catch l'exception et émet une commande selon la situation. Cette dernière sera mise en file d'attente mais ne sera pas traitée.
Pour contourner le problème, la commande qui lève une exception doit émettre un Event indiquant l'erreur. Charge au script principal de recharger l'agrégat et de vérifier son état.
Il y a sûrement une meilleure méthode pour gérer plus efficacement ces cas. J'attends vos idées dans les commentaires.
Les points positifs ?
Le gros point positif est le suivi de toutes les modifications de l'agrégat tout au long de sa vie. Pouvoir remonter dans le temps et analyser ce qu'il s'est passé est un point très important. La possibilité d'ajouter des informations sur chaque Event est également un plus. Savoir comment a été modifié l'agrégat (ligne de commande ou interface web) et par qui sont parfois des informations très précieuses.
La possibilité de rejouer les événements passés en environnement de développement ou de test est très appréciable. Quoi de mieux que l'utilisation réelle pour vérifier le bon fonctionnement du système?
Est-il envisageable de l'utiliser dans d'autres projets ?
Oui, en utilisant une version stable de la librairie. Mais l'écoute des nouvelles librairies dans le domaine est important.
Quelques liens sur le sujet :
Inscription à :
Articles (Atom)