🌐⤴️https://www.infoq.com/articles/federated-GraphQL-platform-Netflix/

Интересно, вообще, когда-то рассматривал в голове концепт, чтобы в микросервисной архитектуре, сервисы не кидали сообщенки и не делали запрос к апи другого сервиса, а создавали запрос, похожий на SQL или GraphQL, но дальше мыслей дело не пошло. Тут про другое, это больше как ApiGateway, но все же.

🤖Netflix перешла к федеративной архитектуре GraphQL для своей студийной организации, объединив ранее разрозненные API команд в единый граф. Это позволило командам, владеющим данными, также управлять их GraphQL API, поддерживая при этом единый GraphQL API для клиентских разработчиков. Сначала было принято около 40 команд, а сейчас уже более 200 команд участвуют в этом графе. Платформа GraphQL была развита вместе с инструментами и фреймворками, чтобы упростить процесс миграции и поддержку разработчиков. Netflix продолжает инвестиции в улучшение производительности и наблюдаемости графа, перенося также свои потоковые API на эту модель, что представляет новые вызовы из-за различий в использовании и высоких требованиях к производительности.

🌐⤴️https://www.infoq.com/articles/minimum-viable-architecture/

Все меньше люблю я термен "архитектура", потому что он слишком зонтичный. Но при упоминании этого темена, все должны понимающе кивать голвой, как будто происходт что-то хорошее. По статье, скорее шпаргалка, о том, что нужно учитывать, но только я бы сказал что это нужно учитывать всегда, а не только когда делаете mvp.

🤖Концепция минимально жизнеспособного продукта (MVP) помогает командам сосредоточиться на создании самого ценного для клиентов продукта на ранних этапах, чтобы быстро и недорого оценить потенциал рынка перед значительными инвестициями в разработку. MVP должен учитывать не только рыночную, но и техническую жизнеспособность продукта для его поддержания и адаптации к меняющимся потребностям со временем. Создание минимально жизнеспособной архитектуры (MVA) в рамках MVP позволяет командам оценить техническую жизнеспособность и обеспечить устойчивую основу для продукта, которая может быть адаптирована по мере его развития. Прозрачное принятие архитектурных решений помогает организации лучше понимать сделанные выборы, что способствует принятию обоснованных решений о дальнейшей адаптации продукта к изменениям рынка и эволюции потребностей клиентов.

https://peps.python.org/pep-0742/

Когда коту делать нечего, он умывается. Надеюсь этот черновик не примут, по ощущениям слишком частный случай.

Все никак не соберусь с силами и не запишу видос про типы, даже сценарий уже готов 😢

🌐⤴️https://habr.com/ru/articles/348314/

Прям очень хорошая статья по парсерам, теперь хочу в них замазаться.

🤖В статье рассматривается вопрос создания собственных парсеров для текстовых форматов данных, когда использование готовых библиотек невозможно. Автор описывает общие подходы к решению задачи парсинга, представляет обзор инструментария, который может быть использован для создания парсеров, и делится советами на основе личного опыта. Основное внимание уделяется работе с контекстно-свободными грамматиками (CFG) и различными видами алгоритмов парсеров, такими как LL(k), LR(k), SLR и другие. В статье обсуждаются сложности, с которыми разработчики могут столкнуться при создании парсера, и предлагаются способы их решения, включая использование специализированных инструментов для парсинга BNF и PEG грамматик.