Introduction

The default OstroJS application structure is meant to provide a good starting point for both large and small apps. However, you are allowed to structure your application in any way you like. OstroJS places practically no limitations on the location of any given class.

The Root Directory

The app Directory

The essential code of your Application is stored in the app directory. We'll go over this directory in more depth later, but it contains virtually all of the classes in your application.

The bootstrap Directory

The app.js file, which bootstraps the framework, is located in the bootstrap directory. You shouldn't need to change any of the files in this directory very often.

The config Directory

All of your application's configuration files are stored under the config directory, as the name indicates. It's a good idea to go over all of these documents and become comfortable with all of your alternatives.

The database Directory

Your database migrations, model factories, and seeds are all stored in the database directory. You may also use this directory to store a SQLite database if you like.

The public Directory

The static assets, such as pictures, JavaScript, and CSS, are stored in the public directory.

The resources Directory

Your views, as well as any raw, uncompiled elements like CSS or JavaScript, are stored in the resources directory. All of your language files are also stored in this directory.

The routes Directory

The routes directory includes all of your application's route definitions. OstroJS comes with multiple route files by default: web.js, api.js, and console.js.

The RouteServiceProvider inserts routes in the web middleware group, which offers session state, CSRF protection, and cookie encryption, in the web.js file. If your site does not provide a stateless, RESTful API, all of your routes will almost certainly be defined in the web.js file.

The RouteServiceProvider adds routes to the api middleware group in the api.js file. These routes are designed to be stateless, which means that requests entering the application through them will be authenticated using tokens and will not have access to session information.

All of your closure-based console commands are defined in the console.js file. Each closure is associated with a command instance, providing for an easy way to communicate with the IO methods of each command. This file defines console-based entry points (routes) into your application, despite the fact that it does not specify HTTP routes.

The storage Directory

Your logs, file-based sessions, file caches, and other files created by the framework are all stored under the storage directory. This directory is divided into three sections: app, framework, and logs. Any files created by your application can be stored in the app directory. Framework produced files and caches are stored in the framework directory. Finally, the logs directory includes the log files for your application.

The storage/app/public directory can be used to store user-generated files that should be publicly available, such as profile avatars. You should make a symbolic link to this directory under public/storage. The node assistant storage:link Assistant command may be used to make the link.

The App Directory

The app directory contains the majority of your application.
Additional folders such as Console, Http, and Providers may be found in the app directory. Consider the Console and Http folders to be APIs into your application's core. Both the HTTP protocol and the CLI are methods for interacting with your programme, but none contains application logic. To put it another way, there are two methods for sending commands to your programme. All of your Assistant instructions are stored in the Console directory, while your controllers, middleware, and requests are stored in the Http directory.

The Console Directory

All of your application's custom Assistant commands are stored in the Console directory. The make:command command can be used to produce these commands. This directory also contains your console kernel, which is where you register your own Assistant commands and configure your scheduled tasks.

The Events Directory

This directory does not exist by default; however, the following event will create it for you: Assistant commands event:generate and make:event Event courses can be found in the Events directory. Events may be used to notify other sections of your application that a certain action has taken place, giving you a lot of flexibility and decoupling.

The Exceptions Directory

Your application's exception handler is located in the Exceptions directory, which is also an excellent place to store any exceptions thrown by your application. Modify the Handler class in this directory if you want to change how your exceptions are logged or displayed.

The Http Directory

Controllers, middleware, and form requests are all stored under the Http directory. This directory will house almost all of the logic for handling requests that come into your application.

The Listeners Directory

This directory does not exist by default, but if you run the following event, it will be created for you: Assistant commands such as event:generate or make:listener The classes that handle your events are found in the Listeners directory. In reaction to the event being fired, event listeners receive an event instance and perform logic. A sendWelcomeEmail listener, for example, may handle a userRegistered event.

The Models Directory

All of your Eloquent model classes are stored in the Models directory. For dealing with your database, the Eloquent ORM bundled with OstroJS provides a beautiful, straightforward ActiveRecord implementation. Each database table has a "Model" associated with it that is utilised to communicate with it. Models enable you to query your tables for data as well as add new records to the database.

The Providers Directory

All of the service providers for your application are included in the Providers directory. Service providers prepare your application for incoming requests by binding services in the service container, registering events, and doing any other activities necessary.

This directory will already have numerous providers in a new OstroJS application. As needed, you are free to add your own suppliers to this list.