Application entry

Application entry-point

The framework library expects an entry-point. The entry-point to an application is a callable method. It accepts one parameter and returns a set of callbacks. It should be configured in the PKG-INFO file of that application.

The format for the entry-point is as below


Let’s say the entry-point callable entry_point is defined in your app’s module example_app.entry_module, then the entry-point should look like


Application States

The entry-point accepts one parameter. This parameter signifies the state at which the application is started. At any time, only one of the following states is applicable.


    It means that the application is started afresh. The application can initialize when this state is received.


    It means the application is restarted after recovering from a crash. This state is not supported for now and is reserved for future use.


    It means the application is getting upgraded and this is the first call to the upgradation process. Any initialization needed for the migration process can be done in this state.The application will not listen to any requests from the client while in this state.


    It means the application is getting upgraded and this is the final stage of the upgradation process. This state is equivalent to STATE_STARTED except that this signifies that the application has just now completed migrating its data from the old app.


    This is called mostly by the packager which does the package validation. This state expects only the routing parameters from the entry-point, so any initialization done in this state will fail.

Application callbacks

The application entry-point should return a set of callbacks relevant to the application state. The return type is a dictionary (key-value pairs). The values for each field is a callable and the key being one among the following.


    The callable should accept one parameter, which is an object to the mapper of python routes module. Through this callback the application can register all the URL routes. This callback will be invoked on all the application states except STATE_MIGRATE.


    The value should be a callable which accepts no parameter. This is invoked when the application is asked to quit. When it is invoked the application will not serve any incoming requests, however it will wait till the application finishes serving earlier requests. This callback should close up any persistent connections like websockets. If the cleanup is proper, the application will quit imediately after serving the last HTTP request, else the application will be terminated after some time.


    This callable accepts one parameter which contains the previous version of this application that it is migrating from. After this callback is returned, the application quits immediately.

    This callback will be invoked only on STATE_MIGRATE.

    Any data migration from the previous version should be done here. While migrating, the older application will still be running, so the migration should not affect the older application.


    This callback is invoked on the new process that is running on state STATE_POST_MIGRATE. This is invoked as soon as the old process quits after serving all its pending connections.