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

[AlisdairO]

I dunno - you've presumably got to implement code to make sure that other servers get unlocked when your locking app server goes down, for example. Personally I try to avoid implementing ad-hoc distributed systems if I can avoid it. Having to shard is pretty damn crappy, but under the circumstances I'd favour it.

Further, I tend to think that if your application is heavy enough to outgrow a reasonably fat db server with (say) 500+GB of RAM, strategies like reimplementing consistent-db-esque locking in an app server + zookeeper setup are also likely to hit some pretty weird performance issues.