Нужно. В одном случае сервис спокойно упадет с 500кой (ну или как-то обработает ошибку, зная что это нештатная ситуация), а в другом будет выполнена бизнес-логика для случая когда объекта не существует.
Как? Баг есть. Админ роут перепутал. У вас 404. Что делать будете?
500тить, например. Это частичная неработоспособность системы. Плюс к этому на 500ки последует очень быстрая реакция. А в том что предлагаете вы из-за инфраструктурной проблемы каскадно начнет неправильно вести себя бизнес-логика. Получив 500ку я сразу по логам могу установить, что ее причиной было 404 от другого сервиса. А в вашем кейсе сломается логика, но никаких признаков что что-то идет не так не будет
Вообще не учитывается админами. Это крайне распространенный штатный ответ. Разве, что наложены правила на алерты по 404.
Там где 404 не используют как нормальный респонс, конечно, накладывают такие правила для алертинга
Об этом должны говорить интеграционные тесты. Регулярные. Мониторинг.
Роут может сломаться в любой момент, уже после прогона интеграционных тестов. А вот с мониторингом опять та же самая проблема, что мы не знаем в каких кейсах 404 это ожидаемое поведение, а в каких-нет.
Ну насчет использования именно 410 я не уверен. Но в любом случае это лучше 404 и позволит эти два состояния отличать. Если конечно есть гарантия, что никто другой между клиентом и сервером не может вернуть такой же статус
Вообще-то как раз сможет, хотя не должен. Кейсы могут быть разные от не критичных до очень критичных, которые могут выливаться в реальные финансовые/репутационные потери для бизнеса. Странно, что вы этого не понимаете.
Проблема то где?
Собственно в потенциальных багах, которые были бы невозможны в случае если 404 не будет являться ожидаемым респонсом.
Вы уперлись в свою тантру и не хотите понять простого — вы не контролируете вообще ответ, который получите.
Я не понял как это связано с обсуждаемое темой. Мы обсуждаем два варианта:
1. Когда мы можем отличить два состояния «ошибка роутинга» и «объект не существует»
2. Когда мы не можем отличить эти два состояния
2-ой вариант может приводить к багам, пример которых я привел, причем такие баги не всегда просто будет обнаружить. В 1-ом варианте эти баги исключены. К тому же если 404 не считается ожидаемым респонсом, то появление респонсов с таким статусом в логах приводит в срабатыванию алертов и более быстрой реакции на то, что, например, какой-то endpoint исчез
Это плохая бизнес-логика, если она может на этом строиться.
Что значит плохая бизнес-логика? Что вы будете делать, если в бизнес-логике предусмотренны разные сценарии в зависимости от того существует объект или нет?
К каким серьезным багам будет приводить? Поясните.
Я же специально выше привел конкретный пример. В данном случае произойдет неправильное определение пермишена пользователя, т.е. сможет залогиниться тот, кто на это не имеет право.
Да и вообще примеров можно много привести. Любой кейс когда от существования объекта зависит логика. Например, могут удаляться связанные с этим объектом сущности
Очень большая разница. На этом может строиться бизнес-логика. И поэтому важно отличать эти два состояния. Представьте что какой-то сервис делает запрос в другой сервис GET /api/banned-users/15/
И на основании ответа решает разрешить ли пользователю логин или нет. Если опираться только на статус 404, то в любая непредвиденная ситуация (сломался роутинг, опечатились в адресе апи в коде, эту апи вообще удалили) будет приводить к серьезным багам в бизнес-логике.
Да, обойтись можно без чего угодно. Однако практика показывает, что во всех зрелых языках они есть, ибо есть задачи которые константы решают. Если нет констант — нет для этих задач предназначенного инструмента.
Большинство этих зрелых языков, в которых есть константы являются статически типизированными и проверка на переопределение констант происходит на этапе компиляции, что значительно лучше чем проверка в рантайме. Вот Final, который я кидал выше способ сделать константу проверяемую на этапе статического анализа. Ну и получается что Lua и Ruby недостаточно зрелые?
И в том, что при запуске и в рантайме, питон не пикнет даже если будут несоответствие типов (частая проблема при использовании сторонних пакетов, где pypy не поможет ввиду отсутствия тайпхинтинга в этих самых сторонних пакетах ).
Да, пока далеко не во всех библиотеках есть тайпхинты. Но это же не проблема системы типов питона. Со временем тайпхинты будут появляться все в большем кол-ве библиотек. В любом случае ставить тайпхинты в минус питону, когда в php все гораздо примитивнее и вообще не позволяет делать хоть какой-то вразумительный статический анализ, довольно странно.
Речь про то, что питон диктует так делать (проблема циклического импорта) и устоявшаяся практика. Посмотрите на models.py в django любого сложного проекта.
Мне кажется, вы преувеличиваете проблему циклических импортов. Почти во всех проектах на django, которые я видел models был разбит на packages/modules
В необходимости писать тип в виде строки вместо непосредственно литерала, если импортировать тип нельзя из-за проблемы циклического импорта.
Опять же, проблема, мне кажется немного преувеличенной, но тем не менее начиная с Python 3.7 это уже не проблема: www.python.org/dev/peps/pep-0563
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк.
Для каких-то вещей это даже хорошо. Как правило release cycle языка сильно длиннее чем у библиотеки/фреймворка, что позволяет добавлять новые фичи/фиксить баги гораздо оперативнее не дожидаясь релиза новой версии языка.
И оно понятно, обработка http — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.
И что в этом плохого? Как это мешает разработчику?
Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.
Можете привести пример такого кода в вашем проекте?
Не очень понятно зачем у вас модели принимают dict, а не конкретные атрибуты. Это же, по-сути, делает невозможным проверку такого кода статическим type-checker'ом, если только в конструкторе модели не указан тип TypedDict
возникает такое ощущение, что в 2019 году FaaS-платформы могут стать основой для серьёзных проектов. Могут ли эти платформы конкурировать с Kubernetes и использоваться для хостинга больших приложений?
Не стесняйтесь использовать в тестах зависимости. В этом нет ничего плохого. Если вы подняли memcached, потому что без него ваш код нормально не функционирует, ничего страшного.
Почему нельзя просто замокать обращение к memcached? Если это в каком-то месте сложно сделать, то, кажется, это проблема в качестве тестируемого кода
Заметим, что SEC (как бы) решает проблему CAP теоремы: все три свойства выполняются.
Не выполняются. Consistency в контексте CAP-теоремы подразумавает, что при чтении мы всегда получаем последние (актуальные) данные. В случае с EC (как и SEC) это условие не выполняется.
Нужно. В одном случае сервис спокойно упадет с 500кой (ну или как-то обработает ошибку, зная что это нештатная ситуация), а в другом будет выполнена бизнес-логика для случая когда объекта не существует.
500тить, например. Это частичная неработоспособность системы. Плюс к этому на 500ки последует очень быстрая реакция. А в том что предлагаете вы из-за инфраструктурной проблемы каскадно начнет неправильно вести себя бизнес-логика. Получив 500ку я сразу по логам могу установить, что ее причиной было 404 от другого сервиса. А в вашем кейсе сломается логика, но никаких признаков что что-то идет не так не будет
Там где 404 не используют как нормальный респонс, конечно, накладывают такие правила для алертинга
Роут может сломаться в любой момент, уже после прогона интеграционных тестов. А вот с мониторингом опять та же самая проблема, что мы не знаем в каких кейсах 404 это ожидаемое поведение, а в каких-нет.
Вообще-то как раз сможет, хотя не должен. Кейсы могут быть разные от не критичных до очень критичных, которые могут выливаться в реальные финансовые/репутационные потери для бизнеса. Странно, что вы этого не понимаете.
Собственно в потенциальных багах, которые были бы невозможны в случае если 404 не будет являться ожидаемым респонсом.
Я не понял как это связано с обсуждаемое темой. Мы обсуждаем два варианта:
1. Когда мы можем отличить два состояния «ошибка роутинга» и «объект не существует»
2. Когда мы не можем отличить эти два состояния
2-ой вариант может приводить к багам, пример которых я привел, причем такие баги не всегда просто будет обнаружить. В 1-ом варианте эти баги исключены. К тому же если 404 не считается ожидаемым респонсом, то появление респонсов с таким статусом в логах приводит в срабатыванию алертов и более быстрой реакции на то, что, например, какой-то endpoint исчез
Что значит плохая бизнес-логика? Что вы будете делать, если в бизнес-логике предусмотренны разные сценарии в зависимости от того существует объект или нет?
Я же специально выше привел конкретный пример. В данном случае произойдет неправильное определение пермишена пользователя, т.е. сможет залогиниться тот, кто на это не имеет право.
Да и вообще примеров можно много привести. Любой кейс когда от существования объекта зависит логика. Например, могут удаляться связанные с этим объектом сущности
GET /api/banned-users/15/И на основании ответа решает разрешить ли пользователю логин или нет. Если опираться только на статус 404, то в любая непредвиденная ситуация (сломался роутинг, опечатились в адресе апи в коде, эту апи вообще удалили) будет приводить к серьезным багам в бизнес-логике.
Большинство этих зрелых языков, в которых есть константы являются статически типизированными и проверка на переопределение констант происходит на этапе компиляции, что значительно лучше чем проверка в рантайме. Вот Final, который я кидал выше способ сделать константу проверяемую на этапе статического анализа. Ну и получается что Lua и Ruby недостаточно зрелые?
Да, пока далеко не во всех библиотеках есть тайпхинты. Но это же не проблема системы типов питона. Со временем тайпхинты будут появляться все в большем кол-ве библиотек. В любом случае ставить тайпхинты в минус питону, когда в php все гораздо примитивнее и вообще не позволяет делать хоть какой-то вразумительный статический анализ, довольно странно.
Мне кажется, вы преувеличиваете проблему циклических импортов. Почти во всех проектах на django, которые я видел models был разбит на packages/modules
Опять же, проблема, мне кажется немного преувеличенной, но тем не менее начиная с Python 3.7 это уже не проблема: www.python.org/dev/peps/pep-0563
Для каких-то вещей это даже хорошо. Как правило release cycle языка сильно длиннее чем у библиотеки/фреймворка, что позволяет добавлять новые фичи/фиксить баги гораздо оперативнее не дожидаясь релиза новой версии языка.
И что в этом плохого? Как это мешает разработчику?
Можете привести пример такого кода в вашем проекте?
Не особо нужно, но оно есть в виде тайпхинта: mypy.readthedocs.io/en/latest/final_attrs.html
Все прекрасно обходятся без них
Какое это имеет отношение к ЯП. В других языках нельзя что ли простыню сделать?
В чем ее мутность? В Python нормальная система типов, в отличии от велосипеда с квадратными колесами в PHP7
В чем заточенность? В том что у php даже event loop'а из коробки нет?
Не очень понятно зачем у вас модели принимают dict, а не конкретные атрибуты. Это же, по-сути, делает невозможным проверку такого кода статическим type-checker'ом, если только в конструкторе модели не указан тип TypedDict
В mypy_extensions есть для этого способ: mypy.readthedocs.io/en/latest/additional_features.html#extended-callable-types
Довольно странно читать про выбор асинхронного фреймворка на основе его производительности, но не встретить упоминания sanic, stralette, vibora и т.п.
Смешались в кучу кони, люди.
Почему нельзя просто замокать обращение к memcached? Если это в каком-то месте сложно сделать, то, кажется, это проблема в качестве тестируемого кода
Работает в том числе и на python 2.7
Это как? У вас в проде постоянно несколько бранчей задеплоено? Серьезно?
Странное название версий. И что вы делаете с клиентами, которые используют stable и вы хотите ваш prestable сделать stable?
Вы путаете unit-тесты и интеграционные тесты. Они должны не заменять друг друга, а дополнять.
Как уже заметили выше, обычно swagger-схема генерируется автоматически. Т.ч. к недостаткам это можно отнести с натяжкой
Не выполняются. Consistency в контексте CAP-теоремы подразумавает, что при чтении мы всегда получаем последние (актуальные) данные. В случае с EC (как и SEC) это условие не выполняется.