/routeService

another sample test task project

Primary LanguagePython

Развёртывание

  1. Запустить БД с установленным расширением PostGIS
$ docker run --name postgis -e POSTGRES_PASSWORD=brutehorse -p 5432:5432 -d postgis/postgis

Если адрес БД в вашей установке будет отличаться, отразите это в .env файле в корне проекта. Для этого скопируйте .env.dist в .env

  1. (Из корня проекта) установить виртуальную среду и зависимости
$ python3 -m venv venv && venv/bin/activate
$ python3 -m pip install -r requirements.txt
  1. Создать исходную схему БД и заполнить семплами данных
$ python3 seed.py

Запуск

Из корня проекта, запустите сервис маршрутов:

$ python serve.py routes

В новом окне терминала запустите демонстрацию клиента этого сервиса

$ python client_routes.py

либо импортировать в интерпретатор чтобы поиграть с клиентом вручную

>>> from client_routes import client, msg
>>> rs = client.GetPoints(msg.GetPointsRequest(point_ids=[1,2,3]))

Аналогично с сервисом отчётов:

$ python serve.py reports

в новом окне терминала:

$ python client_reports.py

Мотивация

Я предположил, что сервис будет частью существующей микросервисной архитектуры, поэтому в качестве реализации API рискнул выбрать перспективный gRPC вместо классического OpenAPI. С gRPC я столкнулся впервые, и вникал по ходу написания сервиса, так что не судите строго.

Для безопасной реализации механизма аутентификации, в корне проекта лежат self-signed сертификат для клиента и приватный ключ сервера для организации защищённого ssl/tls канала. В VCS они только для примера, в реальном проекте они не должны быть включены в исходный код. Схема аутентификации также упрощена, механизм ротации токенов опущен и токены хранятся прямо в таблице пользователей.

Для хранения геоточек я рассматривал варианты графовой БД Neo4j и расширения PostGIS для Postgres. Я остановился на PostGIS, так как ни с одним вариантом я не работал ранее, и PostGIS показался мне проще в реализации, удобнее в интеграции данных и последующей поддержке.

Выделил 2 микросервиса:

  • для работы с маршрутами - требуется горячая БД, обладает единым логическим контекстом.
  • для отчётов - сравнительно долгие запросы, не требует горячую БД, не меняет данные, может быть посажен на холодную read-only реплику. Разделение на микросервисы скорее условное, у обоих остаются общими модели и зависимости.

Полезное

Шпаргалка для генерации кода из .proto файлов:

$ python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. protobufs/routes.proto
$ python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. protobufs/reports.proto