Request Lifecycle

When utilising any tool in the "real world," knowing how it works gives you more confidence. It's the same with application development. You'll feel more at ease and competent utilising your development tools once you grasp how they work.
This document's purpose is to provide you with a high-level understanding of how the OstroJS framework works. By becoming more familiar with the general framework, things will feel less "magical," and you will be more confidence in your application development. Don't be discouraged if you don't grasp all of the words straight immediately. Just attempt to gain a fundamental understanding of what's going on, and as you go further into the material, your knowledge will expand.

Depending on the type of request that enters the programme, the incoming request is then routed to either the HTTP kernel or the console kernel. These two kernels act as the hub via which all requests are routed. For the time being, let's simply concentrate on the HTTP kernel, which can be found at app/http/kernel.js.

The HTTP kernel is an extension of the @ostro/foundation/http/kernel class, which provides an array of bootstrappers to run before the application started. When application start, these bootstrappers configure error handling, configure logging, identify the application environment, and do other duties. Typically, these classes take care of internal OstroJS setup, so you don't have to.

The HTTP kernel also specifies a set of HTTP middleware through which all requests must transit before being processed by the application. These middleware are responsible for reading and writing HTTP sessions, detecting whether the application is in maintenance mode, validating the CSRF token, and more. We'll go through these in further detail later.

The handle method of the HTTP kernel has a basic method signature: it accepts a Request and returns a Response. Consider the kernel as a large black box that contains your whole programme. It will return HTTP replies if you send it HTTP queries.

Loading the service providers for your application is one of the most critical kernel bootstrapping tasks. The providers array in the config/app.js configuration file contains all of the application's service providers.

This list of providers will be iterated over by OstroJS, which will instantiate each one. The register method will be invoked on all of the providers when they have been instantiated. The boot method will be called on each provider when all of the providers have been registered. This is done so that service providers may rely on every container binding being registered and accessible when their boot method is called.

All of the framework's many components, including as the database, validation, and routing components, are bootstrapped by service providers. Almost all of OstroJS’S key features are bootstrapped and set by a service provider. Service providers are the most essential element of the entire OstroJS bootstrap process since they bootstrap and configure so many of the framework's capabilities.

The app/providers/routeServiceProvider is one of the most crucial service providers in your app. This service provider loads the route files in the routes directory of your application. Take a peek at how RouteServiceProvider works by cracking open the code! 

The Request will be handed over to the router for dispatching after the application has been bootstrapped and all service providers have been registered. The router will route the request to the appropriate route or controller and perform any route-specific middleware.

Middleware is a useful tool for filtering and analysing HTTP requests that come into your application. OstroJS, for example, has a middleware that checks if the user of your application is authorised. The middleware will send the user to the login screen if the user is not authorised. If the user is authorised, however, the middleware will allow the request to continue inside the application. Some middleware, such as those defined in your HTTP kernel's $middleware variable, are allocated to all routes in the application, while others are exclusively assigned to specific routes or route groups. You can learn more about middleware by reading the complete middleware documentation.

The route or controller method will be performed if the request goes through all of the matching route's assigned middleware, and the response provided by the route or controller method will be sent back via the route's chain of middleware.

The response will go back outward through the route's middleware whenever the route or controller method provides a response, providing the application the opportunity to change or analyse the outgoing response.

Finally, the HTTP kernel's handle method executes the send function on the received response once the response has passed through the middleware. The response content is sent to the user's web browser using the send method. Our tour through the whole OstroJS request lifecycle is now complete!

The importance of service providers in the bootstrapping of a OstroJS application cannot be overstated. The request is sent to the bootstrapped application, which creates the application instance and registers the service providers. That's all there is to it!

It's quite beneficial to have a solid understanding of how a OstroJS application is constructed and bootstrapped using service providers. The app/providers directory contains the default service providers for your application.

The appServiceProvider is quite empty by default. This provider is an excellent location to add your own bootstrapping and service container bindings to your application. You could want to establish many service providers for big applications, each with more granular boolean logic.