5 ms·

> 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

> 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 https://www.meteor.com/full-stack-db-drivers and in this Youtube video: https://www.youtube.com/watch?v=tqLbodVH3dw 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 11y ago
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!
- aliakhtar 11y ago
  > 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 11y ago
    > 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 11y ago
      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 11y ago
        I guess, but that's some monumental hackery to overcome something that works perfectly fine in an RDBMS :-)
        aliakhtar 11y ago
        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.

murbard2 11y ago

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!

aliakhtar 11y ago
> 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 11y ago
  > 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 11y ago
    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 11y ago
      I guess, but that's some monumental hackery to overcome something that works perfectly fine in an RDBMS :-)
      - aliakhtar 11y ago
        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.