7 ms·

There is a lot opinions on HNews that Meteor is too monolithic and it's bad: https://news.ycombinator.com/item?id=8772563 https://news.ycombinator.com/item?id=8

There is a lot opinions on HNews that Meteor is too monolithic and it's bad: https://news.ycombinator.com/item?id=8772563 https://news.ycombinator.com/item?id=8772563 However, that kind of projects show the opposite. It is in fact very modular.

evo_9 12y ago
The fact that so many dismissed it without giving it a serious look made me interested in seeing what it was really about. Long/short - it's an amazingly focused, fun and easy stack to work with. I think the fact that it's easy, or at least seems easy and probably because it's another javascript framework makes it an easy target to dismiss on HN. If you are coming from a web background like myself (aspx, ruby, etc) then it's quite a revelation how fast, fun and easy it is to work with.
- tracker1 12y ago
  I think that Meteor is pretty awesome, but it isn't good for a lot of use cases out of the box... If you need really granular and flexible security around your models, the out of the box security isn't (or wasn't last I checked) good enough. Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all documents owned by users in GROUP_A. This is a pretty typical scenario for management chain permissions, but when I've looked ad Meteor and similar solutions it wasn't an option (or incredibly difficult to implement).
  - primigenus 12y ago
    At a high level, what you're describing is pretty straightforward to implement. You just publish the data a user has access to read, and you use allow/deny rules to determine which they can write to. You should take a look at the Roles package: https://github.com/alanning/meteor-roles https://github.com/alanning/meteor-roles I recommend taking another look at Meteor's security because although it's different to other platforms, different doesn't mean inferior. It's actually very powerful and simple once you get the hang of it.
    - tracker1 12y ago
      Cool... as I admitted it's been a long while since I've looked at implementations... last I looked, if you opened your Meteor server to the (html/web) client, the client could do nasty things to your backend database, or you had to implement some complicated and/or not very flexible permissions... I'm glad to see that this has changed.
  - lourd 12y ago
    This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents) Meteor gives you an accounts collection so you don't have to declare it yourself. But we do need to declare the Groups Collection Groups = new Mongo.Collection('groups'); Let's assume we want Users and Groups to have a many to many relation, so each User doc has an attribute `groups`. `groups` is an array of which each element is the unique id of a Group document. Similarly, Group documents have an attribute `members`, an array of which each element is a User document unique id. There is a third Collection needed, documents. Documents = new Mongo.Collection('documents'); Each document in the Documents Collection has an `owner` field that is the unique id of a Group document. To handle the security for inserting or updating the Documents Collection, you need to set 2 allow rules on the Collection to check if the document.owner is in the user.groups array. Documents.allow({ insert: function(userId, doc) { // doc's owner must be one of logged in user's groups return Meteor.user().groups.indexOf(doc.owner) > -1; }, update: function(userId, doc, field, modifier) { return Meteor.user().groups.indexOf(doc.owner) > -1; } } As for reading the document, you do that when declaring your Publications. Easiest would be to publish all of them, but you could also pass in a groupId or array of groupIds if you wanted to have some restrictions. Meteor.publish("documents", function() { return Documents.find(); };
    - uptownJimmy 12y ago
      I am not a hater, quite the contrary. I've messed around with Meteor just a bit, and loved it. But I cannot get my head around one thing: why in the world would anyone actually choose to use MongoDB over Postgres or MySQL ?Is there actually a use case where a NoSQL db would be as good or preferable? Or is it really all just a matter of people being intimidated by SQL? Because everything informed and trustworthy that I read on the subject says that NoSQL is simply not robust enough for doing anything more complicated than storing a list of names and email addresses for a simple user forum. That ain't gonna cut it for most apps.
      - achipa 12y ago
lostinpoetics 12y ago
Agreed. I think a lot of that is based on Meteor (understandably) pushing their entire stack. I've always been intrigued by their docs which state: By default all apps include the meteor-platform package. This automatically pulls in the packages that make up the core Meteor stack. If you want to build your own custom stack, just remove meteor-platform from your app and add back in whichever of the standard packages you want to keep.[0] Granted, I've always used the full stack but I'd be interested in seeing some examples of taking a more modular approach at a lower level than adding packages on top of the core stack. [0] http://docs.meteor.com/#/full/usingpackages http://docs.meteor.com/#/full/usingpackages
- achipa 12y ago
  True - even for DDP there are already a number of client libraries not strictly related to Meteor front-ends, as seen from http://meteorpedia.com/read/DDP_Clients http://meteorpedia.com/read/DDP_Clients
  - sordina 12y ago
    I just wrote the Haskell DDP client last week :)

evo_9 12y ago

The fact that so many dismissed it without giving it a serious look made me interested in seeing what it was really about. Long/short - it's an amazingly focused, fun and easy stack to work with. I think the fact that it's easy, or at least seems easy and probably because it's another javascript framework makes it an easy target to dismiss on HN. If you are coming from a web background like myself (aspx, ruby, etc) then it's quite a revelation how fast, fun and easy it is to work with.

tracker1 12y ago
I think that Meteor is pretty awesome, but it isn't good for a lot of use cases out of the box... If you need really granular and flexible security around your models, the out of the box security isn't (or wasn't last I checked) good enough. Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all documents owned by users in GROUP_A. This is a pretty typical scenario for management chain permissions, but when I've looked ad Meteor and similar solutions it wasn't an option (or incredibly difficult to implement).
- primigenus 12y ago
  At a high level, what you're describing is pretty straightforward to implement. You just publish the data a user has access to read, and you use allow/deny rules to determine which they can write to. You should take a look at the Roles package: https://github.com/alanning/meteor-roles https://github.com/alanning/meteor-roles I recommend taking another look at Meteor's security because although it's different to other platforms, different doesn't mean inferior. It's actually very powerful and simple once you get the hang of it.
  - tracker1 12y ago
    Cool... as I admitted it's been a long while since I've looked at implementations... last I looked, if you opened your Meteor server to the (html/web) client, the client could do nasty things to your backend database, or you had to implement some complicated and/or not very flexible permissions... I'm glad to see that this has changed.
- lourd 12y ago
  This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents) Meteor gives you an accounts collection so you don't have to declare it yourself. But we do need to declare the Groups Collection Groups = new Mongo.Collection('groups'); Let's assume we want Users and Groups to have a many to many relation, so each User doc has an attribute `groups`. `groups` is an array of which each element is the unique id of a Group document. Similarly, Group documents have an attribute `members`, an array of which each element is a User document unique id. There is a third Collection needed, documents. Documents = new Mongo.Collection('documents'); Each document in the Documents Collection has an `owner` field that is the unique id of a Group document. To handle the security for inserting or updating the Documents Collection, you need to set 2 allow rules on the Collection to check if the document.owner is in the user.groups array. Documents.allow({ insert: function(userId, doc) { // doc's owner must be one of logged in user's groups return Meteor.user().groups.indexOf(doc.owner) > -1; }, update: function(userId, doc, field, modifier) { return Meteor.user().groups.indexOf(doc.owner) > -1; } } As for reading the document, you do that when declaring your Publications. Easiest would be to publish all of them, but you could also pass in a groupId or array of groupIds if you wanted to have some restrictions. Meteor.publish("documents", function() { return Documents.find(); };
  - uptownJimmy 12y ago
    I am not a hater, quite the contrary. I've messed around with Meteor just a bit, and loved it. But I cannot get my head around one thing: why in the world would anyone actually choose to use MongoDB over Postgres or MySQL ?Is there actually a use case where a NoSQL db would be as good or preferable? Or is it really all just a matter of people being intimidated by SQL? Because everything informed and trustworthy that I read on the subject says that NoSQL is simply not robust enough for doing anything more complicated than storing a list of names and email addresses for a simple user forum. That ain't gonna cut it for most apps.
    - achipa 12y ago

lostinpoetics 12y ago

Agreed. I think a lot of that is based on Meteor (understandably) pushing their entire stack. I've always been intrigued by their docs which state: By default all apps include the meteor-platform package. This automatically pulls in the packages that make up the core Meteor stack. If you want to build your own custom stack, just remove meteor-platform from your app and add back in whichever of the standard packages you want to keep.[0] Granted, I've always used the full stack but I'd be interested in seeing some examples of taking a more modular approach at a lower level than adding packages on top of the core stack. [0] http://docs.meteor.com/#/full/usingpackages http://docs.meteor.com/#/full/usingpackages

achipa 12y ago
True - even for DDP there are already a number of client libraries not strictly related to Meteor front-ends, as seen from http://meteorpedia.com/read/DDP_Clients http://meteorpedia.com/read/DDP_Clients
- sordina 12y ago
  I just wrote the Haskell DDP client last week :)