• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Meteor in Action: How does synchronization of the data between client and server happen?

 
Ranch Hand
Posts: 254
1
MySQL Database Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
On reading a bit about Meteor I couldn't understand how Meteor helps sending only the needed data and no HTML to the client. How does it do this?

I have another question as well. Is Meteor the only framework that handles coding all the layers including the server-side within itself?

 
author
Posts: 18
7
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all it is helpful to understand that Meteor itself is a variant of the MEAN stack. It takes Node.js and MongoDB and builds on top of them. The advantage is that you have the same language (JavaScript) on the client (browser), server (Node.js), and database (MongoDB). This is a common pattern we see a lot these days - like with the traditional MEAN stack that also uses Express.js (server) and Angular.js (client). The difference between a vanilla MEAN stack and Meteor is that MEAN needs you to deal with lots of different APIs while Meteor adds a layer of abstraction on top of it therefore simplifying a lot of the required ground-work. Technically it is possible to swap out most parts of a Meteor stack, but the power comes from the pre-packaged combination.

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).

Fur further reading I suggest the first (free) chapter of Meteor in Action, especially section 1.2 and figure 1.7.

Meteor is probably not the only technology that allows you to code all layers with the same set of APIs, others like Derby.js come to mind. I assume we will see a lot more of these types of platforms or frameworks because it makes developers' lives a lot easier.
 
Ahsan Bagwan
Ranch Hand
Posts: 254
1
MySQL Database Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh my... so many misconceptions addressed in a single post. I believe I have the big picture after all. Thanks a lot Stephan.
 
Video Author
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).


This is a great explanation. Thanks.
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).
 
Stephan Hochhaus
author
Posts: 18
7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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).



I'd argue that this is quite efficient. You leverage the processing power of all clients to do tasks that previously the server had to do. That way it is much easier to scale out. I completely agree that it is bad shipping out nearly 1MB of code just for a simple site, but once we are talking about actual applications, some images are worse than that. So the inefficiency of sending data over the network is - at least in my opinion - out weighed in application contexts by leveraging distributed computing power that puts less stress on the servers.

Security remains a huge concern, but beware not to fall in the security-by-obscurity pit. Meteor still enforces security policies on the server. It may give you the code to manipulate data, but the actual security layer sits on top of the data. Now when you are Google you probably do not want to send out the code that includes algorithms to document how to determine Page Rank, but in those cases you do not have to send out the entire application to the client.

API keys, secret algorithms, authorization models - these can all be kept on the server still.

Also about JavaScript being slow, this is both still accurate and outdated- It's not the fastest language and parsing huge DOM trees is far from efficient (there it is again), but a lot is compensated by scaling server tasks out to clients. If you look at requests over the net, processing times are considerably fast. If there is less data to be sent over the wire (no HTML markup for example) this again compensates for possible slowness on the client. But after all, thanks to Google Chrome and Safari and their battle for quicker JavaScript benchmarks the game has changed significantly in the last 20 months alone.
 
Sheriff
Posts: 67749
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Having worked in the browsers for the past 17 years, I can attest that in comparison to just a few years ago, the JavaScript engines in modern browsers absolutely scream!
 
There is no "i" in denial. Tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic