File Architecture
Package-Based Architecture
Vulcan’s core code follows a file-based architecture, which means every feature lives inside its own package which can be enabled or disabled to add or remove said feature; or even over-ridden with your own custom package of the same name.
App Packages
When building your own Vulcan app, you will typically create a new package that contains the code for your app. Although you are of course free to follow your own structure, we recommend the following file architecture.
Root Level
First, a Meteor package will contain a package.js package manifest that list its contents. On the same level, you will have a lib directory that contains the entirety of the package’s code. This lib directory is then divided into three directories:
/client: code that will only run inside the browser./server: code that will only run on the server./modules: code that will run on both.
Both client and server should contain a main.js entry point that will load client- and server- specific code as well a shared modules code.
Client Directory
Because Vulcan enables server-side rendering, very little code actually runs only on the client. This directory will thus be empty save for the main.js entry point that should point back to modules/index.js.
Modules Directory
We recommend splitting your code around your collection (a.k.a. models). For example, a forum app could have the following directories:
/modules/posts/modules/users/modules/comments
Each directory will then contain all or some of the following files:
collection.js: the main collection/model declarationschema.js: the schema definitionfragments.js: GraphQL fragments related to the collectionhelpers.js: any other code related to the collection
Additionally, we also recommend always including an index.js file to centralize all imports/exports in every directory.
Other Code
You will usually also end up with some code that is not directly related to any collection, such as components imports, route declarations, or internationalization definitions. You can leave those files in /modules.
Server Directory
The server directory should more or less mirror the modules directory in terms of being organized by collection, except it will contain code that only runs on the server, such as mutation callbacks.