Flux et données

Probablement une des choses qui change le plus quand on passe d’une architecture dite d’ « entreprise » à l’architecture d’un pure player du web, c’est l’orientation nette vers une logique de flux.

Un architecte d’entreprise vous présentera son architecture en commençant par les grands blocs applicatifs puis continuera par le système d’échange et d’intégration des données entre les différents systèmes applicatifs.

A l’inverse, l’architecte d’un pure player présentera son architecture dans la perspective d’un flux : de la collecte des données à leur mode de persistance en passant par les divers traitements. On a tout de suite le sentiment d’avoir l’orchestration temporelle d’une suite d’événements.

Dans un cas on met l’accès sur les données comme ressources applicatives, dans l’autre on met l’accent sur le flux des données. Là où la première conception est plutôt spatiale et statique, la deuxième est plutôt temporelle et dynamique.

De l’intégration des données

Je vous invite à aller lire le billet complet de Christian et le premier commentaire de Gautier. Il y est question de dualité entre des données stockées dans des bases distribuées et un système de log globalisé. Là où ça devient intéressant, c’est lorsque l’on rapproche ces réflexions de ce qu’a fait Facebook avec Flux :

Flux is the application architecture that Facebook uses for building client-side web applications. It complements React’s composable view components by utilizing a unidirectional data flow. It’s more of a pattern rather than a formal framework, and you can start using Flux immediately without a lot of new code.

Il n’y a plus d’opposition entre statique et dynamique mais une unidirectionnalité du flux de dynamisation du statique. (Ça c’est pour Damien :p.) La problématique ne se pose plus en termes de stockage et de transfert mais en terme d’évolutivité des données. Ainsi on s’abstrait de la nécessité d’un log global en ayant des flux indépendants et isolés, le stockage peut être distribué c’est le dispatcher qui va s’assurer de la cohérence de la modification des données. On se retrouve avec une approche hybride qui est à la fois spatiale et temporelle. L’intégration et le croisement des données est — si l’on fait abstraction des problèmes de performances — plus politique que technique (cf. OpenData et citoyenneté ou OpenData et évaluation), il ne faut pas concentrer les données dans un même log mais réunir les acteurs dans une même pièce ;-).

Je suis extrêmement surpris que les vieux concepts réutilisés dans Flux n’aient pas donné lieux à une prolifération de nouveaux frameworks web. Je suis presque sûr que l’on peut combiner cette approche à asyncio