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

Meteor Raises $20M

techcrunch.com

Post reply on HN
Print view View original

51–60 of 163 posts

Re: Meteor Raises $20M

#51

Post by wmf »

nichochar wrote: post #44

I like meteor, I think it's a good framework, that solves well the "Make a webapp with non critical data but where real time is critical" problem. I've also used angular, which I also like, but has a little bit more of a learning curve drawback. I do unfortunately believe that a project or framework should make it not because it's CEO or leader is good at selling something, pitching VC's, and creating a brand, I thin…

It's way too late for that anyway. AFAIK DerbyJS was better than Meteor all along but no one has heard of it.

Re: Meteor Raises $20M

#52

Post by primigenus »

murbard2 wrote: post #18

I'm actually looking into meteor at the moment, and the financial backing is a big plus, as it gives me some guarantee that the project will keep being maintained for the foreseeable future. It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it. For intance, when is it ever OK to let your client write directly in the…

> For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?

If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation", where changes users make are instantly reflected in the UI and synced to the server in the background. This is a central feature of Meteor. More here: https://www.meteor.com/full-stack-db-drivers and in this Youtube video: https://www.youtube.com/watch?v=tqLbodVH3dw

> It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.

It's actually very easy to go from prototype to production; you just remove some convenience packages (autopublish and insecure), set up your security rules, do some basic performance tuning (eg. don't publish entire documents if you only need 3 fields, which is a standard practice for any app) and that's about it. Of course the definition of "production" varies per project, but after shipping over 20 Meteor apps since 2012 these are the most common things I tend to do.

> Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?

You can express most of these in code. Yes, in relational databases you can express constraints in the database. But then you're having a NoSQL vs SQL debate, which is sort of out of scope of this discussion.

Re: Meteor Raises $20M

#53

Post by joeyyang »

imslavko wrote: post #43
juliangregorian wrote: post #30

Earlier quoted context omitted.

I'm apprehensive of the security model. Everything is highly ease-of-use optimized, to the point that you can query Mongo via the browser console. My preferred "easy/simple" model of app design is Firebase (backend and JS lib for pure web clients), who have security figured out.

Meteor's security model allows app developer to validate any operation or RPC going through, based on the arguments or userId (by writing JS code). Also, the published set is controlled by publications, allowing to publish only filtered out data with specific fields. Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, befo…

Hey there, I'm Joey, a Firebase dev — last November, we shipped advanced querying support[0] to address this! You can now use orderByChild(), orderByKey() or orderByPriority() to build a query.

We also have limitToFirst(), limitToLast(), startAt(), endAt(), and equalTo() methods to further filter your data.

This allows you to build queries like this:

  ref.orderByChild("weight").limitToLast(2).on("child_added", function(snapshot) {
    console.log(snapshot.key());
  });
Please check out our querying docs[1], and let us know if you have any questions!

[0] https://www.firebase.com/blog/2014-11-04-firebase-realtime-q...

[1] https://www.firebase.com/docs/web/api/query/

Re: Meteor Raises $20M

#54

Post by akhatri_aus »

wmf wrote: post #51
nichochar wrote: post #44

I like meteor, I think it's a good framework, that solves well the "Make a webapp with non critical data but where real time is critical" problem. I've also used angular, which I also like, but has a little bit more of a learning curve drawback. I do unfortunately believe that a project or framework should make it not because it's CEO or leader is good at selling something, pitching VC's, and creating a brand, I thin…

It's way too late for that anyway. AFAIK DerbyJS was better than Meteor all along but no one has heard of it.

I've heard of it and have used both and disagree.

Keep in mind both are open source projects. The community has been immensely successful filling up Meteor's gaps.

Re: Meteor Raises $20M

#55

Post by murbard2 »

primigenus wrote: post #52
murbard2 wrote: post #18

I'm actually looking into meteor at the moment, and the financial backing is a big plus, as it gives me some guarantee that the project will keep being maintained for the foreseeable future. It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it. For intance, when is it ever OK to let your client write directly in the…

> For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing? If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation",…

Sure you remove the autopublish package, but then your app stops working. You need to explicitely publish what you want published, you need to explicitely check and validate every input from the client... and that's fine, but then what exactly have you gained from using meteor over, say, socket.io or autobahn? Fast prototyping, yes, you've definitely gained that, but have you gained anything else? I'm genuinely asking, not making a rhetorical point.

Since meteor integrates very tightly with mongodb, a nosql database, I don't see how the limitations of nosql are out of the scope of the discussion? I also don't know what you mean by "you express most of these in code". The problem isn't writing a piece of code that expresses that constraint... the problem is doing so without introducing a race condition!

Re: Meteor Raises $20M

#56

Post by murbard2 »

sergiotapia wrote: post #26
murbard2 wrote: post #18

I'm actually looking into meteor at the moment, and the financial backing is a big plus, as it gives me some guarantee that the project will keep being maintained for the foreseeable future. It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it. For intance, when is it ever OK to let your client write directly in the…

Do yourself a favor and set aside a weekend to go through this book: https://www.discovermeteor.com/ All of your questions are answered there.

It's not cheap and I can't even find a table of content for it. I've also read excerpts that dealt with autopublish etc, and they didn't really address the point I'm making.

Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.

Re: Meteor Raises $20M

#57

Post by djmashko2 »

murbard2 wrote: post #18

I'm actually looking into meteor at the moment, and the financial backing is a big plus, as it gives me some guarantee that the project will keep being maintained for the foreseeable future. It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it. For intance, when is it ever OK to let your client write directly in the…

Here's step 10 of the tutorial, which demonstrates how you can write custom RPCs to handle writing data in Meteor: https://www.meteor.com/try/10

You don't have to use the client-side insert/update/remove syntax if you don't want to. Unless you add an 'allow' call to let some of them through, they will all be automatically rejected by the server.

(I work at Meteor)

Re: Meteor Raises $20M

#58

Post by danenania »

Beginner question: how does Meteor handle storing server-side web socket connections in a scalable way? Are they kept in ram? Redis? Mongo's ram?

The complexity of this is why I always end up reaching for hosted WS solutions like pusher or fanout.io.

Re: Meteor Raises $20M

#59

Post by smaili »

Not trying to sound like a jerk, but I'm just wondering is it really a good thing to put on your homepage that there are nearly 12K questions posted on StackOverflow about Meteor? Seeing a number like that makes me wonder if maybe the documentation and or APIs are not very well done if it's generated that kind of activity on SO.
Post reply on HN