Boost gives you a default directory structure that should work well for small and large applications. The Boost framework tightly integrates with the given application structure using global variables.
Of course, you’re free to modify the application structure, but make sure to use the corresponding Node.js imports and don’t rely on Boost’s globals then.
Boost’s directory structure is inspired by the Laravel PHP framework. At first, it may overwhelm due to all the existing directories. You’ll quickly understand their use-case and value. It becomes a predictable and extensible architecture that is a joy to work with.
app directory is the core of your application. Everything related to your application should go in there. This directory contains subdirectories that we’ll explore soon.
This directory contains Boost’s utilities and the Craft CLI. The framework core ships directly with the application structure because we don’t have a private NPM registry set up yet.
A benefit of having Boost’s core directly in the project: you can navigate to files or step into them while debugging. You shouldn’t change anything in the
boost directory, only use the framework’s classes in your application.
config directory contains all your application configuration files. Have a look at the individual configuration files to become familiar with the available options to customize Boost’s behavior.
resources directory if you create a build pipeline. Reference the final build output to the
publicfolder, because Boost serves assets in your web views from there.
This directory contains all files to boot the Boost application server. It contains the server’s entry point which will compose an instance containing all the web plugins and middleware.
All files generated by the framework should go into the
storage directory. For example, logging to a file would store the log file within this storage folder. If you need to store something from your application, point the file handling to this directory.
This directory includes all your application tests. To get started with testing in Boost, you should read the Testing section.
This directory contains the important files of your application: the handlers that process the application’s logic. You’ll find pre-configured directories, like
models. These directories build a solid architecture by separating concerns.
When starting a Boost server, it will automatically look for events and related listeners in these directories. It’ll also register any web plugin located inside of the
http directory houses all your route handlers and middleware. Everything that interacts with requests should go in here.
You may guess what this directory contains (and you’re right): event classes. Use events to notify listeners about an action. Events are a great way to decouple logic into separate parts. For example, Boost ships with a
UserRegistered event that fires on user sign-up.
This directory contains all your event listeners. The listeners are classes that wait for a specific event to fire and then handle it. For example, Boost ships with the
SendWelcomeMail listener that waits for the
UserRegistered event to fire and then send out a welcome email.
WelcomeMail that will send warm hugs and a welcome message to the newly signed up user.
models directory stores all your application models. Boost ships with a
User model that you may extend or update to your needs.
Boost’s default application structure gives you a solid starting point for development. If you feel like there’s something missing or in the wrong place, go ahead and create additional directories or move them around. Don’t hesitate to change the structure.