а ещё сисадмины, если пользователь говорит что это хрень собачья, которая не хрена не работает, делают так как хочет пользователь, а не говорят ему что он сам криворукий, а тут типо работает и я не трогаю (а те кто говорит плохо заканчивают).
Но суть не в этом. Речь шла не о том понятна ли работа ИИ, а о том что если ИИ насоздаёт непонятных математик и прочего что вами упоминалась, то никто не придёт от этого в восторг. Т.е. если вы попросите как тут упоминается написать какой-то кусок кода, а в ответ вам чатжопагде выдасть набор каких-то непонятных символов (т.е. типо саздаст новый ЯП и выдаст вам код на нём), то вы не скажете круто, это работает, поэтому погнали это в прод. Вы скорее всего засрёте этот чатвжопевсе и статью на хабре ещё напишите какой жпте беспонтовый ваще... И если его и не сотрут буквально, и может даже фирма не разорится, но такую выдачу ответов пресекут и вернут в область понятного для того кто пользуется этим.
Если этот ИИ непонятным образом решает какие-то проблемы, ни кто его не сотрет и дадут все ресурсы.
Понятно. Вы о каком то воображаемом ИИ, который "управляет каждым атомом во вселенной". Но такой ИИ не будет создан именно потому что критерии для развития этого ИИ задаёт череловек, а ему нужно чтобы результат работы ИИ был ему понятен, а не просто "трах ти бы дох, пиау пиау". И то что не понятно человеку, он стирает и делает то что ему понятно.
Кажется на этот счёт уже сказал один учёный, что такой ИИ примут за не рабочий и сотрут, ибо нафига ИИ который генерирует то что невозможно понять. А сам он ничего реализовать пока не сможет.
кстати, именно так сделаны все веб-серверы на php.
Есть http сервер (nginx/apache/и т.п.) и есть php-fpm. И они друг другу передают данные по порту. И кстате это делается без сериализации (в обоих случях).
Что это даёт? это даёт изолированность частей, и как тут очень любят поминать, избаляет от лишних зависимостей. Т.е. я могу поменять apache на nginx или на caddy (go) и мне не придётся что-то менять на стороне php.
Относительно такого разделения на уровне php могу привести пример докер проекта где апи, админка и фронт разделены на два/три разных докер контейнера (помимо прочего). И общаются между собой по докер сети. Что это даёт. ну это даёт то, что вы можете в админке установить только те зависимости, которые нужны в админке, а в апишке установить те, что нужны в ней и не перемешивать их между собой. кроме того сам код можноно релизить относительно независимо. И вообще, как я приводил пример с системным администрированием, вы можете контроллер домена, ДНС, FTP, фийловый сервер, сервер печати поместить на один сервер, а можете растощить по разным. И такая организация кода позволяет это сделать.
Фраза про недостаток "недостатка мыслительной деятельности" была не уместна.
80% интернета всё ещё сделано на php, а это значит, что используется, то о чём я говорил. Есть две программы которые при обработке входящего запроса обмениваются данными между собой в пределах ОС или по сети. А именно, http сервер (nginx/apache/и т.п.) и php-fpm. Для других языков тоже используют отдельный http сервер, будь то nginx, IIS или Tomcat.
Т.е. я изначально описал то что реально существуют практически в 100% проектов выразив это более обощённо, без упоминания деталей. Т.е. де-факто это стандарт отрасли. И я не вижу реальных ограничений, почему то что реализовано в отрасли по умолчанию не может быть заимствовано в организации вашего кода (программы) и вы не можете разделить свою программу на части, которые будут как-то обмениваться между собой данными.
Тут можно добавить ещё проекты в докере...
Вообще, общение на хабре мне напоминает ситуацию, когда ты стоишь и в тебя кидаются мусором из проезжающих поездов. К этому можно отнести замечания про "зависимость сервисов от оптики". Вы это реально плюсуете? А ничего, что веб-сервер работает на уровне приложений сетевой модели OSI, и поэтому всё равно что находится на транспортном уровне (TCP/IP / что-то другое), тем более не важно что на физическом уровне (витая пара, оптика, и т.п).
но сформулировать это не может, так как не знает что там происходит реально
php интерпретируемый язык (хотя в случае Zend Engine это описыватся как компилятор и рантайм среда, но суть не меняется, скрипты есть скрипты) и в силу исторических причин реализация веб сервера на нём требует отдельного http сервера обрабатывающего входящие соединения.
Он в мире, где на каждый запрос создаётся целый процесс
опять же, обработка http запроса относится к отдельному (от php) http серверу и зависит от него. php вызывается им (http сервером) через fast-cgi интерфейс, а для его дальнейшей обработки в php используется FPM (FastCGI Process Manager) и уже он вызывает интерпретатор php.
и запуском мейна
Вот это я действительно не знаю. Как php веб разработчик я не взаимодействую с функцией main. Она приходит из интерпритатора php и раз это Zend Engine написанный на Си, то это оттуда...
так как не знает что там происходит реально
Как человек работавший в научной среде я уверенно могу сказать, что я знаю что ничего не знаю)))
но сформулировать это не может
Опять же, как бывший научный сотрудник, я могу составить реферат и аналитическую статью на основе источников не будучи таким же экспертом как авторы оригиналов (вы тут наверное начнёте песню Ярославны про величие практики в укор теории...), но при этом всё это будет логически верным содержать обоснованные выводы применительные к практике и даже содержать некотрое выводы которых не было в источниках, ведь мой интелект не ИИ, а естейственный))) Но не слишком ли вы много хотите от проходного поста на хабре? Ведь даже ваш стартер пост лишь перевод чужих мыслей... (и как утверждают некоторые машинный)
(по моему именно так работает php)
вот я вам уже несколько раз говорил, что я не топлю за микросервисную архитектуру и в некотором смысле на вашей стороне, а вы... и что "по вашему" это говорит о вашем "мнении"?
Вообще, сравнивать монолит и микросервесную архитектуру логически не корректно. Микросервисы это распределенная система и сравнивать её надо с системой на одной ОС. Это можно сравнить как в системном администрировании если есть деньги, то стараются растащить контроллер домена, почту, днс, файловый сервер, сервер печати и бог весть что ещё по разным железкам, чтобы не ловить гемморой от их совместного сосуществования на одной машине, но при этом их сосуществование на одной машине не является не является монолитом, потому что они изолированны друг от друга. При этом каждый отдельный програмный-сервер (почта, AD, ДНС) могут быть монолитами, и то что вы их растащите по отдельным железкам (типо сделаете микросервисную архитектуру) они не перестанут быть монолитами если они были таковыми до этого. Поэтому протипоставление монолита и микросервисной архитектуры ложное и происходит от недостатка мыслительной деятельности в сообществе разработчиков.
На этот счёт мне припоминается, что если есть две программы на компе (линукс), то передать между ними данные можно только через что то внешнее, типа сокетов или файлов. Напрямую ОСь не даст вам шарить память между прогами (там наверное есть варианты всякие, но я не про это...).
Т.е. я имел ввиду что у вас есть как минимум два движка. Один допустим на Symfony, другой на Slim (микрофрейворк) для лёгких запросов или как в статье упоминается для чего-то тяжолого типа перекодировки картинок. Соответственно вам нужно их связать.
собственное время выполнения + время выполнения всего, что оттуда было запущено.
Я предположил что вызов первой функции main (кстати, это файл index.php) и всего что было вызвано дальше можно выдать за "что такое "фреймворк выполняется". Мне нужно было пояснить именно этот момент.
лидеры по потреблению времени - это 2-я и 4-я строки
Кстати это получается два автозагрузчика классов. Один движка php, другой фрейма.
Вроде бы сначала для CGI использовали Cи, поэтому это возвращение к истокам))). История замкнулась. Сперва делали без фреймворков на скриптах (в случае Си скомпиленных), потом перешли к фреймам, а сейчас опять переходят к скриптам только распределённым по микросервисам.
"код фреймворка" будет столько же отжирать в любом случае
более коректно сравнивать ЯП, а не фреймы в данном контексте.
Я лишь хотел поделиться мыслью которая как мне кажется коррелирует с микросервисами (использование микрофреймворков для лёгких запросов). И для микросервисов логично использовать именно микрофреймворки для уменьшения накладных расходов на исполнение кода. Хотя конечно сетевые задержки тут определяющие, но зачем прибавлять к ним больше чем минимально необходимо, раз уж вы решили делать распределённую систему.
если вы используте фреймворк Symfony, то перейдя на микрофреймворк Slim или Silex при прочих равных вы выграете в скорости ответа просто потому что у вас будет выполнятся меньше кода фремвока, который должен быть запущен для того чтобы сработал ваш бизнес код. Всё. @Kelbon
А вы читали то что я писал? Я писал про микрофреймворк, а не про микросервис. И говорил про сеть лишь как один из вариантов. И в этом смысле я лишь отвечаю на тот вопрос который интересен вам, поэтому минусуя вы лишь говорите, что не хотите общаться на тему которая интересна вам. Я бы не стал использовать сеть интернет (как минимум).
что такое "фреймворк выполняется"
Для php это как вариант то, что показывает xdebugger profiler для функции main.
куда пропадут эти затраты при создании микросервиса?
почему вы меня это спрашиваете? Я вам предлагал делать микросервис или что? Я высказал вполне конретную мысль.
Есть такие запросы к апи, время выполнения которых тратится по большей части на выполнение кода фреймворка, а на выполнение целевого кода очень мало.
[...]
И естейственно тут возникает идея уменьшить код фреймворка настолько чтобы уменьшить N до нуля, т.е. чтобы выполнялся только полезный код программы, а не что-то ещё.
Получается для запросов у которые M/N маленькое (т.е. полезного кода мало) ускорение ответа апи упирается в этот предел (скорость фреймворка) и использование микрофремворка помогает в его преодолении.
Мне не хочется участвовать в деструктивной дискусии на неопределённую тему за которую меня ещё и минисуют, поэтому давайте уточним о чём мы сейчас говорим? Вы прореагировали на мой ответ на другой вопрос где тоже упоминается микросервисы, о которых я не упоминал, и не хочется уходить в дискусию на тему, которой для меня не было.
допустим если фрейморк на php выполняется за 160 ms, то думаю да, можно добиться что по сети будет быстрее на микрофреймворке который будет отрабатывать за 60 ms. Сделать соединение которое будет быстрее 100 ms думаю не так сложно...
Вообще существует много чего в этом плане. Оптоволокно, соединение через PCI (Express) чуть ли не со скоростью оперативки. Сетевые технологии раньше веба возникли и в корпоративных сетях ещё в конце 90х использовали много чего побыстрее Ethernet. А сейчас если используется виртуализация или докер, то тоже сетевой интерфейс очень быстрый.
Один. Сбросив миксер с крыши (исследовав ударную прочность) вы (как исполнитель) будете уверены что вам не будет больно когда миксер при старте ракеты развалится. А как компания вы будете уверены, что узколобость отдельного исполнителя не повлияет на успешность доставки миксера на орбиту. Т.е. думать что исполнители хорошие добросовестные ребята это конечно приветствуется, но почитайте сборник законов Мёрфи...
Два. Это момент по поводу того, что никакая "задача" не может быть выбита в граните так, чтобы её нельзя было скоректировать под воздействием реальности, и вашего понимания этой задачи в этой реальности. Вы должны быть открыты ко всему, что может изменить эту задачу на основе обратной связи, тем более если она не имеет смысла.
Если компании нужно отправить спутник на орбиту и ты просто скинул с крышы офиса миксер - окей, ты выяснил, что миксеры не летают.
Дело в том, что всё что отправляется в космос на ракете действительно скидывают с крыши офиса)). На современно этапе это называется испытанием (исследованием) ударной прочтности, которое делаю чтобы быть уверенным что ваш миксер не развалится при стартовой перегрузке. На уровне физики это (исследование ударной прочности) тоже что скинуть миксер с высоты h n раз.
Технологи на производстве тоже постоянно занимаются исследованиями. Просто эти исследования стандартизованы и могут называться калибровкой, или ещё как. Но само по себе это и есть исследование. И на производстве чего бы то нибыло его постоянно делают возможно под другими названиями.
Исследование должно создавать ценность, которая неким значимым образом приближает компанию к решению бизнес-задач. В примере с миксером реальная польза максимально близка к нулю.
На этот счёт припоминается что-то из менеджмента по поводу того, что само по себе формулирование бизнес-задачи зависит от вашего понимания много чего и никак не должно быть выдолблено в камне, именно потому что некоторые аспекты задачи вы начинаете воспринимать как "польза максимально близка к нулю", хотя на самом деле это польза от вашей задачи близка к нулю. Как в примере, когда вам ставят задачу всунуть квадратную втулку в треугольное отверстие.
Мне кажеться микросервисы это доведённая до апофеоза следующая мысль.
Есть такие запросы к апи, время выполнения которых тратится по большей части на выполнение кода фреймворка, а на выполнение целевого кода очень мало.
Т.е. если N время выполнения кода фремворка при запросе апи, а M время выполнения кода в экшене (бизнес логики), то для некоторых запросов к апи отношение M/N -> 0 (стремится к нулю). Т.е. полезного кода почти не выполняется.
И естейственно тут возникает идея уменьшить код фреймворка настолько чтобы уменьшить N до нуля, т.е. чтобы выполнялся только полезный код программы, а не что-то ещё.
Получается для запросов у которые M/N маленькое (т.е. полезного кода мало) ускорение ответа апи упирается в этот предел (скорость фреймворка) и использование микрофремворка помогает в его преодолении.
А дальше уже большие дяди придумали распределённую систему, и в итоге забыли ради чего всё было затеяно...
Автор говорит, что не успешность в решении одной бизнес задачи не мешает вам использовать результат для решения другой. Т.е. само по себе исследование обогащает ваш опыт вне зависимости от полученного результата в определенном контексте и т.о. исследование в конечном счёте успешно.
кстате, этот обработчик (AccessTokenHandler) если в запросе нет токена (Bearer), то он даже не вызывается и запрос проходит без валидации токена, хотя настройка фаервола стоит (security: true). Не очень понял как обработать данную ситуацию кроме как установить роль в акцесс контроле (access_control).
а ещё сисадмины, если пользователь говорит что это хрень собачья, которая не хрена не работает, делают так как хочет пользователь, а не говорят ему что он сам криворукий, а тут типо работает и я не трогаю (а те кто говорит плохо заканчивают).
Но суть не в этом.
Речь шла не о том понятна ли работа ИИ, а о том что если ИИ насоздаёт непонятных математик и прочего что вами упоминалась, то никто не придёт от этого в восторг. Т.е. если вы попросите как тут упоминается написать какой-то кусок кода, а в ответ вам чатжопагде выдасть набор каких-то непонятных символов (т.е. типо саздаст новый ЯП и выдаст вам код на нём), то вы не скажете круто, это работает, поэтому погнали это в прод. Вы скорее всего засрёте этот чатвжопевсе и статью на хабре ещё напишите какой жпте беспонтовый ваще... И если его и не сотрут буквально, и может даже фирма не разорится, но такую выдачу ответов пресекут и вернут в область понятного для того кто пользуется этим.
Понятно. Вы о каком то воображаемом ИИ, который "управляет каждым атомом во вселенной".
Но такой ИИ не будет создан именно потому что критерии для развития этого ИИ задаёт череловек, а ему нужно чтобы результат работы ИИ был ему понятен, а не просто "трах ти бы дох, пиау пиау". И то что не понятно человеку, он стирает и делает то что ему понятно.
Кажется на этот счёт уже сказал один учёный, что такой ИИ примут за не рабочий и сотрут, ибо нафига ИИ который генерирует то что невозможно понять. А сам он ничего реализовать пока не сможет.
кстати, именно так сделаны все веб-серверы на php.
Есть http сервер (nginx/apache/и т.п.) и есть php-fpm. И они друг другу передают данные по порту. И кстате это делается без сериализации (в обоих случях).
Что это даёт? это даёт изолированность частей, и как тут очень любят поминать, избаляет от лишних зависимостей. Т.е. я могу поменять apache на nginx или на caddy (go) и мне не придётся что-то менять на стороне php.
Относительно такого разделения на уровне php могу привести пример докер проекта где апи, админка и фронт разделены на два/три разных докер контейнера (помимо прочего). И общаются между собой по докер сети. Что это даёт. ну это даёт то, что вы можете в админке установить только те зависимости, которые нужны в админке, а в апишке установить те, что нужны в ней и не перемешивать их между собой. кроме того сам код можноно релизить относительно независимо. И вообще, как я приводил пример с системным администрированием, вы можете контроллер домена, ДНС, FTP, фийловый сервер, сервер печати поместить на один сервер, а можете растощить по разным. И такая организация кода позволяет это сделать.
Фраза про недостаток "недостатка мыслительной деятельности" была не уместна.
80% интернета всё ещё сделано на php, а это значит, что используется, то о чём я говорил. Есть две программы которые при обработке входящего запроса обмениваются данными между собой в пределах ОС или по сети. А именно, http сервер (nginx/apache/и т.п.) и php-fpm. Для других языков тоже используют отдельный http сервер, будь то nginx, IIS или Tomcat.
Т.е. я изначально описал то что реально существуют практически в 100% проектов выразив это более обощённо, без упоминания деталей. Т.е. де-факто это стандарт отрасли. И я не вижу реальных ограничений, почему то что реализовано в отрасли по умолчанию не может быть заимствовано в организации вашего кода (программы) и вы не можете разделить свою программу на части, которые будут как-то обмениваться между собой данными.
Тут можно добавить ещё проекты в докере...
Вообще, общение на хабре мне напоминает ситуацию, когда ты стоишь и в тебя кидаются мусором из проезжающих поездов. К этому можно отнести замечания про "зависимость сервисов от оптики". Вы это реально плюсуете? А ничего, что веб-сервер работает на уровне приложений сетевой модели OSI, и поэтому всё равно что находится на транспортном уровне (TCP/IP / что-то другое), тем более не важно что на физическом уровне (витая пара, оптика, и т.п).
php интерпретируемый язык (хотя в случае Zend Engine это описыватся как компилятор и рантайм среда, но суть не меняется, скрипты есть скрипты) и в силу исторических причин реализация веб сервера на нём требует отдельного http сервера обрабатывающего входящие соединения.
опять же, обработка http запроса относится к отдельному (от php) http серверу и зависит от него. php вызывается им (http сервером) через fast-cgi интерфейс, а для его дальнейшей обработки в php используется FPM (FastCGI Process Manager) и уже он вызывает интерпретатор php.
Вот это я действительно не знаю. Как php веб разработчик я не взаимодействую с функцией main. Она приходит из интерпритатора php и раз это Zend Engine написанный на Си, то это оттуда...
Как человек работавший в научной среде я уверенно могу сказать, что я знаю что ничего не знаю)))
Опять же, как бывший научный сотрудник, я могу составить реферат и аналитическую статью на основе источников не будучи таким же экспертом как авторы оригиналов (вы тут наверное начнёте песню Ярославны про величие практики в укор теории...), но при этом всё это будет логически верным содержать обоснованные выводы применительные к практике и даже содержать некотрое выводы которых не было в источниках, ведь мой интелект не ИИ, а естейственный))) Но не слишком ли вы много хотите от проходного поста на хабре? Ведь даже ваш стартер пост лишь перевод чужих мыслей... (и как утверждают некоторые машинный)
вот я вам уже несколько раз говорил, что я не топлю за микросервисную архитектуру и в некотором смысле на вашей стороне, а вы... и что "по вашему" это говорит о вашем "мнении"?
Вообще, сравнивать монолит и микросервесную архитектуру логически не корректно. Микросервисы это распределенная система и сравнивать её надо с системой на одной ОС. Это можно сравнить как в системном администрировании если есть деньги, то стараются растащить контроллер домена, почту, днс, файловый сервер, сервер печати и бог весть что ещё по разным железкам, чтобы не ловить гемморой от их совместного сосуществования на одной машине, но при этом их сосуществование на одной машине не является не является монолитом, потому что они изолированны друг от друга. При этом каждый отдельный програмный-сервер (почта, AD, ДНС) могут быть монолитами, и то что вы их растащите по отдельным железкам (типо сделаете микросервисную архитектуру) они не перестанут быть монолитами если они были таковыми до этого. Поэтому протипоставление монолита и микросервисной архитектуры ложное и происходит от недостатка мыслительной деятельности в сообществе разработчиков.
как охотно вы скатились к жаргонной лексике.
стоило лишь появится одному барану матершиннику и вы почуствовали себя в своём стаде?
П.с. хотя я понимаю ваш стресс как автора стартер поста связанный к какофонией присущей хабру))))
Допустим.
Согласно вашим сведениям я могу произвольно связать так два приложения, особенно если это скрипты на рантайме?
Допустим я запускаю два скрипта на ноде
я смогу расшарить память для них?
и даже если смогу не будет ли это слишком большая привязка к оборудованию?
На этот счёт мне припоминается, что если есть две программы на компе (линукс), то передать между ними данные можно только через что то внешнее, типа сокетов или файлов. Напрямую ОСь не даст вам шарить память между прогами (там наверное есть варианты всякие, но я не про это...).
Т.е. я имел ввиду что у вас есть как минимум два движка. Один допустим на Symfony, другой на Slim (микрофрейворк) для лёгких запросов или как в статье упоминается для чего-то тяжолого типа перекодировки картинок. Соответственно вам нужно их связать.
Я предположил что вызов первой функции main (кстати, это файл index.php) и всего что было вызвано дальше можно выдать за "что такое "фреймворк выполняется". Мне нужно было пояснить именно этот момент.
Кстати это получается два автозагрузчика классов. Один движка php, другой фрейма.
Вроде бы сначала для CGI использовали Cи, поэтому это возвращение к истокам))). История замкнулась. Сперва делали без фреймворков на скриптах (в случае Си скомпиленных), потом перешли к фреймам, а сейчас опять переходят к скриптам только распределённым по микросервисам.
более коректно сравнивать ЯП, а не фреймы в данном контексте.
Я лишь хотел поделиться мыслью которая как мне кажется коррелирует с микросервисами (использование микрофреймворков для лёгких запросов). И для микросервисов логично использовать именно микрофреймворки для уменьшения накладных расходов на исполнение кода. Хотя конечно сетевые задержки тут определяющие, но зачем прибавлять к ним больше чем минимально необходимо, раз уж вы решили делать распределённую систему.
т.е. ещё раз моя мысль.
если вы используте фреймворк Symfony, то перейдя на микрофреймворк Slim или Silex при прочих равных вы выграете в скорости ответа просто потому что у вас будет выполнятся меньше кода фремвока, который должен быть запущен для того чтобы сработал ваш бизнес код. Всё. @Kelbon
А вы читали то что я писал? Я писал про микрофреймворк, а не про микросервис. И говорил про сеть лишь как один из вариантов. И в этом смысле я лишь отвечаю на тот вопрос который интересен вам, поэтому минусуя вы лишь говорите, что не хотите общаться на тему которая интересна вам. Я бы не стал использовать сеть интернет (как минимум).
Для php это как вариант то, что показывает xdebugger profiler для функции main.
почему вы меня это спрашиваете? Я вам предлагал делать микросервис или что? Я высказал вполне конретную мысль.
Мне не хочется участвовать в деструктивной дискусии на неопределённую тему за которую меня ещё и минисуют, поэтому давайте уточним о чём мы сейчас говорим? Вы прореагировали на мой ответ на другой вопрос где тоже упоминается микросервисы, о которых я не упоминал, и не хочется уходить в дискусию на тему, которой для меня не было.
это синоним монолита? далее допускаю что да.
допустим если фрейморк на php выполняется за 160 ms, то думаю да, можно добиться что по сети будет быстрее на микрофреймворке который будет отрабатывать за 60 ms. Сделать соединение которое будет быстрее 100 ms думаю не так сложно...
Вообще существует много чего в этом плане. Оптоволокно, соединение через PCI (Express) чуть ли не со скоростью оперативки. Сетевые технологии раньше веба возникли и в корпоративных сетях ещё в конце 90х использовали много чего побыстрее Ethernet. А сейчас если используется виртуализация или докер, то тоже сетевой интерфейс очень быстрый.
Раз. во внутренней сети между хостами может быть очень быстрое соединение.
Два. это может быть вообще один хост.
Три. это может быть передача данных через редис, через сокеты, и т.д., а не через сеть.
Но я не про парижскую коммуну, а про идею революции.
Как я написал тут https://habr.com/ru/companies/yoomoney/articles/777596/comments/#comment_26246028, есть два измерения этого вопроса.
Один. Сбросив миксер с крыши (исследовав ударную прочность) вы (как исполнитель) будете уверены что вам не будет больно когда миксер при старте ракеты развалится. А как компания вы будете уверены, что узколобость отдельного исполнителя не повлияет на успешность доставки миксера на орбиту. Т.е. думать что исполнители хорошие добросовестные ребята это конечно приветствуется, но почитайте сборник законов Мёрфи...
Два. Это момент по поводу того, что никакая "задача" не может быть выбита в граните так, чтобы её нельзя было скоректировать под воздействием реальности, и вашего понимания этой задачи в этой реальности. Вы должны быть открыты ко всему, что может изменить эту задачу на основе обратной связи, тем более если она не имеет смысла.
Дело в том, что всё что отправляется в космос на ракете действительно скидывают с крыши офиса)). На современно этапе это называется испытанием (исследованием) ударной прочтности, которое делаю чтобы быть уверенным что ваш миксер не развалится при стартовой перегрузке. На уровне физики это (исследование ударной прочности) тоже что скинуть миксер с высоты h n раз.
Технологи на производстве тоже постоянно занимаются исследованиями. Просто эти исследования стандартизованы и могут называться калибровкой, или ещё как. Но само по себе это и есть исследование. И на производстве чего бы то нибыло его постоянно делают возможно под другими названиями.
На этот счёт припоминается что-то из менеджмента по поводу того, что само по себе формулирование бизнес-задачи зависит от вашего понимания много чего и никак не должно быть выдолблено в камне, именно потому что некоторые аспекты задачи вы начинаете воспринимать как "польза максимально близка к нулю", хотя на самом деле это польза от вашей задачи близка к нулю. Как в примере, когда вам ставят задачу всунуть квадратную втулку в треугольное отверстие.
Мне кажеться микросервисы это доведённая до апофеоза следующая мысль.
Есть такие запросы к апи, время выполнения которых тратится по большей части на выполнение кода фреймворка, а на выполнение целевого кода очень мало.
Т.е. если N время выполнения кода фремворка при запросе апи, а M время выполнения кода в экшене (бизнес логики), то для некоторых запросов к апи отношение M/N -> 0 (стремится к нулю). Т.е. полезного кода почти не выполняется.
И естейственно тут возникает идея уменьшить код фреймворка настолько чтобы уменьшить N до нуля, т.е. чтобы выполнялся только полезный код программы, а не что-то ещё.
Получается для запросов у которые M/N маленькое (т.е. полезного кода мало) ускорение ответа апи упирается в этот предел (скорость фреймворка) и использование микрофремворка помогает в его преодолении.
А дальше уже большие дяди придумали распределённую систему, и в итоге забыли ради чего всё было затеяно...
Автор говорит, что не успешность в решении одной бизнес задачи не мешает вам использовать результат для решения другой. Т.е. само по себе исследование обогащает ваш опыт вне зависимости от полученного результата в определенном контексте и т.о. исследование в конечном счёте успешно.
кстате, этот обработчик (AccessTokenHandler) если в запросе нет токена (Bearer), то он даже не вызывается и запрос проходит без валидации токена, хотя настройка фаервола стоит (security: true). Не очень понял как обработать данную ситуацию кроме как установить роль в акцесс контроле (access_control).