Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.
Brouillon
Cette page n'est pas terminée.
Les flux de données internes et externes représentent le coeur de toute application web. A mesure qu'il évolue, ces flux de données deviennent de plus en plus complexes. Les maitriser vous aidera à construire des applications web plus efficaces.
Flux HTTP basique
Depuis l'origine, le web est basé sur une architecture client/serveur reposant sur le protocole HTTP.
Le schéma ci-dessus montre un flux basique de site web. Chaque ressource est hébergée sur le serveur et le client (le navigateur web) les requête via HTTP chaque fois qu'il en a besoin. Dans cette configuration, le navigateur web est uniquement chargé d'afficher le contenu web. Toutes les données et leurs traitements sont gérés par le serveur.
Ne soyez pas dupe de l'apparente simplicité de cette architecture. Elle est toujours valide et est utilisée par nombre de sites web encore aujourd'hui. Il existe un gros travail théorique sur le sujet, connu sous le nom d'architecture REST. Cette architecture précise comment les ressources doivent être accédées et manipulées à travers le protocole HTTP. Même si REST est indépendant d'HTTP, sa connaissance est très utile pour construire des services et accès ressources robustes à l'usage d'applications utilisant HTTP.
L'un des inconvénients de cette approche simple est qu'à chaque fois qu'un utilisateur veut voir une page web, tous ses éléments doivent être requêtés, même ceux qui ne changent pas d'une page à l'autre. Ceci amène des effets visuels indésirés tels que des latences d'affichage, FOUC, etc. Pour empêcher autant que possible ces inconforts, les navigateurs web gèrent un cache des ressources qui évitent les requêtes réseau inutiles. Mais même avec le cache les navigateurs vont complètement ré-afficher la page, ce qui va prendre un temps qui sera malheureusement perçu par l'utilisateur.
Flux de données avancé
A la fin des années 90, Microsoft a trouvé un contournement technique à cette nécessité de requêter les ressources de manière répétée. Cette solution est connue sous le nom d'AJAX et est basée sur un nouvel objet JavaScript appelé XMLHttpRequest.
Le principal changement introduit par cette technologie porte sur où et quand les requêtes HTTP sont manipulées. Avec cette technologie, les requêtes HTTP peuvent être manipulées directement par une page web plutôt que par un mécanisme sous-jacent du navigateur tel qu'un lien hypertexte. Grâce à ce changement, la page web a l'opportunité de requêter des ressources de manière asynchrone à chaque fois qu'elle en a besoin et seulement si elle en a besoin. Au début cela a été pensé pour requêter des fragments HTML ou XML pour mettre à jour une portion d'une page web. Aujourd'hui c'est utilisé pour requêter des données (généralement, mais pas nécessairement, au format JSON) nécessaires à la mise à jour du contenu d'une page. Si c'est un peu différent d'un point de vue technique, ça ne change rien d'un point de vue architectural.
Aujourd'hui les plus gros sites web utilisent très largement cette technique, mais il est important de comprendre quand c'est une bonne idée, et quand ça n'est pas nécessaire.
Flux de données d'appli web
Récemment, un ensemble de nouvelles technologies a fait son apparition dans les navigateurs web: IndexedDB, AppCache et offline events. La première n'est rien moins qu'une base de données embarquée dans le navigateur, permettant de stocker et manipuler des données sans requêter un serveur. La deuxième est un nouveau mécanisme de cache qui permet de cacher des données indéfiniment. Une fois qu'une ressource est cachée par ce mécanisme, le navigateur ne demandera jamais plus cette ressource. La dernière est une API permettant de savoir si le navigateur est connecté au réseau.
Ces trois technologies changement pas mal de choses. Grâce à elles, la connexion à un serveur n'est plus un pré-requis à l'utilisation d'un site web. C'est pour cette raison que de tels sites web sont appelés applications web. A partir de là, tout le cycle de vie d'une application peut être géré dans le navigateur. Cependant le serveur est toujours utile, mais uniquement pour deux choses :
- Une première connexion est requise pour "installer" ou "mettre à jour" l'application (cache des ressources, mise en place du schéma de données, etc.)
- Le serveur peut être utilisé comme copie de sauvegarde des données de l'application en cas de problème sur la machine locale, ou pour les utilisateurs qui utilisent plusieurs navigateurs ou machines pour accéder à l'application.
Beyond HTTP
How other technologies fit into our data flow architecture, including Web sockets, WebRTC (but this is advanced stuff: defer detailed discussions to the advanced network communication section).
Go deeper
We need to write separate follow on articles covering the following:
- HTTP basics, and how this can help you be a better master of your data. For this part it may be a good idea to take a look at what HTTP information is currently available on MDN and refresh/reshape/update/reorganize that content
- Ajax basics (architecture, technique)
- Data storage systems and Ajax
- Intro to handling offline AJAX and timeouts
- Handling data within the browser (persistant or temporary; technique with cookies vs. storage vs. IndexedDB vs. data attributes). For offline stuff, defer to the Offline section
- Advanced Ajax topics, such as UI interaction and perceived performance.
- Links to other useful demos and resources