Software Development Kit
The main feature of the Daeploy Software Development Kit (SDK) is the service object. It is used to create API endpoints by decorating functions, add parameters and monitor data. In addition to service, the SDK also contains functionality for communication between services and with the manager and IPython magic functions to allow you to write a service in a jupter notebook.
As stated above, the service object is the main feature of the SDK that consists of a few components
The Service class is built around the FastAPI app and provides a simple interface to add some common functionality to it. It is possible to mix usage of service.entrypoint and service.app to get the best of both worlds.
Each service has their own SQLite database and just like in the manager we connect to it with SQLAlchemy. We create tables dynamically by programatically defining classes with the build-in type function. Each monitored variable gets one table and we only allow strings and float numbers. If the variable is not a string or a number we try to coerce it to a JSON string.
We use multithreading with a producer-consumer queue to run database inserts asynchronously.
The monitoring API uses service database and can return the data as a raw SQLite database file, JSON or as CSV. The endpoints are added to the service upon initialization of the service object.
A get parameter endpoint is always added when initializing the service object, additional endpoints for getting and setting parameters are added when the add_parameter method is run. The parameters are stored in the parameters attribute of the service object.
The entrypoint() decorator method warrants some extra explanation due to it's complexity. It uses the built-in inspect module to examine the signature of the decorated function and create an API endpoint with the input arguments as a json body.
This is best shown with an example, let's say that we have a function with the signature hello(name: str, title: str = ""). Inside of the entrypoint decorator we will read that signature and change it to hello(_request: Request, name: str = Body(...), title: str = Body("")) which FastAPI will recognize as json body arguments. When we register the new function with this signature as an endpoint we will get the automated input validation that we are used to with FastAPI. The _request argument is used to extract the request information for monitoring but does not affect the format of the final endpoint.
This module contains functions to communicate with the manager. They use requests to send HTTP requests to the manager API. We use our own HTTP session class derived from requests.Session to set special rules when calling the manager host and we use the unique service token to authorize our requests to the manager.
The notify function sends notifications to the manager by sending POST requests to the notification API on the manager.
The call_service() function sends requests to other services on the manager host and returns the response.
We have created custom magic functions to save the contents of a cell to a daeploy service. There is also a magic function to save the cell contents to the requirements file.