This page is not complete.
The core of every web app is its internal and external data flow. As the web evolved, this data flow become more and more complex. Mastering it will help to build better and efficient web apps.
The basic HTTP data flow
From the start, the Web is based on a client/server architecture sustain by the HTTP protocol.
The above schema shows basic web site flow. Each resource is hosted on the server and the client (the web browser) is requesting them through HTTP each time it needs it. In such a configuration, the web browser is only in charge of displaying the web content. All the data and the treatments performed on them are handled by the server.
Don't be fooled by the apparent simplicity of that architecture. It is still valid and is used by many web sites today. There is a big theoretical work available about it, which is known as the REST architecture. This architecture states how resources should be accessed and handled through the HTTP protocol. Even if REST is independent from HTTP, knowing it can be quite helpful to build robust services and resources access over HTTP for an application.
One of the drawback of that simple approach is that each time a user wants to see a web page, all its assets must be requested again, even the ones that are the same from one page to the other. This leads to some undesired visual effects such as display latencies, FOUC, and so on. To avoid as much pain as possible, web browsers handle a cache of the resources to, at least, avoid unnecessary network requests. But even with that they will fully rerender the page, and sadly this operation can take time and be noticed by the user.
Advanced web site data flow
The main change introduced by this technology is where and when HTTP requests are handled. With this technology, the HTTP requests can be handled directly by a web page rather than by the built-in browser mechanism such as hyperlinks. Thanks to that change, the web page takes the opportunity to request resources asynchronously any time it needs them and only if it needs them. At the beginning it was thought to request HTML or XML fragments to update portion of the web page. Today, it's used to request data (usually, but not necessarily, in the JSON format) necessary to update the page content. If it's a bit different in a technical point of view, it does not change anything in an architectural point of view.
Today's biggest web sites use this technique quite extensively but it is important to know when it's a good idea to use it and when it is not necessary.
Web app data flow
Recently, a set of new technolgies start to land in web browsers. It is IndexedDB, AppCache and offline events. The first one is nothing less than a data base directly embedded in the browser. It allows to store and manipulate data localy without any request to a server to do the job. The second one is a new cache mechanism that allows to cache (none data) resources forever. Once a resource is cached through that mechanism, the browser will never request the server for that resource again. The last one is an API to know when the browser is connected to the network or not.
Those three technolgy change many things. Thanks to them, the connection to the server is no longer a preriquistery to use a web site. For that reason, such web sites are called web application. At that point, the whole life cycle of the application can be handled inside the browser. However the server is still useful, but only for two point:
- A first connexion is required to "install" or "update" the application (caching ressources, setup data schema, etc.)
- The server can be used to backup the applications data to prevent any issue on the local machine or for users who use several browsers or computers to access the application.
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).
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