Databases
StackOverflow2013
Postsdbo
POArchitecture of real-time web applications
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POArchitecture of real-time web applications
    primarykey
    data
    text
    <p>This is going to be a rather theoretical question. I'm currently working on my bachelor thesis, which includes the creation of a <a href="http://en.wikipedia.org/wiki/Real-time_web" rel="nofollow">web-based real-time</a> object synchronization framework much like <a href="https://www.firebase.com" rel="nofollow">Firebase</a>, but local (i.e. not cloud based).<br> I need to distinguish "regular" web applications (is there a better term?) from real-time, especially in terms of architecture. My thoughts so far:</p> <ul> <li>a regular web application is based on the Client-Server model, i.e. "Clients and servers exchange messages in a request-response messaging pattern: The client sends a request, and the server returns a response."</li> <li>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).</li> <li>my advisor (from the chair of applied software engineering) states the above point already qualifies the application for a <a href="http://en.wikipedia.org/wiki/Peer-to-peer" rel="nofollow">Peer-to-Peer</a> 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".</li> <li>the server doesn't send messages directly to specific clients, but uses the <a href="http://en.wikipedia.org/wiki/Publish-subscribe" rel="nofollow">publish-subscribe</a> messaging pattern, i.e. 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 <em>could</em> know.</li> <li>the main use case is as follows: a client sends a message to the server (e.g. when a new todo item was created), the server processes it (e.g. writes the new todo item to the database) and finally dispatches the message to all other subscribed clients. The <a href="http://en.wikipedia.org/wiki/Mediator_pattern" rel="nofollow">mediator pattern</a> came to my mind, though it's a behavioral pattern, not an architectural one.</li> <li>but there's another use case: the server sends a message of its own accord (e.g. 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.</li> </ul> <p>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:</p> <ol> <li>Peer-to-Peer (with heterogeneous peers)</li> <li>Client-Server with pub-sub messaging pattern and mediator (if the latter matters for architecture)</li> <li>you surprise me with something totally different ;-)</li> </ol> <p>Not sure if it's of importance at all, but I use <a href="http://rubyonrails.org" rel="nofollow">Rails</a> (with a <a href="http://en.wikipedia.org/wiki/Java_Message_Service" rel="nofollow">JMS</a>-based messaging service that provides <a href="http://en.wikipedia.org/wiki/WebSocket" rel="nofollow">WebSocket</a>-support) on the backend and <a href="http://angularjs.org" rel="nofollow">AngularJS</a> on the frontend.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USnubbel
    1. USnubbel
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COThe only principal difference is that the real-time web application operates... in real-time. That eliminates any architecture that doesn't support real-time updating of the client. AFAICT that completely answers the question you've asked.
      singulars
      1. POArchitecture of real-time web applications
      1. USRobert Harvey
    2. CO@RobertHarvey Thanks for your answer. So your point is the architecture doesn't actually matter as long as the the server can update the client in real-time? It could be P2P, Client-Server or whatever?
      singulars
      1. POArchitecture of real-time web applications
      1. USnubbel
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload