@wakenbyWork

Как правильно работать с таким rest api?

Всем привет! Есть проект, он написан на Django REST framework. На данный момент проект существует как MPA, новая реализация уже на React + Redux Toolkit. И вскрылись проблемы, которые нужно решать не понятным мне образом.

Мнение заказчика: Бек важнее фронта, бек правильно структурирован, каждый эндпоинт это самостоятельная сущность, которая отвечает только за себя. Организация БЕК части логически идеальна. Создавать новые эндпоинты которые могут отдавать данные из двух старых эндпоинтов, быдло-код который нарушает логику.

Я буду очень благодарен за ответ на вопрос: Как все таки правильно реализовывать rest api для фронта? Я просто хочу знать как должно быть, ибо я вижу то, что есть. Я даже не могу аргументировать свою позицию, ибо фраза: бек важнее, меня ставит в тупик, а моя фраза: пользователь важен не меньше, не доходит.

Пример с выдуманной историей (NDA):

63ea53bd4e5ad440683854.png

Владения:

UI

63ea1292e1b5d296664933.png


Состоят из:

  • Имя
  • Описание
  • Количество населенных пунктов в данной столице
  • Чипсы с быстрой информацией по уровню армии


Населенные пункты:

UI

63ea542fcb09e071556202.png


Состоят из:

  • Населенный пункт (Статичная строка)
  • Сторона (Статичная строка)
  • Добавлен (Статичная строка)
  • Обновлен (Статичная строка)
  • Статус


Описание API:

https://api-domain/groups/ - Список всех Владений
json

[
  {
    "id": 1,
    "name": "Вайтран",
    "desc": "Владение",
    "settlements_count": 80,
    "chips": {
      "level-1": 20,
      "level-2": 20,
      "level-3": 40
    }
  }
]



https://api-domain/meta-settlements/ - Список населенных пунктов (с meta информацией)
json

[
  {
    "name": "Вайтран",
    "army_info": 9.0,
    "update": 1674219110,
    "side_war": "Братья Бури",
    // Остальное мусор для данной страницы, но таков эндпоинт
    "dop_info_key_1": "dop_info_value",
    "dop_info_key_2": [
      "dop_info_value",
      "dop_info_value"
    ],
    "dop_info_key_3": "dop_info_value",
    "dop_info_key_4": [
      {
        "dop_info_key_5": [
          "dop_info_value",
          "dop_info_value"
        ],
        "dop_info_key_6": "dop_info_value",
        "dop_info_key_7": "dop_info_value",
        "dop_info_key_8": "dop_info_value",
        "dop_info_key_9": "dop_info_value",
        "dop_info_key_10": "dop_info_value",
        "dop_info_key_11": "dop_info_value",
        "dop_info_key_12": "dop_info_value",
        "dop_info_key_13": "dop_info_value",
        "dop_info_key_14": "dop_info_value"
      },
      {
        "dop_info_key_16": [
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
          "dop_info_value",
        ],
        "dop_info_key_17": "dop_info_value",
        "dop_info_key_18": "dop_info_value",
        "dop_info_key_19": "dop_info_value",
        "dop_info_key_20": "dop_info_value",
        "dop_info_key_21": "dop_info_value",
        "dop_info_key_22": "dop_info_value",
        "dop_info_key_23": "dop_info_value",
        "dop_info_key_24": "dop_info_value",
        "dop_info_key_25": "dop_info_value"
      },
      {
        "dop_info_key_26": "dop_info_value",
        "dop_info_key_27": "dop_info_value",
        "dop_info_key_28": "dop_info_value",
        "dop_info_key_29": "dop_info_value",
        "dop_info_key_30": "dop_info_value",
        "dop_info_key_31": "dop_info_value",
        "dop_info_key_32": "dop_info_value",
        "dop_info_key_33": "dop_info_value",
        "dop_info_key_34": "dop_info_value"
      },
      {
        "dop_info_key_35": "dop_info_value",
        "dop_info_key_36": "dop_info_value",
        "dop_info_key_37": "dop_info_value",
        "dop_info_key_38": "dop_info_value",
        "dop_info_key_39": "dop_info_value",
        "dop_info_key_40": "dop_info_value",
        "dop_info_key_41": "dop_info_value",
        "dop_info_key_42": "dop_info_value",
        "dop_info_key_43": "dop_info_value"
      }
    ],
    "dop_info_key_44": [
      "dop_info_value",
      "dop_info_value"
    ]
  }
]



