а
а тоесть я получаю не id процесса а id потока на возврате?
именно
Size: a a a
2020 February 20
PT
епт спс
A
Клиенту не пофиг ли, что именно не существует, если он просил пост. Поста нет. Ему этого достаточно. А чего именно нет - это уже вообще не в кассу вопрос. Захочет узнать, есть ли пользователь - пусть дёргает ресурс пользователя, а не поста.
ну, обычно совсем много "ручек" не плодят. могут возвращать и кучу данных в одной, ради производительности
S
ну, обычно совсем много "ручек" не плодят. могут возвращать и кучу данных в одной, ради производительности
Вот как раз ради производительности лучше иметь много ручек, возвращающих строго то, что запрошено. А вот такие ручки, которые возвращают всё, до чего дотянутся, обычно делаются из-за лени
A
Вот как раз ради производительности лучше иметь много ручек, возвращающих строго то, что запрошено. А вот такие ручки, которые возвращают всё, до чего дотянутся, обычно делаются из-за лени
Нет, не из-за лени. К примеру, у нас огромное количество статистики на главной странице. Чтобы клиент не дёргал 40 методов API, он дёргает один, который возвращает один ответ. Внутри бек просто собирает из сервисов этот ответ и это не выглядит как дублирование кода В результате главная страница грузится практически моментально.
Подробнее эта статистика отображается на других компонентах и там используются другие контроллеры. Хотя можно всё это сделать универсальным и собрать API так, чтобы фронт дёргал просто 1000 ручек, чтобы собрать всю нужную статистику. Но у нас компонентный подход.
Подробнее эта статистика отображается на других компонентах и там используются другие контроллеры. Хотя можно всё это сделать универсальным и собрать API так, чтобы фронт дёргал просто 1000 ручек, чтобы собрать всю нужную статистику. Но у нас компонентный подход.
C
но зачем?
~
@floodcode зачем тут = ?
A
Нет, не из-за лени. К примеру, у нас огромное количество статистики на главной странице. Чтобы клиент не дёргал 40 методов API, он дёргает один, который возвращает один ответ. Внутри бек просто собирает из сервисов этот ответ и это не выглядит как дублирование кода В результате главная страница грузится практически моментально.
Подробнее эта статистика отображается на других компонентах и там используются другие контроллеры. Хотя можно всё это сделать универсальным и собрать API так, чтобы фронт дёргал просто 1000 ручек, чтобы собрать всю нужную статистику. Но у нас компонентный подход.
Подробнее эта статистика отображается на других компонентах и там используются другие контроллеры. Хотя можно всё это сделать универсальным и собрать API так, чтобы фронт дёргал просто 1000 ручек, чтобы собрать всю нужную статистику. Но у нас компонентный подход.
Можно сказать, что это решение некой интерпретации N+1 проблемы.
p
В gcloud/rackspace/aws нет проблем
Хорошо, когда нет проблем :)
Но чем меньше кастома и отличий от типичного http в вебе - тем меньше шансов наткнуться на особенности реализации или корнеркейс.
Но чем меньше кастома и отличий от типичного http в вебе - тем меньше шансов наткнуться на особенности реализации или корнеркейс.
S
Нет, не из-за лени. К примеру, у нас огромное количество статистики на главной странице. Чтобы клиент не дёргал 40 методов API, он дёргает один, который возвращает один ответ. Внутри бек просто собирает из сервисов этот ответ и это не выглядит как дублирование кода В результате главная страница грузится практически моментально.
Подробнее эта статистика отображается на других компонентах и там используются другие контроллеры. Хотя можно всё это сделать универсальным и собрать API так, чтобы фронт дёргал просто 1000 ручек, чтобы собрать всю нужную статистику. Но у нас компонентный подход.
Подробнее эта статистика отображается на других компонентах и там используются другие контроллеры. Хотя можно всё это сделать универсальным и собрать API так, чтобы фронт дёргал просто 1000 ручек, чтобы собрать всю нужную статистику. Но у нас компонентный подход.
Это скорее случай-исключение - всякая статистика и дашборды - это отдельная тема. Хотя и тут я почти уверен, 40 методов были бы быстрее, чем один жирный.