title: Flux et données
slug: flux-donnees
date: 2014-11-04
chapo: Il n’y a plus d’opposition entre statique et dynamique mais une unidirectionnalité du flux de dynamisation du statique.

> 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**.
>
> <cite>*[De l’intégration des données](http://www.christian-faure.net/2014/11/02/de-lintegration-des-donnees/)*</cite>

Je vous invite à aller lire le billet complet de [Christian](http://www.christian-faure.net/) et le [premier commentaire](http://www.christian-faure.net/2014/11/02/de-lintegration-des-donnees/#comment-161048) de [Gautier](http://www.lespetitescases.net/). 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](https://facebook.github.io/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](http://www.cynicalturtle.net/kame/) :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é](/david/blog/2013/opendata-citoyennete/) ou [OpenData et évaluation](/david/blog/2014/opendata-evaluation/)), 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](https://docs.python.org/3.4/library/asyncio.html)…