VF
РПЦ православное
Size: a a a
2021 November 16
S
Ну....с одной стороны хочецца дать клиенту все, что он попросит в рамках привилегий, а с другой он может попросить чего-то, что будет очень долго считаться. Поэтому, получается, если сразу ему крылья подрезать - можно сэкономить на железе. А если прибежит возмущенный - пусть платит.
AB
Спасибо друзья за дискуссию, получается, вывод такой. 0,00001% пишу сваггер и дают его на бэк. 99% пишут код сразу на беке и генерят сваггер для фронта. Что есть, используйте. Чего нет, пишите сделаем.
AB
Ну потому и идет речь про BFF. Если в апи есть условно метод поиска и он возвращает 100 результатов и на каждый нужно отдельно сходить в апи чтобы получить пользователя, то как раз в апи напишут метод с агрегацией, который с результатами поиска вернет и данные пользователей, как оптимизация. Но это не апи под экраны, хоть и по сути такой метод может исподльзоваться на конкретном экране
AB
Пытаются оптимизировать деятельность. Если у меня легко и просто из контракта на беке сходу генерится json open api, то непонятно зачем мне отталкиваться от ручного написания, тем более что при сборке бекэнд мне из конрактов соберет _актуальный_ сваггер, а не нарисованный в доках
VF
Надо кусок сервера, где фронты смогут себе ваять все что захотят, но только из готовых методов
AB
И поддержку пользователей, которые будут жаловаться на медленную работу приложения - тоже им
VF
Ну это же легко протестить
VF
Тесты тоже пусть пишут, офулстечиваются таксказать
AB
Тогда, бекенд API собираете из ТЗ, ему по сути ему дизайн приложения не нужен?
AB
Похоже на необходимость тестирования того что будет, если лизать розетку, ведь нам толькол в теории известно что будет %)
VF
А бэков отправить РПЦ делать на фронт, все при деле
PD
Я даже не про это.
Вот тут у знакомых дизайнер для онбродинга вместо нормального визарда решил нарисовать чат.
И если следовать этой идее, то у тебя UX начинает очень сильно влиять на модель обмена с сервером (т.е. вместо обычного CRUD у тебя сразу асинхронный чатбот и вот это все).
Проще, конечно, стукнуть дизайнера по голове Клеппманом и сделать как обычно.
Вот тут у знакомых дизайнер для онбродинга вместо нормального визарда решил нарисовать чат.
И если следовать этой идее, то у тебя UX начинает очень сильно влиять на модель обмена с сервером (т.е. вместо обычного CRUD у тебя сразу асинхронный чатбот и вот это все).
Проще, конечно, стукнуть дизайнера по голове Клеппманом и сделать как обычно.
VF
И сбросить в бергшрунд
AB
Я не смог понять, сорри. Надо клиенту (фронту или айос разрабу или кто там) вместе с беком согласовывать что и кому нужно. Если беку легко из тз понятно какое апи наваять - плохо разве?
PD
Кстати, да.
Я как раз и просил фронтов писать свои методы на bff (на заглушках), бэк потом подправлял.
Но у меня фронтлид был умный и опытный и понимал и про БД и про транзакции.
Я как раз и просил фронтов писать свои методы на bff (на заглушках), бэк потом подправлял.
Но у меня фронтлид был умный и опытный и понимал и про БД и про транзакции.
AB
Ну да, на какой стороне экспертиза есть, та и может без проблем ваять контракты
VF
Ну вот да, если интерфейсы особо никто делать не умеет, то тут только взаимное опыление
AB
Тогда все зависит от ТЗ и его потом синхронизации с дизайном.
AB
Ну если я открываю ТЗ и вижу описание страницы поиска, вижу фильтры, вижу данные которые нужно рендерить - я понимаю какое апи можно сделать