[primigenus]

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

[murbard2]

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!

[dsyko]

To answer your first question, there are a number of attractive advantages to using Meteor over say socket.io or autobahn on top of Node. One major one would be a consistent API for accessing your data on the Client and Server. I would argue that using Javascript on both backend and frontend with Node boosts a developer's productivity by reducing language/context switching. In the same vein accessing data using the Mongo query api on both backend and front end with Meteor's MiniMongo improves development. Also Meteor comes with built-in latency compensation when using either RPCs (with stubs on the client) or Minimongo operations. Latency compensation is a non-trivial problem which would need to be implemented by the developer when using something like socket.io. You also gain access to a growing list of great packages that implement things like user accounts which you would otherwise need to write yourself or wire together from various projects.

As for your second question. There are certainty use cases where MongoDB isn't appropriate, and support for other databases is on Meteor's roadmap. For now there are some community created packages for interfacing directly with SQL databases in place of MongoDB, but there are a number of issues with them. You could also pipe data in and out of an SQL database inside RPCs, however the data would not be updated in 'real-time' to clients. I anticipate SQL databases will get some good support options in time.

[aliakhtar]

> 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!

I agree, and this also exposes a weakness of javascript as a backend language. If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times. Which makes this problem solvable even with a NoSQL database. Javascript is single threaded though, which makes this problem a lot harder and I don't know how you'd solve it without an RDBMS with transactional support.

[AlisdairO]

> If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times.

That does cause you to have a hard limit of one application server for the app, which can be a pretty big deal...

[aliakhtar]

No, you could have multiple servers talking to each other via something like ZooKeeper. But individually, each node/server would use multithreading to keep track of its state.

[AlisdairO]

I guess, but that's some monumental hackery to overcome something that works perfectly fine in an RDBMS :-)

[aliakhtar]

Until the time comes when you need to scale out your RDBMS and need to shard it. IMO that's a bigger pain ;).

Plus if you have multiple servers, they will most likely need to pass messages for other things too.