в целом та же проблема декомпозиции стэйта. "есть табличка юзеров и у него 100 полей"

Ну что-то хз на каждое поле делать отдельный ресурс. Бизнес операция же одна - обновить свойства объекта. Возможно что PATCH ломает головы когда нужно сделать что-то типа lock - и тут возникает желание сделать его тоже патчем )))

хз, мен всегда пугает весь этот роутинг на основе данных запроса. Ну и в целом если у тебя "бизнес операция это прям обновить свойство" то тут достаточно обертки)

Всегда у всего есть свойства которые время от времени кто-то хочет поменять )))

у меня просто за 10 лет что я апишки делаю вот кейса для patch особо небыло

Ок, это такой разговор ни о чем. Мне в целом нравится подход что patch вам не нужен, а потом когда человек денёк помучается и придёт с вопросом - ну как это сделать ты и скажешь - ну ладно, есть ещё PATCH для подобного)))

хз для меня желание заюзать PATCH это признак какой-то кривой декомпозиции. Либо кривая декомпозиция либо "нахер тебе вообще свою апишку писать - возьми любой готовый тул который апишку поверх базы генерит"

ну вот буквально либо "примитивный круд без проблем" либо "у тебя там явно это разные ресурсы которые ты в одного юзера слепил"

у людей просто "ресурс = табличка в базе". Даже когда это явно не так

потому что они идут с другого конца обычно и все фреймворки так устроены - ресурс = табличкак в базе

может стоит нормальные фреймворки юзать?)

спорное утверждение - влезать в этот спор я конечно же не буду ))

Это какие?

которые не заставляют UI на базу накладывать

если честно - буквально все не заставляют, потому мне не оч понятно про какие "все фреймворки" речь шла

может речь идет про "все конкретные ориентированные на быстро склепать апи поверх базы"...

В голове держал Rails, но подозревая что так во многих MVC

Ну слово все там лишнее вероятно - да )))

Ребят, есть задача - дать кнопку клиенту "скачать все картинки товаров архивом" (B2B e-commerce).
Картинки храним на s3, Backend на Django.

Моим логическим решением было не задействовать бэкенд в этой задаче, т.к. тогда возникают проблемы - когда этот архив генерировать, сколько его хранить и т.д. - сделали на фронтенде. Сейчас говорят - чёто медленно.
Единственный способ ускорить я так понимаю - это делать архивы заранее на бекенде/с3 и их там держать уже готовыми?
+ Заказ может измениться. Выскажите мнения)

Какие полюсы даёт архивирование на клиенте? Вот минусы такого подхода:
1. Когда добавите новый клиент, там тоже нужно будет реализовывать архивирование.
2. Невозможность докачки, скачивания в несколько потоков.
3. Нельзя дать доступ к скачиванию архивов через API.

Чтобы дать ответ как это делать на сервере, нужно знать от чего зависит список файлов, средний размер файла и т. д.