https://api-domain/settlements/ - Список населенных пунктов (без meta информации)
json

[
  {
    "id": 1,
    "name": "Вайтран",
    "group": 1,
    "added": "2022-10-10",
    "is_scanning": 0,
    "verified": true
  }
]



Шаги реализации страницы:

1) GET: https://api-domain/groups/ — Получение всех владений
1.1) Рендеринг владений
2) GET: https://api-domain/settlements/ — Получение всех населенных пунктов
?) Информация о населенных пунтках разбита на два эндпоинта
3) Создание строки, которая хранит в себе все id населенных пунктов, полученных ранее, для получения нужных meta данных в 4 шаге
4) POST: https://api-domain/meta-settlements/
5) Склеивание данных из 2 и 4 пункта
6) Рендеринг населенных пунктов

Количество данных:

  • Владения — не больше 8 владений
  • Населенные пункты — 500 пунктов


Сколько я вижу запросов:

  • 1 запрос: Вывод списка Владений
  • 1 запрос: Получение половины данных о населенных пунктов
  • 1 запрос: Получение второй половины данных о населенных пунктов
  • Итого: 3 запроса


На первый взгляд не много. Но один запрос зависит от другого, пока они идут, пользователь ждет. После еще склеивать данные двух запросов.

До этого, для вывода Владений, было три запроса:

Один запрос
https://api-domain/groups/

Два дополнительных на каждое владение
https://api-domain/settlements/
https://api-domain/meta-settlements/

Так как владения, ничего не знали о количестве населенных пунктов, и не знали статистику по армии. Все разделено логически верно же. Сил было потрачено на просьбы переделать это, не оправданно больше чем нужно. И время за которое фронт должен закончен было отнято у меня. Ловушка :)

Я уже себе не доверяю. Описанный мною пример из проекта это норма? Или чего то не понимаю? Я уже думаю проблема во мне...
  • Вопрос задан
  • 298 просмотров
Решения вопроса 1
Krasnodar_etc
@Krasnodar_etc
avito front
Какой толк от логически правильного проектирования бэкенда, если она значительно влияет на скорость загрузки проекта (а значит на пользовательский опыт и сео-метрики) ?
Как вообще понять логическую правильность? Предположим, можно сделать ручку GET https://api-domain/groupsWithSettlements - ручка для "владений, обогащённых информацией о населённых пунктах" - это логически верно?

Разделение сущностей - это хорошо, но оно должно нести в себе смысл, решать какую-то задачу. Допустим, несколько клиентов с разной логикой, которым не всегда нужны полные данные (мобильные приложения, ещё один веб фронт, просто отдаём кому-то API, ...). Причём не гипотетических, а уже запущенных или спроектированных. Если архитектурное решение плохо влияет на проект - это плохое решение, каким бы красивым оно не казалось

Ответ, который вы получаете от заказчика, очень похож на "не мои проблемы". Ну, значит скорость загрузки страницы - не ваши проблемы, вот и всё. Если вам платят и просят сделать плохо - почему бы нет?)
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
dimonchik2013
@dimonchik2013
non progredi est regredi
не связал вопрос и последующую инфу, поэтому на всякий - универсальный ответ

https://dmkpress.com/catalog/computer/web/978-5-97...

ПРОЕКТИРОВАНИЕ ВЕБ-API

АННОТАЦИЯ
API позволяет разработчикам выполнять интеграцию с приложением без детализированного знания кода. Независимо от того, используете ли вы установленные стандарты, такие как REST и OpenAPI, или более новые подходы, например GraphQL или gRPC, освоение разработки API – своего рода суперспособность.
Благодаря ней пользоваться вашими веб-сервисами станет легче, и ваши клиенты – как внутренние, так и внешние – останутся довольны.

Темы, затрагиваемые в книге:
- характеристики правильно разработанного API;
- ориентированные на пользователя и реальные API;
- API и принцип Secure by design;
- изменение API, его документирование и проверка.

Издание предназначено для разработчиков, обладающих минимальным опытом в создании и использовании API-интерфейсов.

есть в телегах, если жалко денег


теперь по вопросу - ввиду игр на мабилах, важно чтобы передаваемых данных было немного,а на число запросов, в общем-то, нас*ть - асинхронщина их пощелкает,
вот из этого и исходи

да, реакту придется сложнее и больше работы - ну а кому щас легко? если не будет данных - игру юзер закроет, вообще ничего с него не выжмите, а интерес надо поддерживать
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы