mirror of
https://github.com/StanGirard/quivr.git
synced 2024-11-24 14:08:09 +03:00
cce7c25a3e
small improvments
60 lines
2.9 KiB
Plaintext
60 lines
2.9 KiB
Plaintext
---
|
|
sidebar_position: 3
|
|
title: Specifications
|
|
---
|
|
|
|
Quivr is using FastAPI to provide a RESTful API for the backend. The API is currently in beta and is subject to change. The API is available at [https://api.quivr.app](https://api.quivr.app).
|
|
|
|
You can find the Swagger documentation for the API at [https://api.quivr.app/docs](https://api.quivr.app/docs).
|
|
|
|
## Overview
|
|
|
|
This documentation outlines the key points and usage instructions for interacting with the API backend. Please follow the guidelines below to use the backend services effectively.
|
|
|
|
## FastAPI
|
|
|
|
FastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints. FastAPI is a class-based API framework that is built on top of Starlette and Pydantic. FastAPI is a great choice for building APIs because it is easy to use, fast, and has a lot of great features.
|
|
|
|
We decided to choose FastAPI because it is a modern, fast, and easy-to-use API framework. FastAPI is also very well documented and has a lot of great features that make it easy to build APIs. FastAPI is also very well supported by the community and has a lot of great features that make it easy to build APIs.
|
|
|
|
## Authentication
|
|
|
|
The API uses API keys for authentication. You can generate an API key by signing in to the frontend application and navigating to the `/config` page. The API key will be required to authenticate your requests to the backend.
|
|
|
|
When making requests to the backend API, include the following header:
|
|
|
|
```http
|
|
Authorization: Bearer {api_key}
|
|
```
|
|
|
|
Replace `{api_key}` with the generated API key obtained from the frontend
|
|
|
|
You can find more information in the [Authentication](/docs/Developers/useQuivr/get_your_api_key) section of the documentation.
|
|
|
|
|
|
## Architectural Schema
|
|
|
|
|
|
<div style={{ textAlign: 'center' }}>
|
|
<img src="/images/architectural-high-level.png" alt="Quivr architecture" style={{ width: '60%' }} />
|
|
</div>
|
|
|
|
### Load Balancer
|
|
|
|
The role of the load balancer is to catch the incoming traffic and redirect to the corresponding server. It is also responsible for the SSL termination.
|
|
|
|
### Container Service
|
|
|
|
The role of this service is to manage the replicas of all the services. It hold the information about the number of replicas of each service and the corresponding server.
|
|
|
|
### Queue
|
|
|
|
The role of the queue it to store "tasks" that are long to run and that can be run asynchronously. In our case we use it to embed the files and to index them as it can take a lot of time.
|
|
|
|
### Celery Worker
|
|
|
|
The role of the celery worker is to run the tasks that are stored in the queue. It is a distributed task queue that can run tasks asynchronously.
|
|
|
|
### Supabase
|
|
|
|
Supabase is used to do the authentication and to store the users information. It is a great open-source alternative to Firebase. It is currently used as a database, an authentication service, a vector store and a file store. |