Lifecycle

Different behavior modes for the Orchestrator

The Orchestrator has a few different stages of its lifetime as a singleton within your app:

Prestart

In this stage, the Orchestrator loads itself into memory. This is before any of your app's code runs. Here's what happens:

1. The Orchestrator takes over the entire app. It will not give up control until shutdown or until a fatal error occurs.

2. The Orchestrator singleton is created and it gets ready to run services. This is one of a few synchronous parts of its existence.

3. Any prestart handlers will run. It is highly recommended to avoid using these handlers to do anything related to app code, so you should only use it to control the operation of the Orchestrator. Any failures here will bypass error handling and immediately terminate the Orchestrator.

4. It will search recursively for all needed dependencies of your entry points and create a job queue that it will follow. Every new dependency is added to the start of the job queue. All other dependencies are loaded into memory but not instantiated.

Startup

This is when the startup job queue will be acted upon synchronously. Because this queue only consists of needed dependencies, it won't be too long.

1. The job queue is executed from start to finish, plumbing things together where needed to have access to the proper APIs

2. When all entry services are declared ready,