Я фронтенд разработчик, а не обезьянка

Это не так, вся статья пронизана, что фронты-вносят предложения, а бэк согласовывает.

Я фронтенд разработчик, а не обезьянка

А как же тогда сказать бэку, что вам от него нужно? Чаты? JSON-чики?

Я фронтенд разработчик, а не обезьянка

Спасибо за поддержку, именно это я и хотел донести для тех кто прочитает статью полностью.

Я фронтенд разработчик, а не обезьянка

А коммуникация в чатах с JSON-чиками?

Я фронтенд разработчик, а не обезьянка

Спасибо за комментарий. Разрешите привести в качестве аргумента https://swagger.io/tools/swaggerhub/

The Single Source of Truth for API Development

Join thousands of teams who depend on SwaggerHub to get their products to market, faster 100k+ API Practitioners, 40k+ Organizations, 200k+ API Projects

Складывается ощущение, что на текущий момент такой подход просто еще не пришел на Хабр.

Я фронтенд разработчик, а не обезьянка

Спасибо за развернутый комментарий.

Но мне несколько странно, что Вы написали:

Мне лично кажется, что у вас в голове каша из множества различных областей процессов разработки и управления. Попробую систематизировать и предложить примеров.

Ведь в моей статье был тезис про разделение слоя бизнес-логи и API.

@breslavsky Мне кажется проблема в том, что некоторые бекенд разработчики, неверно понимают разработку бизнес-логики и разработку интерфейса доступа к ней и к данным. Интерфейс на бекенд может быть HTTP, сокеты ли даже командная строка. Это всего лишь интерфейс. Эти разработчики при проектировании ендпойнта /login часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить, например, GraphQL им нужно дублировать код.

Пожалуйста, производитель создал слой бизнес-логики. API - слой общения с ней.

Я как отдельный класс потребителя web-приложение требую выдать последние комментарии с Reddit оставленные пользователями в нерабочие дни в USA, потому-что продуктологи хотят сделать тест на новую фичу. Другие внешние системы которые сейчас тоже запрашивают API с Reddit врядли, когда-либо потребуют такой ендпойнт.

Где тут проблема?

Я фронтенд разработчик, а не обезьянка

Что я предлагал? Я лично ничего не придумал. Есть Swagger - Spec-First - не я это придумал. Я лишь, описал как хорошо писать спецификации на API заранее или нет?

Причем тут ограниченность архитектур?

Напишите контракты, выполните их, проверьте, что все выполнено - разве не хорошо?

Я фронтенд разработчик, а не обезьянка

Потому-что это дополнительный IO между nginx и сервером приложений, потом между сервером приложений и memcache.

Я фронтенд разработчик, а не обезьянка

Да я согласен, но дополнительный IO требуется для передачи от nginx до uWSGI? Для масштабирования требуется запуск новых воркеров? Жедательно воркеров на разных машинах. Значит их нужно запускать - это ведь дороже в конечном счете чем кэш на nginx. Или нет?

Я фронтенд разработчик, а не обезьянка

Это самый популярный язык программирования в мире. Плох он или хорошо - это предмет отдельной дискуссии.

Я фронтенд разработчик, а не обезьянка

Вы не заметили разницы из-за моего недочета - сорри (get параметр не используется больше), у нас кэш нужно отключить через localStorage, вот видео в подтверждение.

По поводу 12 мегабайт ресурсов - то перед вами SPA приложение, которое лениво загружается к вам в браузер и это не значит, что для его работы требуются весь объем - оно кешируется на случай вашего серфинга по нему.

Задите пожалуйста на youtube.com и Вы увидите 12.6 мегабайт загруженных ресурсов - разве это может быть аргументом в неправильной архитектуре?

На платформе проводяться онлайн конференции для докторов с нагрузкой порядка 5 тыс. онлайн пользователей, и если каждый запрос перенаправлять на сервер приложений для обработки Python это становится проблемой. В моем примере nginx выдает ответ в 3-5 раз быстрее, чем Python из memcache - это факт.

Python - прекрасный и самый популярный язык программирования в мире. На нем быстро писать из коробки, но изначальная дискуссия была вообще в другом - в кешировании graphql. Проблема, в том, что, если можно выдать данные из nginx - их лучше выдать оттуда, перенаправление на сервер приложений не может быть быстрее - это тоже факт. В случае с graphql сделать кэш на nginx становиться сложнее, т.к. все запросы по сути это POST с телом с миксом фетчинга и мутаций.

Я фронтенд разработчик, а не обезьянка

Вы меня минусуете просто так? :-)

Вот реальный пример, правда, я хочу предугадать Ваш следущий комментарий: вы неверно все настроили вот у вас и такая ситуация. Настроено верно, долго эксперементировали со всем чем можно.

Один из наших проектов https://www.esanum.de/

Смотрим ендпойнт /api/apps/current/feeds/today/posts?page=1&page_size=14...

C кэшированием nginx ответ 77ms x-cache-status: HIT

Отключеаем кэш https://www.esanum.de/?no-cache=1

C memcache там же 522 ms x-cache-status: BYPASS

Как видим разница в 5-8 раз. И тут в целом все очевидно. Воркеры требуют дополнительных ресурсов. Nginx выдаст это как обычный статический файл.

Долго делали эксперименты c Python касаемо производительности, сверяли с GoLang и т.д. Python - тормозит :-) Жду Ваших минусов.

Я фронтенд разработчик, а не обезьянка

Я единственно, правда не совсем понимаю, почему многие пишут и комментируют статью в отрыве от самого текста? Почему нельзя взять любой тезис и на него написать комментарий.

Я писал про Spec-First именно (для этого и был сделан Swagger / Open API) про то, как можно согласовать требования заранее к API без "чатиков" и "JSON-чиков", вопрос был только в этом.

Я фронтенд разработчик, а не обезьянка

Вопрос то ведь был поставлен так и никаки иначе:

Как считаете будущее за Spec-First Development или полный Agile (шутка): митинги, JSON-чики в чатиках и т.д.?

Разве это не для того, что бы обеспечить взаимопонимания? Вы как считаете?

Я фронтенд разработчик, а не обезьянка

Потому-что воркер очевидно требует больше ресурсов для запуска и работы, даже если в вашем коде Вы просто забираете данные из memcache например. И Ваш ответ не будет занимать 10 миллисекунд как при nginx кеше, а все 50-100 минимум.

Я фронтенд разработчик, а не обезьянка

Вот отличная статья https://www.nginx.com/blog/nginx-caching-guide/

На хабре я бы закэшировал https://habr.com/kek/v2/inset/vacancies, а когда нужно сбросил бы кэш на nginx для этого урла.

Кэш на nginx очень дешевый, по сути это статика в памяти. nginx легко выдержит тысячи и десятки тысяч таких запросов без какого-либо масштабирования.

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

Я фронтенд разработчик, а не обезьянка

Как обмениваетесь этой документацией?

Я фронтенд разработчик, а не обезьянка

Это верно, вопрос только в скорости кэша в этоге.

Я фронтенд разработчик, а не обезьянка

Как решаете проблемы с кэшированием в GraphQL? REST легко закэшировать на уровне nginx искользуя в качестве ключа URL. GraphQL все запросы шлются через POST при этом в одном запросе могут комбинироваться как фетчи так и мутации вместе.