Directory Structure

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.

Boost’s Application Directory

The “app” Directory

The 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.

The “boost” Directory

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.

The “config” Directory

The 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.

The “public” Directory

This directory includes all your asset files, like JavaScript, CSS, and images.

The “resources” Directory

This directory contains the web views and raw asset files. Put all your JavaScript or CSS files in the 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.

The “start” Directory

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.

The “storage” Directory

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.

The “test” Directory

This directory includes all your application tests. To get started with testing in Boost, you should read the Testing section.

The “app” Directory

This directory contains the important files of your application: the handlers that process the application’s logic. You’ll find pre-configured directories, like events, listeners, or 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 folder.

The “http“ Directory

The http directory houses all your route handlers and middleware. Everything that interacts with requests should go in here.

The “events“ Directory

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.

The “listeners“ Directory

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.

The “mails“ Directory

Mailables in Boost are JavaScript classes. Create all the emails you want to send out as a class. Boost ships with a WelcomeMail that will send warm hugs and a welcome message to the newly signed up user.

The “models“ Directory

The 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.