Согласно https://datatracker.ietf.org/doc/html/rfc3986 в адресе допустимы только ASCII символы и то не все. Просто некоторые браузеры (и серверный софт) строго поддерживают стандарты, а некоторые допускают вольности для удобства пользователя, надеясь что по пути не будет прокси, который выкинет запрос как не валидный
А теперь композер основное средство распространения. Но теперь Октобер закрыл код и особого значения это уже не имеет для меня — инициирую отказ от Октобера в пользу хотя бы Laravel
Это смотря какие "мы", на каком уровне "мы" и тп. Жизнь "нас", команды разработчиков какого-то модуля монолита, часто становится проще, если принято решение вынести его в микросервис. По крайней мере никто не завяжется на наши детали реализации: вот наш ендпоинт, вот его контракт, вот даже клиентская библиотека, и больше у вас ничего нет физически.
Тут ещё конфликт интересов может быть почти всегда есть на разных уровнях Кому-то интересно попробовать в проде новый технологии и подходы, кому-то наоборот неохота изучать что-то новое и переделывать на него без явной необходимости. Даже у бизнеса бывает мнения типа "если мы не будем использовать стандарты де-факто типа кубернетес, то не получим инвестиции на рост"
ни разные версии одного и того же API — это противоестественно(хотя и возможно).
Да вполне естественно, когда в новую версию API добавили нужную фичу, при этом сильно изменив и всё остальное типа протокола или формата, а времени переписывать весь клиентский код сразу нет. "работает — не трогай" — вполне естественно. Вот и появляются в коде других микросервисов и пользовательских приложений ServiceAClientV1, ServiceAClientV2 которые для разных частей одного инстанса обращаются к другому инстансу по разным версиям API. И это может длиться годами пока команда сервиса A не продвинет выделение времени другим командам для выпиливания ServiceAClientV1 из кодовой базы других команд, потому что все время в А уходит на согласованную поддержку двух версий
«Пока ты тут будешь свой код рефакторить — конкуренты выкатывают новые фичи»
Если не отрефакторим, то фичи мы будем выкатывать медленнее конкурентов — они явно времени на рефакторинг не жалеют )
«Зачем тебе рефакторить? Ты плохой программист и написал говнокод?»
Ты плохой постановщик и 5 лет назад описал только 5 фич, а сейчас жалуешься, что 100500-ю никак закончить не можем без багов — надо было сразу все 100500 описать ))
А какое отношение DevOps отдел имеет к микросервисам?
Девопс работает с тем что есть.
Тогда это админы — девопс-самозванцы, а роль настоящих девопс-инженеров исполняет тот, кто создаёт грамотные шаблоны сервисов, учитывающие и интересы разработчиков (легко и приятно писать бизнес-логику), и интересы админов (легко и приятно деплоить и мониторить)
Согласно https://datatracker.ietf.org/doc/html/rfc3986 в адресе допустимы только ASCII символы и то не все. Просто некоторые браузеры (и серверный софт) строго поддерживают стандарты, а некоторые допускают вольности для удобства пользователя, надеясь что по пути не будет прокси, который выкинет запрос как не валидный
P.S. Про https://tools.ietf.org/html/rfc3987 я в курсе
А может не готовы жертвовать удобством ради, например, большей скорости загрузки страниц — в их метриках удобства она имеет минимальный вес
У некоторых внутреннее табу на использование неймспейсов и ко на кластере для разделения дев/тест окружений от прода
Скорее это разные контексты предметной области типа производства метизделий.
А теперь композер основное средство распространения. Но теперь Октобер закрыл код и особого значения это уже не имеет для меня — инициирую отказ от Октобера в пользу хотя бы Laravel
Переписывать можно по частям, одновременно работая в двух системах, маршрутизируя запросы юзеров между ними
Так уж рыночек порешал, что есть позиции DevOps-инженеров, основная задача которых в идеальном мире — технически обеспечивать работу по методологии
Это смотря какие "мы", на каком уровне "мы" и тп. Жизнь "нас", команды разработчиков какого-то модуля монолита, часто становится проще, если принято решение вынести его в микросервис. По крайней мере никто не завяжется на наши детали реализации: вот наш ендпоинт, вот его контракт, вот даже клиентская библиотека, и больше у вас ничего нет физически.
А другие приложения бездумно обновляли версию этого пакета?
Отдать на аутсорс всякое не особо на старте важное, но необходимое?
Ну а как научиться, не начав делая их неправильно? ))
Тут ещё конфликт интересов
может бытьпочти всегда есть на разных уровнях Кому-то интересно попробовать в проде новый технологии и подходы, кому-то наоборот неохота изучать что-то новое и переделывать на него без явной необходимости. Даже у бизнеса бывает мнения типа "если мы не будем использовать стандарты де-факто типа кубернетес, то не получим инвестиции на рост"Да вполне естественно, когда в новую версию API добавили нужную фичу, при этом сильно изменив и всё остальное типа протокола или формата, а времени переписывать весь клиентский код сразу нет. "работает — не трогай" — вполне естественно. Вот и появляются в коде других микросервисов и пользовательских приложений ServiceAClientV1, ServiceAClientV2 которые для разных частей одного инстанса обращаются к другому инстансу по разным версиям API. И это может длиться годами пока команда сервиса A не продвинет выделение времени другим командам для выпиливания ServiceAClientV1 из кодовой базы других команд, потому что все время в А уходит на согласованную поддержку двух версий
Привет от экосистемы nodejs
Микросервис не так страшно отдать команде, которая не умеет писать монолит как монолит )
Думаете тимлид сроки назначает?
Если не отрефакторим, то фичи мы будем выкатывать медленнее конкурентов — они явно времени на рефакторинг не жалеют )
Ты плохой постановщик и 5 лет назад описал только 5 фич, а сейчас жалуешься, что 100500-ю никак закончить не можем без багов — надо было сразу все 100500 описать ))
Тогда это админы — девопс-самозванцы, а роль настоящих девопс-инженеров исполняет тот, кто создаёт грамотные шаблоны сервисов, учитывающие и интересы разработчиков (легко и приятно писать бизнес-логику), и интересы админов (легко и приятно деплоить и мониторить)
В теле ответа могут быть: