This page is not complete.
A 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 show a simple 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 an is used by many web site as of today. There is a big theoretical work made on it known as the REST architecture. This architecture state how resources should be access 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 want 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 lead to some undesired visual effects such as display latencies, FOUC, and so one. To avoid as much pain as possible, web browsers handle a cache of the resources to, at least, avoid unnecessary network requests. But event with that, they will fully rerender the page, and sadly, this operation can take time and be noticed by the user.
Advance web site data flow
The main change introduce 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 build-in browser mechanism such as hyperlinks. Thanks to that change, the web page as 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 any thing 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
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