aitoroses/organization.txt

## organization.txt
As in the unofficial meteor faq, I think it pretty much explains how do structure a large app:

Where should I put my files?
The example apps in meteor are very simple, and don’t provide much insight. Here’s my current thinking on the best way to do it: (any suggestions/improvements are very welcome!)

lib/                    # <- any common code for client/server.
lib/environment.js      # <- general configuration
lib/methods.js          # <- Meteor.method definitions
lib/external            # <- common code from someone else
## Note that js files in lib folders are loaded before other js files.

collections/                 # <- definitions of collections and methods on them (could be models/)

client/lib              # <- client specific libraries (also loaded first)
client/lib/environment.js   # <- configuration of any client side packages
client/lib/helpers      # <- any helpers (handlebars or otherwise) that are used often in view files

client/application.js   # <- subscriptions, basic Meteor.startup code.
client/index.html       # <- toplevel html
client/index.js         # <- and its JS
client/views/<page>.html  # <- the templates specific to a single page
client/views/<page>.js    # <- and the JS to hook it up
client/views/<type>/    # <- if you find you have a lot of views of the same object type

server/publications.js  # <- Meteor.publish definitions
server/lib/environment.js   # <- configuration of server side packages
For larger applications, discrete functionality can be broken up into sub-directories which are themselves organized using the same pattern. The idea here is that eventually module of functionality could be factored out into a separate smart package, and ideally, shared around.

feature-foo/               # <- all functionality related to feature 'foo'
feature-foo/lib/           # <- common code
feature-foo/models/        # <- model definitions
feature-foo/client/        # <- files only sent to the client
feature-foo/server/        # <- files only available on the server
	As in the unofficial meteor faq, I think it pretty much explains how do structure a large app:

	Where should I put my files?
	The example apps in meteor are very simple, and don’t provide much insight. Here’s my current thinking on the best way to do it: (any suggestions/improvements are very welcome!)

	lib/ # <- any common code for client/server.
	lib/environment.js # <- general configuration
	lib/methods.js # <- Meteor.method definitions
	lib/external # <- common code from someone else
	## Note that js files in lib folders are loaded before other js files.

	collections/ # <- definitions of collections and methods on them (could be models/)

	client/lib # <- client specific libraries (also loaded first)
	client/lib/environment.js # <- configuration of any client side packages
	client/lib/helpers # <- any helpers (handlebars or otherwise) that are used often in view files

	client/application.js # <- subscriptions, basic Meteor.startup code.
	client/index.html # <- toplevel html
	client/index.js # <- and its JS
	client/views/<page>.html # <- the templates specific to a single page
	client/views/<page>.js # <- and the JS to hook it up
	client/views/<type>/ # <- if you find you have a lot of views of the same object type

	server/publications.js # <- Meteor.publish definitions
	server/lib/environment.js # <- configuration of server side packages
	For larger applications, discrete functionality can be broken up into sub-directories which are themselves organized using the same pattern. The idea here is that eventually module of functionality could be factored out into a separate smart package, and ideally, shared around.

	feature-foo/ # <- all functionality related to feature 'foo'
	feature-foo/lib/ # <- common code
	feature-foo/models/ # <- model definitions
	feature-foo/client/ # <- files only sent to the client
	feature-foo/server/ # <- files only available on the server