-
Notifications
You must be signed in to change notification settings - Fork 18
Backend ‐ Architecture
Napari Hub's backend acts as a conduit for accessing data specific to plugins on Napari. It supports the API endpoints required by the front end and other clients. It surfaces information on the plugins, categories, collections, metrics specific to the plugin, etc. We can find the endpoints currently supported by the napariHub backend here.
We leverage serverless architecture to implement the backend service for the Napari Hub. The backend server runs in the AWS ecosystem on Lambdas. DynamoDB is used to persist data rendered by the backend. Caching layers reduce the latency for user requests. The caching layers include caching of response using CloudFront and plugin data in Dynamo.
The high-level architecture diagram can be found here: https://lucid.app/lucidchart/d32995a2-42d6-4ccd-84fc-9c5a097304de/view
To find more detailed architecture diagrams on categories, metrics, and, plugin-metadata please refer to their linked individual pages.
The application's startup must be fast as we leverage lambdas to serve the backend request. We do this by utilizing a lightweight framework that can start up quickly, and the flask is a perfect candidate for this.
Currently, all the API calls the frontend client utilizes are GET methods routed to the backend through an API gateway. This call triggers the start of the flask application that renders the results for the requested path. The code for this is defined in the backend module.
The Napari Hub does not support API calls for clients with POST methods.
To reduce latency at request time, we pre-fetch and compute data for plugins and pre-aggregate the metrics for the plugin. Data update jobs are run periodically in the background to keep those data current. The code is defined in the data workflows and plugin module.
These workflows are not exposed via API calls.