Are there any ways to customize the 3 required directories?
server/ client/ public/
For example, is there a way I can have more than one server directory. say in foo/server, and in packages/mySmartPackage/server (which also bodes the question, can i have my own server/client/public directories in a custom smart package).
Also, is there a way to rename these, or of multiple are allowed, to define other directories that are considered server directories. say i want /server/ and /core/ to both only be server directories.
The use case behind this, is the app I have will be basically separate apps, but will share server side code. primarily the controllers or templates would be different and would each have different public directories. Each would have their own resources (css/js) in the public dir and would have separate upload directories. Though they would share much of the models/backend code and even a database.
Meteor scans for directories with matching names so you can put it in a sub-directory and receive the expected behavior (e.g. create a directory named foo/server and files in there will only be available on the server.
Tom's FAQ has a suggested way to organize files in Meteor apps:
> Are there any ways to customize the 3 required directories?
> server/
> client/
> public/
> For example, is there a way I can have more than one server directory. say in foo/server, and in packages/mySmartPackage/server (which also bodes the question, can i have my own server/client/public directories in a custom smart package).
> Also, is there a way to rename these, or of multiple are allowed, to define other directories that are considered server directories. say i want /server/ and /core/ to both only be server directories.
> The use case behind this, is the app I have will be basically separate apps, but will share server side code. primarily the controllers or templates would be different and would each have different public directories. Each would have their own resources (css/js) in the public dir and would have separate upload directories. Though they would share much of the models/backend code and even a database.
> -- > You received this message because you are subscribed to the Google Groups "meteor-talk" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/meteor-talk/-/b4bxqdxt-HIJ.
> To post to this group, send email to meteor-talk@googlegroups.com.
> To unsubscribe from this group, send email to meteor-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.
Ok yea that helps, But based on his example, would the models/ directory
not be accessible to the client? Wouldnt I want it to be in the server/
directory? Also, based on the fact he gives the feature-* examples, it
seems that I can have more than one server and/or client directory correct?
so:
On Thu, Aug 16, 2012 at 9:45 PM, Iain Shigeoka <i...@shigeoka.com> wrote:
> Meteor scans for directories with matching names so you can put it in a
> sub-directory and receive the expected behavior (e.g. create a directory
> named foo/server and files in there will only be available on the server.
> Tom's FAQ has a suggested way to organize files in Meteor apps:
> On Aug 16, 2012, at 8:09 PM, luckysmack <luckysm...@gmail.com> wrote:
> > Are there any ways to customize the 3 required directories?
> > server/
> > client/
> > public/
> > For example, is there a way I can have more than one server directory.
> say in foo/server, and in packages/mySmartPackage/server (which also bodes
> the question, can i have my own server/client/public directories in a
> custom smart package).
> > Also, is there a way to rename these, or of multiple are allowed, to
> define other directories that are considered server directories. say i want
> /server/ and /core/ to both only be server directories.
> > The use case behind this, is the app I have will be basically separate
> apps, but will share server side code. primarily the controllers or
> templates would be different and would each have different public
> directories. Each would have their own resources (css/js) in the public dir
> and would have separate upload directories. Though they would share much of
> the models/backend code and even a database.
> > --
> > You received this message because you are subscribed to the Google
> Groups "meteor-talk" group.
> > To view this discussion on the web visit
> https://groups.google.com/d/msg/meteor-talk/-/b4bxqdxt-HIJ.
> > To post to this group, send email to meteor-talk@googlegroups.com.
> > To unsubscribe from this group, send email to
> meteor-talk+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/meteor-talk?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "meteor-talk" group.
> To post to this group, send email to meteor-talk@googlegroups.com.
> To unsubscribe from this group, send email to
> meteor-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/meteor-talk?hl=en.
--
-- Shawn McElroy
"Anything worth doing, is worth doing right" — Hunter S. Thompson
On Aug 17, 2012, at 7:30 AM, Shawn McElroy <luckysm...@gmail.com> wrote:
> Ok yea that helps, But based on his example, would the models/ directory not be accessible to the client?
It would be accessible to both client and server. Think of the rules as; meteor walks the directory tree with a sticky "publish mode" that it sets as a flag for each directory (and it's contents) - by default it's in client/server mode - everything it sees is published to both the client and server. If it gets to a directory that is named 'client' or 'server' it goes into the appropriate mode and only sends the files it finds in that directory. All directories below that directory will get the same "stick" mode unless a directory name sets a new mode. The only exception is if it sees a directory named 'lib' - it will include those into the web page ahead of other javascript files it finds ('lib' directories allow you to prioritize some libraries to be loaded before others - you will tend to put core dependencies there like third party libraries or your base javascript files).
> Wouldnt I want it to be in the server/ directory? Also, based on the fact he gives the feature-* examples, it seems that I can have more than one server and/or client directory correct? so:
> where all the server directories would properly only expose code to the server, and client/ to the client? anything outside is both.
Yup, you got it. The files in the following directories in your example will only be available to the client:
foo/client
bar/client
/
The files in the following directories will be only available on the server
foo/server
bar/server
/
You'll find you will write some common javascript (like utility functions and basic data model definitions) that you'll want to include in both the client and the server. Rather than include them in the / directory in this case, it would be better to create another directory to store them. If you don't care when they are loaded, you could name that directory 'common' - if you want it loaded before the other javascript files, you would name it 'lib'. So a good way to organize could be:
Yea it makes sense now. It just so different than what I'm used to. Where
models are where a lot of the core app functionality which, if the end user
could see, could allow them to easily copy your code which you would not
want. But here the model is exposed. But since the focus on meteor is
having a local client db to make the site appear real time, it makes sense
to me. so here in the models I would only have the minimal code needed for
the app to function properly.
Which begs the question, for code I dont want end users to see that I would
normally have in a model, or a controller, where would I put that? For
controllers and what I am used to, the controllers handle all the
communication between model and view. the model validates and returns the
dataset, and the controller, if needed, preps the data to be available in
the view. The way meteor works, I would need that kind of info on both
client and server as well. Which I would probable end up all just putting
into the models here.
So for code I dont want end users to see I would put it in the lib or
server directories. but short of server side validation and maybe some
schema definitions, or server/app configs, I dont see a lot else I would
put in there. I just want to be able to prevent users from being able to
capture code and being able to use it (for proprietary apps, which I would
make at my job). While I love the idea of meteor and how it works, it so
far, seems to me that the vast majority of your application code is visible
to the end user. Granted it is all minified/obfuscated which makes it more
difficult. Just for the apps I make at my job, code security is of high
importance. And for those kinds of apps, meteor may not be as much as a fit
as I need it to be.
On Fri, Aug 17, 2012 at 11:01 AM, Iain Shigeoka <i...@shigeoka.com> wrote:
> On Aug 17, 2012, at 7:30 AM, Shawn McElroy <luckysm...@gmail.com> wrote:
> > Ok yea that helps, But based on his example, would the models/ directory
> not be accessible to the client?
> It would be accessible to both client and server. Think of the rules as;
> meteor walks the directory tree with a sticky "publish mode" that it sets
> as a flag for each directory (and it's contents) - by default it's in
> client/server mode - everything it sees is published to both the client and
> server. If it gets to a directory that is named 'client' or 'server' it
> goes into the appropriate mode and only sends the files it finds in that
> directory. All directories below that directory will get the same "stick"
> mode unless a directory name sets a new mode. The only exception is if it
> sees a directory named 'lib' - it will include those into the web page
> ahead of other javascript files it finds ('lib' directories allow you to
> prioritize some libraries to be loaded before others - you will tend to put
> core dependencies there like third party libraries or your base javascript
> files).
> > Wouldnt I want it to be in the server/ directory? Also, based on the
> fact he gives the feature-* examples, it seems that I can have more than
> one server and/or client directory correct? so:
> > where all the server directories would properly only expose code to the
> server, and client/ to the client? anything outside is both.
> Yup, you got it. The files in the following directories in your example
> will only be available to the client:
> foo/client
> bar/client
> /
> The files in the following directories will be only available on the server
> foo/server
> bar/server
> /
> You'll find you will write some common javascript (like utility functions
> and basic data model definitions) that you'll want to include in both the
> client and the server. Rather than include them in the / directory in this
> case, it would be better to create another directory to store them. If you
> don't care when they are loaded, you could name that directory 'common' -
> if you want it loaded before the other javascript files, you would name it
> 'lib'. So a good way to organize could be:
> Yup, you got it. The files in the following directories in your example
> will only be available to the client:
> lib/
> foo/client
> bar/client
> /
> The files in the following directories will be only available on the server
> lib/
> foo/server
> bar/server
> server
> /
> Hope that helps.
> -iain
> --
> You received this message because you are subscribed to the Google Groups
> "meteor-talk" group.
> To post to this group, send email to meteor-talk@googlegroups.com.
> To unsubscribe from this group, send email to
> meteor-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/meteor-talk?hl=en.
--
-- Shawn McElroy
"Anything worth doing, is worth doing right" — Hunter S. Thompson
On Aug 17, 2012, at 11:30 AM, Shawn McElroy <luckysm...@gmail.com> wrote:
> Yea it makes sense now. It just so different than what I'm used to. Where models are where a lot of the core app functionality which, if the end user could see, could allow them to easily copy your code which you would not want. But here the model is exposed. But since the focus on meteor is having a local client db to make the site appear real time, it makes sense to me. so here in the models I would only have the minimal code needed for the app to function properly.
> Which begs the question, for code I dont want end users to see that I would normally have in a model, or a controller, where would I put that? For controllers and what I am used to, the controllers handle all the communication between model and view. the model validates and returns the dataset, and the controller, if needed, preps the data to be available in the view. The way meteor works, I would need that kind of info on both client and server as well. Which I would probable end up all just putting into the models here.
> So for code I dont want end users to see I would put it in the lib or server directories. but short of server side validation and maybe some schema definitions, or server/app configs, I dont see a lot else I would put in there. I just want to be able to prevent users from being able to capture code and being able to use it (for proprietary apps, which I would make at my job). While I love the idea of meteor and how it works, it so far, seems to me that the vast majority of your application code is visible to the end user. Granted it is all minified/obfuscated which makes it more difficult. Just for the apps I make at my job, code security is of high importance. And for those kinds of apps, meteor may not be as much as a fit as I need it to be.
I think perhaps a better way to think of it is: "I'm writing an app that lives in the browser". Everything lives in the browser - including the database (mongoDB)! That means everything - views, models, logic, controllers and data storage - all lives in the browser.
Meteor adds special magic so that what happens in the browser is automatically reflected on the server and pushed out to other people running their apps in other browsers. "Meteor + server" is really just magic "sync and shard" technology to keep all the databases (minimongo) in the apps running in each person's browser in sync and to "shard" the data (using the server "publish" functions) so that people only see the slices of data they should (depending on your app design, permissions, etc). In general, you should never need to really think about this other than how to manage the "publish" functions to ensure clients only get the data they should.
On a practical level, Meteor on the server is also where you have to perform re-validation of data to prevent rogue clients, script kiddies, etc from corrupting the shared database or accessing data they shouldn't. e.g. someone on the client updated the mongodb database (minimongo) running in the browser - before I write it to the shared database on the server, I'll rerun the validation to ensure the data is OK then allow/reject the write/sync. This should be the same validation logic you run on the client before writing it to the browser's minimongo so code reuse should be nearly 100%.
Finally, Meteor.methods() allows you to write the server-side services that you simply can't implement in a browser-only app - and those services can be thought of like accessing any other "remote" API from a browser-only app. E.g. I want to access an ERP system - obviously you can't do that within the browser so you Meteor.call a Meteor.method that runs access code on the server, and returns results.
As for code security, you are correct in that a lot of the application code for a normal Meteor app will typically be exposed in the client (minified and obfuscated but it's still there to be reverse engineered). My guess is that depending on your use case and application design this could be a problem. I think that's especially true if you don't want all your page templates available in the browser since Meteor doesn't provide any way to control what is pushed to the browser (they may add an API for it but it's definitely not present now). Meteor certainly makes it easier to pull all the page templates but most web apps aren't that hard to reverse engineer so any security by obscurity is really just a false sense of "being secure". I think this is an area where Meteor support is currently very limited - but also an area where future Meteor improvements will probably focus (I know a lot of related features are on the drawing boards).
I think in most cases, most web apps won't really be less "code insecure" with Meteor. But if you are doing really unique things at the browser level (like your page layout or navigation/page-flow depends on proprietary code you don't want exposed e.g. order the page links in a certain way to Thursdays in odd hours, but all other days except saturdays, use another layout, etc) then Meteor will probably not be for you.
Of course, the framework is young - just thinking about that example, those use-cases may be addressed in the future - localization and browser detection (mobile vs desktop vs tablet) features that are on the roadmap could allow you to serve different templates to different users for different reasons (all defined on the server)... :)
OK thanks, that helps make a lot of sense. I was talking to a few people in
irc as well that helped clear a lot of things up too. So at this point I
think I have a far better idea on where/how I would use meteor in this way.
thanks for all your input.
On Fri, Aug 17, 2012 at 12:32 PM, Iain Shigeoka <i...@shigeoka.com> wrote:
> On Aug 17, 2012, at 11:30 AM, Shawn McElroy <luckysm...@gmail.com> wrote:
> > Yea it makes sense now. It just so different than what I'm used to.
> Where models are where a lot of the core app functionality which, if the
> end user could see, could allow them to easily copy your code which you
> would not want. But here the model is exposed. But since the focus on
> meteor is having a local client db to make the site appear real time, it
> makes sense to me. so here in the models I would only have the minimal code
> needed for the app to function properly.
> > Which begs the question, for code I dont want end users to see that I
> would normally have in a model, or a controller, where would I put that?
> For controllers and what I am used to, the controllers handle all the
> communication between model and view. the model validates and returns the
> dataset, and the controller, if needed, preps the data to be available in
> the view. The way meteor works, I would need that kind of info on both
> client and server as well. Which I would probable end up all just putting
> into the models here.
> > So for code I dont want end users to see I would put it in the lib or
> server directories. but short of server side validation and maybe some
> schema definitions, or server/app configs, I dont see a lot else I would
> put in there. I just want to be able to prevent users from being able to
> capture code and being able to use it (for proprietary apps, which I would
> make at my job). While I love the idea of meteor and how it works, it so
> far, seems to me that the vast majority of your application code is visible
> to the end user. Granted it is all minified/obfuscated which makes it more
> difficult. Just for the apps I make at my job, code security is of high
> importance. And for those kinds of apps, meteor may not be as much as a fit
> as I need it to be.
> I think perhaps a better way to think of it is: "I'm writing an app that
> lives in the browser". Everything lives in the browser - including the
> database (mongoDB)! That means everything - views, models, logic,
> controllers and data storage - all lives in the browser.
> Meteor adds special magic so that what happens in the browser is
> automatically reflected on the server and pushed out to other people
> running their apps in other browsers. "Meteor + server" is really just
> magic "sync and shard" technology to keep all the databases (minimongo) in
> the apps running in each person's browser in sync and to "shard" the data
> (using the server "publish" functions) so that people only see the slices
> of data they should (depending on your app design, permissions, etc). In
> general, you should never need to really think about this other than how to
> manage the "publish" functions to ensure clients only get the data they
> should.
> On a practical level, Meteor on the server is also where you have to
> perform re-validation of data to prevent rogue clients, script kiddies, etc
> from corrupting the shared database or accessing data they shouldn't. e.g.
> someone on the client updated the mongodb database (minimongo) running in
> the browser - before I write it to the shared database on the server, I'll
> rerun the validation to ensure the data is OK then allow/reject the
> write/sync. This should be the same validation logic you run on the client
> before writing it to the browser's minimongo so code reuse should be nearly
> 100%.
> Finally, Meteor.methods() allows you to write the server-side services
> that you simply can't implement in a browser-only app - and those services
> can be thought of like accessing any other "remote" API from a browser-only
> app. E.g. I want to access an ERP system - obviously you can't do that
> within the browser so you Meteor.call a Meteor.method that runs access code
> on the server, and returns results.
> As for code security, you are correct in that a lot of the application
> code for a normal Meteor app will typically be exposed in the client
> (minified and obfuscated but it's still there to be reverse engineered). My
> guess is that depending on your use case and application design this could
> be a problem. I think that's especially true if you don't want all your
> page templates available in the browser since Meteor doesn't provide any
> way to control what is pushed to the browser (they may add an API for it
> but it's definitely not present now). Meteor certainly makes it easier to
> pull all the page templates but most web apps aren't that hard to reverse
> engineer so any security by obscurity is really just a false sense of
> "being secure". I think this is an area where Meteor support is currently
> very limited - but also an area where future Meteor improvements will
> probably focus (I know a lot of related features are on the drawing boards).
> I think in most cases, most web apps won't really be less "code insecure"
> with Meteor. But if you are doing really unique things at the browser level
> (like your page layout or navigation/page-flow depends on proprietary code
> you don't want exposed e.g. order the page links in a certain way to
> Thursdays in odd hours, but all other days except saturdays, use another
> layout, etc) then Meteor will probably not be for you.
> Of course, the framework is young - just thinking about that example,
> those use-cases may be addressed in the future - localization and browser
> detection (mobile vs desktop vs tablet) features that are on the roadmap
> could allow you to serve different templates to different users for
> different reasons (all defined on the server)... :)
> -iain
> --
> You received this message because you are subscribed to the Google Groups
> "meteor-talk" group.
> To post to this group, send email to meteor-talk@googlegroups.com.
> To unsubscribe from this group, send email to
> meteor-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/meteor-talk?hl=en.
--
-- Shawn McElroy
"Anything worth doing, is worth doing right" — Hunter S. Thompson
