Skip to main content
version 1.0.0

Application Lifecycle


When using any tool in the "real world", you feel more confident if you understand how that tool works. Application development is no different. When you understand how your development tools function, you feel more comfortable and confident using them.

The goal of this document is to give you a good, high-level overview of how the Athenna framework works. By getting to know the overall framework better, everything feels less "magical" and you will be more confident building your applications. If you don't understand all the terms right away, don't lose heart! Just try to get a basic grasp of what is going on, and your knowledge will grow as you explore other sections of the documentation.

Lifecycle overview

First steps

The entry point for all types of an Athenna application is the bootstrap/main.js file. The first action taken by Athenna itself is to create an instance of the application and then boot it.


Athenna has the class called Ignite. This class is responsible for resolving your environment, your language type (ts, js), resolving your environment files and configuration files of config folder and booting/registering your providers. In the end of all, fire method returns a new Application instance, and it's with this instance that we are going to choose what type of application we want to run (http, worker, cli, etc...).

Service providers

One of the most important kernel bootstrapping actions is loading the service providers for your application. All the service providers for the application are configured in the config/app.js configuration file's providers array.

Athenna will iterate through this list of providers and instantiate each of them. After instantiating the providers, the register method will be called on all the providers. Then, once all the providers have been registered, the boot method will be called on each provider. This is so service providers may depend on every container binding being registered and available by the time their boot method is executed.

Service providers are responsible for bootstrapping all the framework's various components, such as the database, http server, validation, services and routing components. Essentially every major feature offered by Athenna is bootstrapped and configured by a service provider. Since they bootstrap and configure so many features offered by the framework, service providers are the most important aspect of the entire Athenna bootstrap process.


Each Athenna application type have a Kernel. This classes serves configurations for each type of application.

The Kernel of Http folder extends the HttpKernel class from @athenna/http, which defines some bootstraps that will be run before the routes/http file is preloaded. These bootstraps configure error handling, configure logging, detect the application environment, and perform other tasks that need to be done before the request is actually handled. Typically, these classes handle internal Athenna configuration that you do not need to worry about.

The Kernel of Http folder also defines a list of global middlewares that all requests must pass through before being handled by the application. It also defines your named middlewares to use inside routes/http file. See the example:

* The application's global HTTP middlewares.
* This middlewares are run during every request to your http server.
get globalMiddlewares() {
return [import('#app/Http/Middlewares/ResponseMiddleware')]

Or you can define as a named middleware and choose what routes are going to use it inside routes/http:

* The application's named HTTP middlewares.
* Here you define all your named middlewares to use inside routes/http file.
get namedMiddlewares() {
return {
response: import('#app/Http/Middlewares/ResponseMiddleware')
Route.get('/', '').middleware('response')


The routes folder is the kernel of your application. The route files that you will find here are:

This file is responsible to create a contract between your client and your application. Is in here that we define all of ours routes and the controllers who will handle the client request.

One of the most important service providers in your application is the HttpRouteProvider. This service provider adds in the container the Route class instance used inside http file.

When the client request arrives, the server first execute all handle method of your global middlewares. Than it will execute the handle method of all your route middlewares. Once it finish, it goes for your controller or handler function. See the example:

Handle request imageHandle request image

Finishing up

Once the controller/handler function returns a response, the response will travel back outward through the intercept method of each global middleware and than route's middleware, giving the application a chance to modify or examine the outgoing response. See the example:

Handle request imageHandle request image

As you can see in the example the response content is sent to the client. The request finish for the client but not for the server. Now it's time to execute the terminate method from our global and route's middleware. The terminate method is executed when a response has been sent, so you will not be able to send more data to the client. It can however be useful for sending data to external services, for example, create metrics of the entire request. See the example:

Handle request imageHandle request image

Finally, once the terminate method is executed in all middlewares the request finish in the server. We've finished our journey through the entire Athenna request lifecycle!

Focus on service providers

Service providers are truly the key to bootstrapping an Athenna application. The application instance is created, the service providers are registered, and the request is handed to the bootstrapped application. It's really that simple!

Having a firm grasp of how an Athenna application is built and bootstrapped via service providers is very valuable. Your application's default service providers are stored in the providers directory.

By default, the AppServiceProvider is fairly empty. This provider is a great place to add your application's own bootstrapping and service container bindings. For large applications, you may wish to create several service providers, each with more granular bootstrapping for specific services used by your application.