Architecture of real-time web applications

Question

This is going to be a rather theoretical question. I'm currently working on my bachelor thesis, which includes the creation of a web-based real-time object synchronization framework much like Firebase , but local (ie not cloud based).
I need to distinguish "regular" web applications (is there a better term?) from real-time, especially in terms of architecture. My thoughts so far:

• a regular web application is based on the Client-Server model, ie "Clients and servers exchange messages in a request-response messaging pattern: The client sends a request, and the server returns a response."
• a real-time web application maintains a persistent connection between the client and the server. Both can send and receive messages simultaneously and independently from each other over that connection (full-duplex).
• my advisor (from the chair of applied software engineering) states the above point already qualifies the application for a Peer-to-Peer architecture, though he's not quite sure. I'm not yet convinced since a) the peers are not homogeneous, b) the server is still a centralized system, c) we still use the terms "server" and "client".
• the server doesn't send messages directly to specific clients, but uses the publish-subscribe messaging pattern, ie a client connects to a message channel and receives a message when the server publishes it in the respective channel. Hence the server doesn't actually know about its clients, though he could know.
• the main use case is as follows: a client sends a message to the server (eg when a new todo item was created), the server processes it (eg writes the new todo item to the database) and finally dispatches the message to all other subscribed clients. The mediator pattern came to my mind, though it's a behavioral pattern, not an architectural one.
• but there's another use case: the server sends a message of its own accord (eg it recognizes the expiry date of a todo item exceeded and deletes it) to subscribed clients. So the communication doesn't always have to start at the client.

Sorry, it got longer than intended. To put it in a nutshell, I see three possibilities for the architecture of a web-based real-time application:

1. Peer-to-Peer (with heterogeneous peers)
2. Client-Server with pub-sub messaging pattern and mediator (if the latter matters for architecture)
3. you surprise me with something totally different ;-)

Not sure if it's of importance at all, but I use Rails (with a JMS -based messaging service that provides WebSocket -support) on the backend and AngularJS on the frontend.

Answer 1

"Real-time" actions or applications or systems have timeliness and predictability constraints.

In principle, that is independent of the system architecture--in practice, the architecture must be suitable for the real-time properties you need.

A publish/subscribe mechanism has a real-time metric based on the latency from when a publishable event occurs until the event is manifest at all operational subscribers--simplified, real-time = real fast (think automated financial trading). But real-time is as much about timeliness predictability. In the P/S case, the predictability of interest is the latency--both in magnitude and in variability ("jitter" is a special case). There is a lot of literature in both the research and practitioner communities--in your case I suggest reading some of the excellent documents on RTI's web site (although IMHO RTI doesn't deal with predictability as thoroughly as they could, but they make good products).

Non-P/S systems, including but not limited to client/server ones, have a different style of real-time. There are multiple time-constrained (say) tasks contending for shared resources (such as a processor, synchronizers, networks, etc.). The contending access requests must be resolved by being either dispatched or scheduled in an order that satisfies both a timeliness and a predictability optimality criterion. Everyone is familiar with the very simple special case that the requests have deadlines and the optimality criterion is to meet all the deadlines. Note that the "meet deadlines" timeliness criterion has been expressed together with the predictability criterion "always meet all."

In the vast majority of real world real-time cases (not limited to computers), the criteria are much more complex--for example, it is common for a real-time system to require that the mean (or, alternatively, maximum) tardiness either be minimized or not exceed some value. Additional complexity is added by dependencies, such as precedence constraints. This style of real-time has major implications on certain properties of the architecture and its system software. All of the above has been greatly simplified for brevity.

Answer 2

I can read your question in one of the following ways:

a) Which of Peer-to-Peer, Client-Server, or some other term describes the application best?

b) Which architecture should the application use as the basis of its design?

In my opinion your question describes the application's architecture quite well, and it's quite irrelevant whether you want to call it Peer-to-Peer or Client-Server or something else.

That said, the real-time aspects of the design don't make it Peer-to-Peer for the very reasons you mention.