Контекст
У нас есть большое приложение Django со сложным интерфейсом, в котором смешаны несколько технологий.Мы думаем о крупном перепроектировании и хотим избежать некоторой сложности органического роста, то есть большого количества ручного отслеживания изменений и отдельных конечных точек в REST API.
Модель данных охватывает дюжину приложений Django и 156 таблицв PostgreSQL.Некоторые ресурсы очень велики и содержат списки сопоставлений с другими, более мелкими ресурсами.Например, AirplaneRepair, структура данных, описывающая планируемую операцию, содержит требования к оборудованию и персоналу, оба с ограничениями относительно , когда они необходимы.
Внешний интерфейс имеетНесколько общих функций, которые бросают вызов текущей архитектуре:
- автоматическое сохранение изменений (аналогично Google Drive)
- отмена / повтор (хорошо работает с избыточностью)
- управление версиями компонентов, описывающих операции (например, версия операции AirplaneRepair со всеми ее ограничениями для экипажа и оборудования)
- хранится в виде BLOB-объектов JSON в БД на данный момент
- , созданных в явном виде "создать версию "вызов пользователя
В противном случае это в основном манипулирование данными с принудительными проверками ограничений / согласованности на сервере.
Предлагаемая новая архитектура
Мы определили все наши модели в Джанго.Те должны остаться.ORM отображает их в БД.
API
API REST должен состоять из двух корневых частей
/api/v2/resources/ должендать общий доступ к CRUD для всех моделей.Обновления должны предоставляться с использованием принципов JSON-Patch (т. Е. Просто diff вместо целых BLOB-объектов JSON) ?fields=field1,field3,field5 должно позволять фильтрацию возвращаемых данных для возврата только запрошенных подполей ?expand=field.childrenдолжен вызывать prefetch_related или каким-либо другим способом автоматически расширять отношения в моделях и помещать их в возвращаемый JSON
/api/v2/services/ содержит любые конкретные вызовы RPC, которые запускают сложные действия в серверной частикоторые не отображаются на ресурсы
Внешний интерфейс
Внешний интерфейс основан на комбинации статических «кадров» и реагирующих компонентов внутри этих кадров.Мы используем react-redux, чтобы отслеживать наши данные.Читая это обсуждение reddit , кажется, что другие пытались жениться на документах json-patch и redux / реагировать.Как правило, шаблон действий / редукторов при редуксе должен обеспечивать простую реализацию нескольких концепций, упомянутых выше.
- Пользовательский интерфейс отображает данные на основе URL (т. Е. Ресурса и текущего представления)
- изменения в данных обернуты в действия и редукторы
- использовать промежуточное программное обеспечение redux для отправки любых действий по обработке данных в бэкэнд
- обновление хранилища избыточности в ответах ajax
- обновить хранилище притока через канал "уведомлять" веб-сокета, который позволяет серверу обновлять свои клиенты об изменившихся ресурсах
Открытые вопросы
- Каковы способыВ общем, все определенные модели представлены в django через API остальных CRUD (желательно с DRF)
- . Как мы здесь подключаемся к жизненному циклу для обработки упомянутых параметров запроса
- Как следуетмы сопоставляем избыточные действия с запросами PATCH / POST / PUT?Частичные обновления особенно интересны, поскольку нам не следует отправлять весь блок JSON туда и обратно просто для обновления одного поля
- Является ли JSON-Patch широко используемым стандартом?