Спасибо за Ваш комментрий и за найденный баг - обязательно поправим. Нашему продукту 2 месяца и это MVP. Ну и получается им заниматься в свободное от основной работы время. Хабру насколько мне известно лет 10 и это достаточно прибыльный проект, т.е. он может себе позволить иметь тестирование любого уровня.
Попытка зарепортить багу требует логина в GitLab. У меня нет GitLab логина.
Было бы конечно хорошо, если бы в спецификации API можно было бы указать как допустимые параметры запросов, так и список ожидаемых ошибочных ответов. Всё что не в списке — значит проблемы инфраструктуры или баги.
Тут может быть и другой вариант, что обработка для server side rendering и обработка API работают по своему и отдельно. И как раз в server side rendering перехват out of range есть, а API нет.
Но в целом какая разница, ведь и так понятно, что nginx в итоге поместит это в RAM для востребованных запросов и не будет IO с диска. А так тут же статья https://habr.com/ru/post/428127/
Не думал, что примите буквально. +-1 секунда на все 100 запросов имелось ввиду. 2.5ms сюда включен IO между nginx сервером приложений и например memcached?
Слишком много если, вместо простого помещения результата ответа API в статический кэш nginx с супер низкой стоимостью владения. На 100 запросах +-1 секунда не будет заметна, а вот 100 000 вот тогда будет важен каждый лишний запрос на сервер приложений.
Очень жаль, что в инженерной среде когда адекватные аргументы заканчиваются, люди уходят в личные оценки и оскорбления.
Статью я привел как аргумент в пользу nginx как сервера с минимальной стоимостью владения инфраструктурой и метрик его скорости обработки статического контента в который можно загнать кэш ответов API.
На последок ответьте тогда на такой вопрос:
Что будет быстрее и дешевле (управлять и масштабировать) выдать статический кэш с nginx или отправить его на сервер приложений с выдачей из memcache на масштабе 100 000 запросов в секунду?
Но я же писал выполнить требования заказчика на компромисе стоимости реализации, надежности, расширяемости и т.д.
В моей системе я бы спроектировал идеально бизнес-логику и модель данных. Добавить новый ендпойинт, что бы принять или отправить что-то из нее не составило бы труда или нет?
В моей статье было это:
Мне кажется проблема в том, что некоторые бекенд разработчики, неверно понимают разработку бизнес-логики и разработку интерфейса доступа к ней и к данным. Интерфейс на бекенд может быть HTTP, сокеты ли даже командная строка. Это всего лишь интерфейс. Эти разработчики при проектировании ендпойнта /login часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить, например, GraphQL им нужно дублировать код.
Ну так все таки, что будет быстрее и дешевле выдать статический кэш с nginx или отправить запрос на сервер приложений с выдачей из memcache на масштабе 100 000 запросов в секунду?
А этого места нет. Выводы вы сдедали сами, что это подход на все случаи жизни. Я честно говоря, думал, что вы больше прокомментируете :-(
Хотя бы это:
Многие думают, что Swagger (Open API) – это «UI шкурка», которую генерирует в конечном счете бек из кода, они не понимают, что это в первую очередь – JSON схема описания API.
А что не так с аргументом? У библиотек не бывает детских болячек? Сисадминам на настройку разных серверов требуется одинаковое время (включая те сервера, которые настраиваются только кодом)?
Эти аргументы - субъективные оценки, объективные аргументы инженера - это цифры.
Apache пора закопать уже, а не сравнивать с ним nginx.
Вот например я как поставщик продукта и выбрал единственный приемлемый для себя ( тот за работу и актуальность которого я готов отвечать головой)
Очень странное для себя. Разве не задача любого исполнителя выполнить требования заказчика на компромисе стоимости реализации, надежности, расширяемости и т.д.
Как вы считаете по стоимости масштабирования: дергать 2 запроса с бэка вместо одного для отображения одного UI блока на фронте - это дешевле или дороже, чем просто реализовать это в API для фронта? Или дешевле сделать промежуточный сервис который в итоге все равно дернет API 2 раза, но на фронт вернет это одним ответом? В итоге в системе будет один промежуточный узел со всеми вытекающими проблемами типа кэширования, сложных выборок из базы данных и т.д.
Как вы считаете, а так будет лучше для Вас как для бэка?
Если фронтенд достаточно грамотен, чтобы сам написать Swagger-спецификацию - я выйду из дома, сяду в автобус, доеду до его офиса, поднимусь на нужный этаж и поцелую его в сахарные уста. А потом доеду обратно, сяду и напишу бэк, который будет отдавать именно то что нужно.
И бэку не нужно залезать в Фигму, лазить по экранам, разбираться во всей UX/UX специфике приложения.
Ну так все таки, что будет быстрее и дешевле выдать статический кэш с nginx или отправить его на Python с выдачей из memcache на масштабе 100 000 запросов в секунду?
На каждый мой комментарий - минус, хотя ни в одном из них я не позволял себе аргументов типа:
детские болячки и привычный инструмент сисадмина
Не ужели в инженерной среде такие аргументы имеют место?
nginx - стал популярен из-за в первую очередь снижения стоимости владения инфраструктурой.
Возьмите статью по оценке производительности nginx
Static Content. NGINX performs 2.5 times faster than Apache according to a benchmark test performed by running up to 1,000 simultaneous connections. Another benchmark running with 512 simultaneous connections, showed that NGINX is about twice as fast and consumed less memory.
Отличная статья! У меня тоже был разбор ошибки в API хабра тут https://habr.com/ru/post/647957/
Спасибо за Ваш комментрий и за найденный баг - обязательно поправим. Нашему продукту 2 месяца и это MVP. Ну и получается им заниматься в свободное от основной работы время. Хабру насколько мне известно лет 10 и это достаточно прибыльный проект, т.е. он может себе позволить иметь тестирование любого уровня.
Подумаем перенести на GitHub.
Спасибо!
Конечно такое можно https://swagger.io/docs/specification/describing-responses/
Тут может быть и другой вариант, что обработка для
server side renderingи обработка API работают по своему и отдельно. И как раз вserver side renderingперехватout of rangeесть, а API нет.Тут используется
server side rendering, вызова API/articlesнет.Но в целом какая разница, ведь и так понятно, что
nginxв итоге поместит это в RAM для востребованных запросов и не будетIOс диска. А так тут же статья https://habr.com/ru/post/428127/Так это просто оценка скорости запроса в БД и все? Это не скорость обработки HTTP запроса с конечной выдачей ответа? Это очень разные вещи, очень.
Не думал, что примите буквально. +-1 секунда на все 100 запросов имелось ввиду.
2.5msсюда включенIOмеждуnginxсервером приложений и напримерmemcached?Слишком много если, вместо простого помещения результата ответа API в статический кэш
nginxс супер низкой стоимостью владения. На 100 запросах +-1 секунда не будет заметна, а вот 100 000 вот тогда будет важен каждый лишний запрос на сервер приложений.Спасибо за дискуссию, за кашу обидно :-) Это же личностные оценки, что в инжеренной среде мне кажеться не уместно.
Очень жаль, что в инженерной среде когда адекватные аргументы заканчиваются, люди уходят в личные оценки и оскорбления.
Статью я привел как аргумент в пользу
nginxкак сервера с минимальной стоимостью владения инфраструктурой и метрик его скорости обработки статического контента в который можно загнать кэш ответов API.На последок ответьте тогда на такой вопрос:
Но я же писал выполнить требования заказчика на компромисе стоимости реализации, надежности, расширяемости и т.д.
В моей системе я бы спроектировал идеально бизнес-логику и модель данных. Добавить новый ендпойинт, что бы принять или отправить что-то из нее не составило бы труда или нет?
В моей статье было это:
Ну так все таки, что будет быстрее и дешевле выдать статический кэш с
nginxили отправить запрос на сервер приложений с выдачей изmemcacheна масштабе 100 000 запросов в секунду?А этого места нет. Выводы вы сдедали сами, что это подход на все случаи жизни. Я честно говоря, думал, что вы больше прокомментируете :-(
Хотя бы это:
Эти аргументы - субъективные оценки, объективные аргументы инженера - это цифры.
И снова субъективная оценка. Давайте закопаем сервер который работает сейчас на 33% серверов в Интернете https://w3techs.com/technologies/comparison/ws-apache,ws-nginx
Снова минус? Хоть за что? За цифры? Мне просто интересна позиция инженера с такой кармой.
Очень странное для себя. Разве не задача любого исполнителя выполнить требования заказчика на компромисе стоимости реализации, надежности, расширяемости и т.д.
Как вы считаете по стоимости масштабирования: дергать 2 запроса с бэка вместо одного для отображения одного UI блока на фронте - это дешевле или дороже, чем просто реализовать это в API для фронта? Или дешевле сделать промежуточный сервис который в итоге все равно дернет API 2 раза, но на фронт вернет это одним ответом? В итоге в системе будет один промежуточный узел со всеми вытекающими проблемами типа кэширования, сложных выборок из базы данных и т.д.
Не подскажите что формат описания?
Как вы считаете, а так будет лучше для Вас как для бэка?
И бэку не нужно залезать в Фигму, лазить по экранам, разбираться во всей UX/UX специфике приложения.
Ну так все таки, что будет быстрее и дешевле выдать статический кэш с
nginxили отправить его наPythonс выдачей изmemcacheна масштабе 100 000 запросов в секунду?На каждый мой комментарий - минус, хотя ни в одном из них я не позволял себе аргументов типа:
Не ужели в инженерной среде такие аргументы имеют место?
nginx- стал популярен из-за в первую очередь снижения стоимости владения инфраструктурой.Возьмите статью по оценке производительности
nginxЭто аргумент?