Tornado vs Aiohttp: путешествие в дебри асинхронных фреймворков

Делаем веб лучше









Всем привет, хочу поделиться результатом размышлений на тему — каким может быть современное веб-приложение. В качестве примера рассмотрим проектирование доски объявлений для комиксов. В некотором смысле рассматриваемый продукт рассчитан на аудиторию гиков и им сочувствующих, что позволяет проявить вольность в интерфейсе. В технической же составляющей, напротив, необходимо внимание к мелочам.
По правде говоря, я ничего не понимаю в комиксах, но люблю барахолки, особенно в формате форума, какие были популярны в нулевых. Отсюда, допущение (возможно ложное), из которого проистекают последующие выводы, только одно — основной тип взаимодействия с приложением — просмотр, второстепенные — размещение объявлений и обсуждение.
Нашей целью будет создание простого приложения, без технических ноу-хау лишних свистелок, однако соответствующее современным реалиям. Основные требования, соблюдения которых хотелось бы достичь:

В прошлом материале, мы рассмотрели неудобные моменты в системе типов GraphQL.
А теперь мы попробуем победить некоторые из них. Всех заинтересованных, прошу под кат.


Рассмотрим одно из подразделений Яндекс.Маркета. Оно довольно крупное — 85 человек. Внутри подразделения есть несколько команд. Команды либо занимаются функциональными частями Маркета, либо решают какую-то большую пользовательскую задачу. Вот одна из них: изменить сам сервис Яндекс.Маркет и интернет-торговлю в регионах так, чтобы местным пользователям стало удобнее решать свои проблемы.
С чего командам начать? Как объяснить всем вокруг, почему мы делаем одно, а не другое? Как донести до каждого инженера, зачем он занимается своей текущей задачей? Как вкладывать силы в то, что действительно улучшит мир вокруг, и не тратить время на то, что не нужно? Как сделать работу команд прозрачной друг для друга?
Чтобы лучше отвечать на эти и прочие вопросы, мы внедрили особый подход. В соответствии с ним мы разрабатываем продукты и расставляем приоритеты.


