Architecture#
Overview#
The software architecture of PyST is divided into three layers: router, application, and persistence. Each has its own data transfer objects (DTO), protocols, and unit tests.
Each layer is independent, and can only communicate with other layers through defined protocols.
Router#
Info
Source code for router endpoints, pydantic classes for incoming data, pydantic classes for outgoing data
PyST uses FastAPI to define ReST API endpoints. All API endpoints consume and emit JSON-LD.
Note
ReST API endpoints have separate documentation.
After using pydantic to validate incoming data, the endpoint functions create dataclasses for use in application logic, and call the appropriate application service functions.
Application#
Application functionality is implemented via service classes; we currently have two services, a graph service and a search service. Services do not persist data, but perform operations on data to either provide responses to users or prepare data for persistence.
Application functions can call the persistence layer during function execution, or when finished. The DTO between the application and persistence layers and the same as between the router and application layers.
Persistence#
The persistence layer makes the actual calls to the Postgres and Typesense databases. The structure of the application and persistence protocols are quite similar; in general, business logic should go in the application layer, and the persistence layer should only be for interfacing with the databases, but in practice this distinction can get fuzzy.