Customizing server/client/public directories

[luckysmack]

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.

[Iain Shigeoka]

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:

https://github.com/tmeasday/unofficial-meteor-faq#where-should-i-put-my-files

-iain

> --
> 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 meteo...@googlegroups.com.
> To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.

[Shawn McElroy]

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:

foo/server/

foo/client/

server/

bar/client/

baz/server/

where all the server directories would properly only expose code to the server, and client/ to the client? anything outside is both.

--

 -- Shawn McElroy

"Anything worth doing, is worth doing right"  — Hunter S. Thompson

"A mind troubled by doubt cannot focus on the course to victory" — Arthur Golden

[Iain Shigeoka]

On Aug 17, 2012, at 7:30 AM, Shawn McElroy <lucky...@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:
>
> foo/server/
> foo/client/
> server/
> bar/client/
> baz/server/
>
> 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:

foo/server/
foo/client/
server/
bar/client/
baz/server/

lib/

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

[Shawn McElroy]

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.

-iain

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To post to this group, send email to meteo...@googlegroups.com.
To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.

[Iain Shigeoka]

On Aug 17, 2012, at 11:30 AM, Shawn McElroy <lucky...@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

[Shawn McElroy]

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.

-iain

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To post to this group, send email to meteo...@googlegroups.com.
To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.