Stephan Hochhaus wrote:Now to explain how data is exchanged we need to take into account that Meteor consists of various pieces, most importantly a standard protocol named DDP that allows bi-directional communication between server and client via WebSockets (SockJS) and a pub/sub approach that keeps track of both subscriptions and data changes (Livequery).
The first request to a Meteor app is to get the application to the browser via HTTP. Once all resources are transferred server and client only communicate via WebSockets. Since inside the browser an application is running it can turn raw data into HTML easily.
The client app subscribes to certain data collections and the Livequery component constantly monitors changes to the data source as well as keeps track of all subscribed clients. It pro-actively pushed changes out to all connected and currently subscribed clients over the DDP connection (WebSockets).
Thom Parkin wrote:
But, being "an old-timer" I can't help but think how terrible inefficient this is.
First, the ENTIRE application must be downloaded to the client on the initial request. Am I wrong about that?
And, of course, you do not want ALL the [for lack of a better term] "back-end" data on the client (security is one very BIG reason that comes to mind) so there is no real savings; you are not eliminating trips to the server. Are they minimized by such a great extent it makes a difference?
I remember the days of LiveScript and cannot quite shake the idea that Javascript belongs only on the client and it is very slow (I know this is an outdated and incorrect assumption).
Those who dance are thought mad by those who hear not the music. This tiny ad plays the bagpipes:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|