Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meteor hits 1.0

meteor.com

Post reply on HN
Print view View original

221–230 of 250 posts

Re: Meteor hits 1.0

#221

Post by pluma »

AndyKelley wrote: post #127

I see this in example code: if (Meteor.isClient) { I don't get it. Are we shipping server side code to the client?

If you use browserify for your "isomorphic" code (i.e. JS that runs on client and server), you may have situations in which you need to run different code depending on whether the code executes on the client and server (think XMLHttpRequest vs `require('http')`).

In node you do that by extracting the code in a separate module and telling browserify to use the browser-specific module via your package.json.

In Meteor you can just check whether you're running in the client or server at runtime and execute different code accordingly. That's what `Meteor.isClient` is for.

Re: Meteor hits 1.0

#222

Post by pluma »

resca79 wrote: post #200
prottmann wrote: post #198

Earlier quoted context omitted.

I hoped they change meteor and opened it to other databases. The mongodb only option was the reason for us to stop using meteor. Most of our customer projects use "old school" sql and only a few nosql-databases. Waiting for Version 2 ;-)

I'm not really confident about new version the releasing of version 1 was too long. Also I do not see a strong open community that support them like Rails, Django o Node. Of course I wish them to grow in terms of contributors

There is a pretty distinct and active Meteor community, though from the outside it's hard to tell how much of that is just people who are interested in it because of the hype (kinda the problem MongoDB had) vs people who actually use it and know what they are doing.

I wouldn't say the wait for 1.0 is a good indicator of stability or success, though. Node.js is still at 0.x and so is React. AngularJS took a long while to get to 1.x but is now actively working on 2.0.

Many developers are cautious about when they dare calling a product 1.0. Until the idea that "if your code is in production, it's already 1.0" gained some ground, there was barely any code on npm that wasn't stuck in pre-1.0 land.

The real indicator is how much time passes between minor or bugfix releases. Ideally the latter should happen fairly regularly and the former not too often. If Meteor hits 2.0 anytime soon, that could be a worse sign than if it sticks with 1.0.x for "too long".

Re: Meteor hits 1.0

#223

Post by denom »

dandv wrote: post #181
denom wrote: post #163

Earlier quoted context omitted.

This is something that I've wrestled with when working with meteor, how do you execute privileged queries from the client? You can do a 'Meteor.call' to execute code on the server, but there is no way to shield the user from accessing the parameters used in the query. Traditionally, you would use a cookie on the client to authenticate and trigger the 'privileged' query during the http request cycle. As far as I can t…

In the same vein, there's no way to shield the user from accessing the parameters of a REST request. Which incidentally is easier to replay outside the browser than a Meteor.call().

After doing some poking it looks like you can access `this.userId` in the server-side publish and Meteor.methods functions. That's enough to prevent a lot of client-side tampering

Re: Meteor hits 1.0

#224

Post by sbking »

sbking wrote: post #202
findjashua wrote: post #136

Earlier quoted context omitted.

I imagine it's just using localStorage under the hood, and it's selling point is that it exposes the mongo api you'd use for interacting with the db, or is there something else that I missed?

More that it fully simulates the mongo api. When you perform an insert/update on the client, the following will happen: 1. The command will be sent to the server. 2. The command will be performed on the local database, but backing up the original local DB state so that it can be reverted if needed. 3. Immediately, any helper functions used by templates which rely on data from the DB will react to the change in the lo…

Another point to add is Meteor's EJSON, which is a simple spec for defining how any complex, constructed or factory-made JavaScript objects should be serialized to JSON, and then deserialized back into a full JS object with behavior. Objects inserted/retrieved to/from the MongoDB or Session variables are automatically serialized/deserialized if you have made them EJSON compatible (quite easy to do, and built-in for Date and binary objects). By sharing EJSON definitions on the client and server, you have a flexible basis on which you can build an isomorphic model layer to your liking. The constructed model objects you're working with can easily be made identical (truly or superficially, depending on your needs) on both the client and server code.

Re: Meteor hits 1.0

#225

Post by tvararu »

sbking wrote: post #169
bduerst wrote: post #90

Earlier quoted context omitted.

So is it a PaaS like Google App Engine? Is it just an MVC like angular or ember?

No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits t…

Spot-on explanation, wish I could be so coherent when trying to explain Meteor to other people.

Re: Meteor hits 1.0

#226

Post by sbking »

ak39 wrote: post #175
sbking wrote: post #169

Earlier quoted context omitted.

No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits t…

Thanks for this info. Does it have to use Node.js on the server can the client side framework work with any server side JSON service?

You need to be running the Node.js Meteor application. The client relies on DDP rather than REST and right now Meteor is the only server framework using DDP. There is, however, an isomorphic HTTP library which makes it easy to communicate with third party REST APIs on both the client and server. It is also easy to create REST endpoints for your Meteor collections, so that third party services which don't support DDP can communicate with your app.

It is very possible to use other client side frameworks such as Angular or Polymer, rather than just using Meteor's Blaze UI engine. However I find that Blaze's TemplateEdit: Actually, they do seem to have a decoupled version of the Blaze UI that you could use just for your reactive DOM code and hook into a REST API. You just won't get any of the server-dependent features like full-stack automated data synchronization, hot-reload, live CSS injection, or Meteor's build chain. You just get a simple reactive template/helper/events system. http://meteor.github.io/blaze/

Re: Meteor hits 1.0

#227

Post by sbking »

tvararu wrote: post #225
sbking wrote: post #169

Earlier quoted context omitted.

No, it's a full-stack framework, using Node.js on the server and sending down a client app bundle containing all HTML templates and JS. The client and server then communicate exclusively with JSON through a purpose-invented pubsub WebSockets/SockJS protocol they call DDP. The client has a simulated MongoDB database and thus much of the API is isomorphic, so the client will simulate the server's code while it awaits t…

Spot-on explanation, wish I could be so coherent when trying to explain Meteor to other people.

It seems like too much magic until you've been exposed to it a bit. It's actually pretty simple to visualize what's going on under the hood, but it takes a bit to click. Reading the DDP spec and the tracker package definitely helped me grasp the concepts. The new subprojects page is also great at explaining the major Meteor components: https://www.meteor.com/projects

Re: Meteor hits 1.0

#229

Post by sbking »

nojvek wrote: post #93

Congrats Meteor! but I really find it loading a bazillion javascript files a bit of an overkill. Also debugging is a pain in the butt.

In production in bundles and minifies all JS and HTML into one file that is sent to the client. Then all further communication happens with JSON over WebSockets/SockJS. If changes are made to the JS/HTML, the server will send down a new application bundle and hot-reload the app without interrupting the user if you are storing the user's app state in the Session.

The CSS is also bundled in production. When further changes are made to the CSS, the new stylesheet is live-injected into the running apps without reloading the browser.

Post reply on HN