Использовать DRY, опираясь на реализацию - приводит к описанным проблемам. Использовать DRY, опираясь на контракт и выделяя абстракции как наиболее стабильные части - находится за пределами бытового понимания.
А 'на офисном ПК под Windows 10 (апрель 2024)' это как? Мои устройства с 4Гб оперативной памяти уже в пролете для современного веба? А Acer Aspire One с 1Гб?
ТОЛЬКО браузер без вкладок вроде легко отжирает 2,5Гб. При открытии сайта - своп и запись сотен мелких кэш файлов убивают остаток ресурсов. Чем таким занято нативное приложение, чтобы, ничего не выполняя, столько памяти использовать. Откуда борьба за миллисекунды бенчмарков, если браузер загружается 30 секунд, а потом каждый сайт в нем еще по пол-минуты, а после 5 вкладок, начинает выгружать фоновые. О видео речи даже не идет - аппаратное декодирование новых форматов убивает старые девайсы быстрее нехватки памяти.
И вот все вроде хорошо. Да только в реальной жизни Kafka, Spark и Hadoop живет где-то там, в королевстве кривых платформ корпоративного разлива, администрируются выделенной командой, и настроены согласно их, этой команды, представлениям о прекрасном.
И при попытке использовать эти сервисы, проблема не в том, как контейнеры локально поднять, или пакеты в виртуальное окружение питона установить, а, скорее, в том, чтобы затолкать в свой нормально выглядящий скрипт обработки поддержку stage-развертывания, Kerberos аутентификации, и автосинхронизацию схем топиков, ибо дата продюсеры имеют обыкновение, без объявления, ломать формат сообщений.
И после фарширования скрипта обработки всем этим хозяйством, еще и неплохо уметь его локально запускать для тестов. И воспроизвести локально тот же Kerberos уже не так просто....
Концептуально похоже на 20-летний уже как ISO стандарт-расширение ISO IEC 14496 по хранению и передаче трехмерных сцен как параметров объектов в формате MP4 файлов. Дальше нескольких научных работ это не ушло. Скорее всего по причине отсутствия как раз вменяемого способа такие сцены показывать и создавать.
А как две разные архитектуры выглядят для софта? Надо отдельные ОС иметь для каждого ядра, или в сейчас можно тот же Linux собрать в мультиплатформу ARM+Risc-v? А планировщик задач как работать может в таких условиях? В десктопных Intel E+P ядра отрывают голову планировщику. А тут аж архитектуры разные. Ну и ядра не то чтобы мощные для трансляции инструкций на лету.
А 'отличный' проект. Позволить скриптам с администраторскими правами скачать с неизвестного сервера какие-то непонятные исполняемые файлы и почти 3 гигабайта архив, и распаковать это все прямо в свою систему с выключенными сервисами безопасности. Антивирус тоже нужно отключать? Почему-то не упомянуто.
Нет бы выложить описание и документацию, что, где как и почему подменяется. Менее подозрительно было бы, и более полезно знать.
Сэкономлю пару кликов: в архиве всякие медиа файлы, куски Office 2010 включая Project и Visio, россыпь исполняемых файлов из разных проектов по смене внешнего вида Windows, патчи реестра, батники и PowerShell скрипты, чтобы все это смотать.
Выглядит максимально подозрительно уже, и крайне рисково в целом на перспективу.
Но работа проведена грандиозная, что есть, то есть.
Небольшой веб-сервис c OpenAPI UI, предоставляет просто API, и взаимодействует с несколькими другими API. OpenAPI 3.0 нам было достаточно. Внешние сервисы: Swagger 2 или OpenAPI 3.0 тоже. API Клиент не предполагает распространение, и скорее для внутренних нужд и тестирования сервиса, однако для внешних сервисов хозяева сервисов клиенты не предоставляют.
Главные требования к выбору генератора - API Spec First, чтобы фокусироваться на контракте, а не на коде; изоляция сгенерированного кода от реализации в целях проверки совместимости типов и декларации интерфейса; минимальное количество ручной работы по выполнению тривиальный операций преобразования форматов; Язык - Python, Сервер приложений не важен, лишь бы было четкое разделение, где свой код, где генерированный.
Стандартным генератором я бы назвал https://github.com/swagger-api/swagger-codegen. Выглядит достаточно официальным, предлагает генераторы для сервера и клиента. Вот к нему основная претензия в неочевидном мусоре. Генерируется куча всего, развалено как попало, да еще и как jar файл распространяется. Без экосистемы разработки на Java было крайне нетривиально его запустить в CI/CD, а интегрировать в Python package структуру проекта оказалось неподъемно. Какое-то оно оказалось, Java-style что ли...
После активного поиска и в целом разочарования по серверным генераторам, пришли к https://github.com/spec-first/connexion, с ним необычно, что генерации серверного кода нет вообще, и фреймворк реализует весь бойлерплейт на лету в рантайме, но вменяемая и тривиальная интеграция через operationID атрибут нас устроила. Имеем API Spec файл, который при сборке подсовывается в connexion и это все запускает с guvicorn. Если какие-то контракты не соблюдены - на старте ругается на несоответствие схемы и реализации.
С генерацией клиента оказалось проще, но интереснее Альтернатив полно.
Разные команды у нас используют OpenAPI чуть-чуть по-своему, и неограниченные генераторами иногда публикуют некорректные спецификации. Как первый попавшийся генератор, который минималистичный и изолированный: https://github.com/openapi-generators/openapi-python-client. Буквально 3 файла для импорта в собственно приложение и всё. 3 из 5 клиентов до сих пор генерируем этим генератором.
А вот для двух других сервисов, openapi-python-client создает некорректный код клиента или просто валится с ошибкой парсинга, и никаких шансов изменить спецификацию. Так пришли к https://github.com/Azure/autorest, который смог успешно прожевать, хотя и ругаясь предупреждениями. Пришлось отключить строгую проверку типов, но в целом нас устроило. Целиком не мигрировали на autorest из-за лени и нежелания трогать то, что работает.
И все эти прекрасные цифровые финансовые инструменты никак не снижают цену за товар, при оплате здесь и сейчас, целиком и в наиболее удобной форме. Тот же пример с телефоном за 10к. Если он на ценнике 10к, а с кредитом 10к+1к процентов, а с BNPL - на ценнике 11к и без переплат, то как я могу купить телефон за 10к не используя ненужные мне финансовые инструменты, и не оплачивая тот сервис, которым не пользуюсь. Ну и непонятно в этом случае, куда пойдет эта лишняя тысяча, если я полностью оплатил покупке сразу без сплитов.
Для меня это выглядит, как разгон инфляции, ибо кол-во долговых обязательств начинает превышать скорость производства ценности.
Какой оригинальный подход - измерять перспективность новой версии формата через количество строк и уровней вложенности.
Вот чего OpenAPI не хватает, так это строгости, чтобы запретить некорректные интерфейсы. А для этого стоит попробовать уйти от абстрактных JSON схем на каждом углу, и уделить больше времени дизайну собственно архитектуры API и ключевых деталей.
Генераторы тоже головную боль создают. 3.1 не всеми поддерживается вообще. 3.0 поддерживается как попало, и не весь функционал спецификации приводит к корректно сгенерированном коду.
Для серверной части пока только Connexion достоин внимания. Клиентская часть - autorest.
А стандартный генератор производит лишний мусор, который ни интегрировать, ни изолировать в проекте нельзя.
А разве спецификация интерфейса не есть набор обещаний? А реализация - частный случай, выполняющий эти обещания?
Как по мне, так сам подход от кода в спецификации чреват проблемами с неотторгаемым интерфейсом от реализации, а потому стабы, моки, и бойлерплейт проходят мимо.
Как представлю Git clone для С проекта с названием 'Multiplier Façade' и его сборку с использованием make - так дрожь пробирает. UTF-8 до сих пор не везде, а разный регистр и пробелы в именах - это верный способ запутаться. Одна система позволяет пробелы в именах, другой надо дефисы, а третья - только подчеркивания, как разделители.
А если серьезно, здравый смысл никто не отменял. И Domain-Driven Development нам в помощь. Говорим об крупно масштабной архитектуре - используем функциональные имена, выделили сферы ответственности, назначили исполнителей, сопоставили функционал и декомпозицию, проекты и репозитории уже допустимо обозначать короткими именами, аббревиатурами и сокращениями, спускаемся еще ниже и внутри команды разработки компоненты создали внутреннюю утилиту для локальных нужд - хоть в карту Швеции тыкаем, и, как Икея, имя выбираем. Все равно эта утилита сдохнет, когда автор перейдет в другую компанию.
А как оценить ответы на эти вопросы? На поле интервью, где один участник более опытен в жонглировании словами, чем другой, ответ надо как-то оценить:
Как я буду получать обратную связь? -> На периодических 1-1 с линейным менеджером.
Это хороший ответ или не очень? Какие бывают другие варианты? В чем их отличия?
И так по всем вопросам. Если на каждый заданный вопрос докапываться до сути и продираться сквозь маркетинг-буллшит, то интервью будет не 4 часа, а 400 и в найме откажут, потому что занудный такой, и софт-скиллы отсутствуют, чтобы понять, когда пора заканчивать и продолжать выполнять негласный социальный контракт: 3 вопроса в конце беседы на нейтральные темы.
Вот хорошая статья, обстоятельная, и читается хорошо. Продолжения жду, спасибо за труд.
К последовательности изложения есть вопросы, которые осложняют восприятие. Начали статью с классификации сверхпроводников, перечислили группы, и ушли от дальнейшего раскрытия темы.
Затем, начали про историю открытия и вехи в исследованиях, но абзацы с фактами не упорядочены по времени и логика повествования ломается. К концу статьи очень много малозначимых для неподготовленной аудитории деталей. И при этом, непонятно, зачем перечислять все эти соединения в статье, без предварительного введения в особенности химии и физики сверхпроводников.
Ну как-то так.... Прекрасный пересказ вводной статьи из руководства по Rust. А каким-же все-таки идиоматическим способом обрабатывать ошибки в реальном софте, в котором 40 зависимостей, каждая со своим набором ошибок, обмазано все асинхронностью, хотя бы с помощью Tokyo, и все это затолкано в собственные крейты для удобства администрирования и декомпозиции, не рассказано. За перевод - спасибо, притарю статью в закладки.
Когда-то давно мне посоветовали MessagEase клавиатуру. Как подсел, назад на стандартную уже не хочется. Она не для девелоперов и Ctrl или Shift на ней нет, но разные раскладки, цифры, символы и выделить\копировать\вставить\навигация курсора - всегда под рукой и кастомизируется. А еще из неочевидных плюсов(или минусов) - никто кроме тебя не сможет на твоем телефоне набрать ни слова, потому что при первом взгляде взрывает мозг.
https - это протокол http завернутый в tls. Где tls, как правило, используется для верификации сервера, хотя и поддерживает верификацию клиентского сертификата. И да - я ни разу не встречал в дикой природе Интернета(что как бы разительно отличается по сути от внутрикорпоративных сетей со своими правилами администрирования) сервисов, которые поддерживают клиентские сертификаты https, и само собой не видел, где я могу себе такой сертификат прикупить, и в какое место присунуть. И даже в случае успеха, контрагент, с которым я связываюсь через электронную почту в браузере, веб-интерфейс телеграма или любой другой сервис, не может быть уверен в самом сервисе, которому мы оба как бы доверяем потому что https, но все-таки не до конца. Потому хотелось бы PGP/GPG(которым уже почти 40/30 лет в обед). А вот его как раз для электронной почты широко и не внедрено.
По схожим причинам, полагаю, и подпись биологически сгенерированного контента может не взлететь.
К слову, поразительно, что SSH аутентификация с ключами вместо паролей почему-то более популярна чем PGP для коммуникации. Хотя по сути своей схожа - доверенный издатель, подписи и ключи. Но для SSH мы свой ключ загружаем на удаленную машину самостоятельно заранее и никаких проблем, а для передачи сообщения - хотим избежать спама на засвеченный в центре сертификации адрес почты. Такое впечатление, что в системе PGP или в ее приложении к электронной почте есть фундаментальный изъян UX при неопровержимых функциональных преимуществах.
Вот это прямо оно! Даже без блокчейна, а просто цифровой удостоверенной подписью. Однако подписание электронной почты не влетает в массы уже уйму лет. Есть обстоятельства непреодолимой силы.
Остроумное решение, но как же сомнительно выглядит Python код, который регулярными выражениями патчит файл на лету перед публикацией, посреди yaml разметки.
Но за все равно спасибо, что поделились опытом и наработками.
Выглядит один в один Flask и миллиона других подобных фреймворков для Python. В чем ключевая особенность фреймворка, помимо выхода из экосистемы Nim? И какие планы по поддержке API-first подхода?
Использовать DRY, опираясь на реализацию - приводит к описанным проблемам. Использовать DRY, опираясь на контракт и выделяя абстракции как наиболее стабильные части - находится за пределами бытового понимания.
А 'на офисном ПК под Windows 10 (апрель 2024)' это как? Мои устройства с 4Гб оперативной памяти уже в пролете для современного веба? А Acer Aspire One с 1Гб?
ТОЛЬКО браузер без вкладок вроде легко отжирает 2,5Гб. При открытии сайта - своп и запись сотен мелких кэш файлов убивают остаток ресурсов. Чем таким занято нативное приложение, чтобы, ничего не выполняя, столько памяти использовать. Откуда борьба за миллисекунды бенчмарков, если браузер загружается 30 секунд, а потом каждый сайт в нем еще по пол-минуты, а после 5 вкладок, начинает выгружать фоновые. О видео речи даже не идет - аппаратное декодирование новых форматов убивает старые девайсы быстрее нехватки памяти.
И вот все вроде хорошо. Да только в реальной жизни Kafka, Spark и Hadoop живет где-то там, в королевстве кривых платформ корпоративного разлива, администрируются выделенной командой, и настроены согласно их, этой команды, представлениям о прекрасном.
И при попытке использовать эти сервисы, проблема не в том, как контейнеры локально поднять, или пакеты в виртуальное окружение питона установить, а, скорее, в том, чтобы затолкать в свой нормально выглядящий скрипт обработки поддержку stage-развертывания, Kerberos аутентификации, и автосинхронизацию схем топиков, ибо дата продюсеры имеют обыкновение, без объявления, ломать формат сообщений.
И после фарширования скрипта обработки всем этим хозяйством, еще и неплохо уметь его локально запускать для тестов. И воспроизвести локально тот же Kerberos уже не так просто....
Концептуально похоже на 20-летний уже как ISO стандарт-расширение ISO IEC 14496 по хранению и передаче трехмерных сцен как параметров объектов в формате MP4 файлов. Дальше нескольких научных работ это не ушло. Скорее всего по причине отсутствия как раз вменяемого способа такие сцены показывать и создавать.
А где вы берете весь этот узко-специализированный софт? Он же обычно для сертифицированных сервисных центров и распространяется по закрытым каналам.
А как две разные архитектуры выглядят для софта? Надо отдельные ОС иметь для каждого ядра, или в сейчас можно тот же Linux собрать в мультиплатформу ARM+Risc-v? А планировщик задач как работать может в таких условиях? В десктопных Intel E+P ядра отрывают голову планировщику. А тут аж архитектуры разные. Ну и ядра не то чтобы мощные для трансляции инструкций на лету.
А 'отличный' проект. Позволить скриптам с администраторскими правами скачать с неизвестного сервера какие-то непонятные исполняемые файлы и почти 3 гигабайта архив, и распаковать это все прямо в свою систему с выключенными сервисами безопасности. Антивирус тоже нужно отключать? Почему-то не упомянуто.
Нет бы выложить описание и документацию, что, где как и почему подменяется. Менее подозрительно было бы, и более полезно знать.
Сэкономлю пару кликов: в архиве всякие медиа файлы, куски Office 2010 включая Project и Visio, россыпь исполняемых файлов из разных проектов по смене внешнего вида Windows, патчи реестра, батники и PowerShell скрипты, чтобы все это смотать.
Выглядит максимально подозрительно уже, и крайне рисково в целом на перспективу.
Но работа проведена грандиозная, что есть, то есть.
Мой случай следующий:
Небольшой веб-сервис c OpenAPI UI, предоставляет просто API, и взаимодействует с несколькими другими API. OpenAPI 3.0 нам было достаточно. Внешние сервисы: Swagger 2 или OpenAPI 3.0 тоже. API Клиент не предполагает распространение, и скорее для внутренних нужд и тестирования сервиса, однако для внешних сервисов хозяева сервисов клиенты не предоставляют.
Главные требования к выбору генератора - API Spec First, чтобы фокусироваться на контракте, а не на коде; изоляция сгенерированного кода от реализации в целях проверки совместимости типов и декларации интерфейса; минимальное количество ручной работы по выполнению тривиальный операций преобразования форматов; Язык - Python, Сервер приложений не важен, лишь бы было четкое разделение, где свой код, где генерированный.
Стандартным генератором я бы назвал https://github.com/swagger-api/swagger-codegen. Выглядит достаточно официальным, предлагает генераторы для сервера и клиента. Вот к нему основная претензия в неочевидном мусоре. Генерируется куча всего, развалено как попало, да еще и как jar файл распространяется. Без экосистемы разработки на Java было крайне нетривиально его запустить в CI/CD, а интегрировать в Python package структуру проекта оказалось неподъемно. Какое-то оно оказалось, Java-style что ли...
После активного поиска и в целом разочарования по серверным генераторам, пришли к https://github.com/spec-first/connexion, с ним необычно, что генерации серверного кода нет вообще, и фреймворк реализует весь бойлерплейт на лету в рантайме, но вменяемая и тривиальная интеграция через operationID атрибут нас устроила. Имеем API Spec файл, который при сборке подсовывается в connexion и это все запускает с guvicorn. Если какие-то контракты не соблюдены - на старте ругается на несоответствие схемы и реализации.
С генерацией клиента оказалось проще, но интереснее Альтернатив полно.
Разные команды у нас используют OpenAPI чуть-чуть по-своему, и неограниченные генераторами иногда публикуют некорректные спецификации. Как первый попавшийся генератор, который минималистичный и изолированный: https://github.com/openapi-generators/openapi-python-client. Буквально 3 файла для импорта в собственно приложение и всё. 3 из 5 клиентов до сих пор генерируем этим генератором.
А вот для двух других сервисов, openapi-python-client создает некорректный код клиента или просто валится с ошибкой парсинга, и никаких шансов изменить спецификацию. Так пришли к https://github.com/Azure/autorest, который смог успешно прожевать, хотя и ругаясь предупреждениями. Пришлось отключить строгую проверку типов, но в целом нас устроило. Целиком не мигрировали на autorest из-за лени и нежелания трогать то, что работает.
И все эти прекрасные цифровые финансовые инструменты никак не снижают цену за товар, при оплате здесь и сейчас, целиком и в наиболее удобной форме. Тот же пример с телефоном за 10к. Если он на ценнике 10к, а с кредитом 10к+1к процентов, а с BNPL - на ценнике 11к и без переплат, то как я могу купить телефон за 10к не используя ненужные мне финансовые инструменты, и не оплачивая тот сервис, которым не пользуюсь. Ну и непонятно в этом случае, куда пойдет эта лишняя тысяча, если я полностью оплатил покупке сразу без сплитов.
Для меня это выглядит, как разгон инфляции, ибо кол-во долговых обязательств начинает превышать скорость производства ценности.
Какой оригинальный подход - измерять перспективность новой версии формата через количество строк и уровней вложенности.
Вот чего OpenAPI не хватает, так это строгости, чтобы запретить некорректные интерфейсы. А для этого стоит попробовать уйти от абстрактных JSON схем на каждом углу, и уделить больше времени дизайну собственно архитектуры API и ключевых деталей.
Генераторы тоже головную боль создают. 3.1 не всеми поддерживается вообще. 3.0 поддерживается как попало, и не весь функционал спецификации приводит к корректно сгенерированном коду.
Для серверной части пока только Connexion достоин внимания. Клиентская часть - autorest.
А стандартный генератор производит лишний мусор, который ни интегрировать, ни изолировать в проекте нельзя.
А разве спецификация интерфейса не есть набор обещаний? А реализация - частный случай, выполняющий эти обещания?
Как по мне, так сам подход от кода в спецификации чреват проблемами с неотторгаемым интерфейсом от реализации, а потому стабы, моки, и бойлерплейт проходят мимо.
Как представлю Git clone для С проекта с названием 'Multiplier Façade' и его сборку с использованием make - так дрожь пробирает. UTF-8 до сих пор не везде, а разный регистр и пробелы в именах - это верный способ запутаться. Одна система позволяет пробелы в именах, другой надо дефисы, а третья - только подчеркивания, как разделители.
А если серьезно, здравый смысл никто не отменял. И Domain-Driven Development нам в помощь. Говорим об крупно масштабной архитектуре - используем функциональные имена, выделили сферы ответственности, назначили исполнителей, сопоставили функционал и декомпозицию, проекты и репозитории уже допустимо обозначать короткими именами, аббревиатурами и сокращениями, спускаемся еще ниже и внутри команды разработки компоненты создали внутреннюю утилиту для локальных нужд - хоть в карту Швеции тыкаем, и, как Икея, имя выбираем. Все равно эта утилита сдохнет, когда автор перейдет в другую компанию.
А как оценить ответы на эти вопросы? На поле интервью, где один участник более опытен в жонглировании словами, чем другой, ответ надо как-то оценить:
Это хороший ответ или не очень? Какие бывают другие варианты? В чем их отличия?
И так по всем вопросам. Если на каждый заданный вопрос докапываться до сути и продираться сквозь маркетинг-буллшит, то интервью будет не 4 часа, а 400 и в найме откажут, потому что занудный такой, и софт-скиллы отсутствуют, чтобы понять, когда пора заканчивать и продолжать выполнять негласный социальный контракт: 3 вопроса в конце беседы на нейтральные темы.
Вот хорошая статья, обстоятельная, и читается хорошо. Продолжения жду, спасибо за труд.
К последовательности изложения есть вопросы, которые осложняют восприятие. Начали статью с классификации сверхпроводников, перечислили группы, и ушли от дальнейшего раскрытия темы.
Затем, начали про историю открытия и вехи в исследованиях, но абзацы с фактами не упорядочены по времени и логика повествования ломается. К концу статьи очень много малозначимых для неподготовленной аудитории деталей. И при этом, непонятно, зачем перечислять все эти соединения в статье, без предварительного введения в особенности химии и физики сверхпроводников.
Ну как-то так.... Прекрасный пересказ вводной статьи из руководства по Rust. А каким-же все-таки идиоматическим способом обрабатывать ошибки в реальном софте, в котором 40 зависимостей, каждая со своим набором ошибок, обмазано все асинхронностью, хотя бы с помощью Tokyo, и все это затолкано в собственные крейты для удобства администрирования и декомпозиции, не рассказано. За перевод - спасибо, притарю статью в закладки.
Когда-то давно мне посоветовали MessagEase клавиатуру. Как подсел, назад на стандартную уже не хочется. Она не для девелоперов и Ctrl или Shift на ней нет, но разные раскладки, цифры, символы и выделить\копировать\вставить\навигация курсора - всегда под рукой и кастомизируется. А еще из неочевидных плюсов(или минусов) - никто кроме тебя не сможет на твоем телефоне набрать ни слова, потому что при первом взгляде взрывает мозг.
https - это протокол http завернутый в tls. Где tls, как правило, используется для верификации сервера, хотя и поддерживает верификацию клиентского сертификата. И да - я ни разу не встречал в дикой природе Интернета(что как бы разительно отличается по сути от внутрикорпоративных сетей со своими правилами администрирования) сервисов, которые поддерживают клиентские сертификаты https, и само собой не видел, где я могу себе такой сертификат прикупить, и в какое место присунуть. И даже в случае успеха, контрагент, с которым я связываюсь через электронную почту в браузере, веб-интерфейс телеграма или любой другой сервис, не может быть уверен в самом сервисе, которому мы оба как бы доверяем потому что https, но все-таки не до конца. Потому хотелось бы PGP/GPG(которым уже почти 40/30 лет в обед). А вот его как раз для электронной почты широко и не внедрено.
По схожим причинам, полагаю, и подпись биологически сгенерированного контента может не взлететь.
К слову, поразительно, что SSH аутентификация с ключами вместо паролей почему-то более популярна чем PGP для коммуникации. Хотя по сути своей схожа - доверенный издатель, подписи и ключи. Но для SSH мы свой ключ загружаем на удаленную машину самостоятельно заранее и никаких проблем, а для передачи сообщения - хотим избежать спама на засвеченный в центре сертификации адрес почты. Такое впечатление, что в системе PGP или в ее приложении к электронной почте есть фундаментальный изъян UX при неопровержимых функциональных преимуществах.
Вот это прямо оно! Даже без блокчейна, а просто цифровой удостоверенной подписью. Однако подписание электронной почты не влетает в массы уже уйму лет. Есть обстоятельства непреодолимой силы.
Остроумное решение, но как же сомнительно выглядит Python код, который регулярными выражениями патчит файл на лету перед публикацией, посреди yaml разметки.
Но за все равно спасибо, что поделились опытом и наработками.
Выглядит один в один Flask и миллиона других подобных фреймворков для Python. В чем ключевая особенность фреймворка, помимо выхода из экосистемы Nim? И какие планы по поддержке API-first подхода?