Что внутри asyncio

В этой статье мы предлагаем читателю совершить с нами в меру увлекательное путешествие в недра asyncio, чтобы разобраться, как в ней реализовано асинхронное выполнение кода. Мы оседлаем коллбэки и промчимся по циклу событий сквозь пару ключевых абстракций прямо в корутину. Если на вашей карте питона еще нет этих достопримечательностей, добро пожаловать под кат.

Организация асинхронной работы с РСУБД на языке Python

Нет времени ждать! Нет времени ждать блокирующие I/O операции, поэтому практически каждый backend-разработчик рано или поздно задумывается об использовании асинхронного веб-фреймворка.

На данный момент у Python-разработчика существует достаточно большой выбор фреймворков с различными реализациями event loop’а: от Twisted, больше похожего на сетевую библиотеку, до http клиента и сервера для asyncio aiohttp (>6500 звезд на GitHub), Flask-like фреймворка sanic (>11000 звезд на GitHub) и http клиента и сервера Tornado (>17000 звезд на GitHub).

Редкий веб-сервер обходится без работы с хранилищами данных. И здесь приверженцев реляционных СУБД поджидает неприятный сюрприз: SQLAlchemy ORM, самая популярная ORM для Python, не поддерживает асинхронную работу. Рассмотрим пути решения возникшей задачи удобной работы с РСУБД без использования самой популярной Python-ORM.

Трансформация из Junior в Middle для Python-разработчиков

Статья из внутренней базы знаний нашей компании.

Мы подразумеваем, что разработчик грейда Junior владеет навыками программирования на Python (в идеале — Python 3), базово знает Django/Flask или что-то подобное и умеет работать с базой данных и системной контроля версий (мы используем Git). Таким образом, он может разработать простое веб-приложение на этом стеке.

Для перехода в грейд Middle разработчик должен освоить следующий список инструментов/технологий/навыков.

Мы начали организовывать конференцию Python-разработчиков в Челябинске

В прошлую субботу, 21 октября 2017 года, мы провели свою первую конференцию Python-разработчиков Челябинска. Нам удалось собрать в одном месте почти 70 человек, увлеченных разработкой на этом языке так же, как мы. На первой встрече было представлено пять докладов: три из них были от нашей компании.

Разработка SaaS на Django и Python. Часть 2. Шардинг базы данных (multi-tenant)

В предыдущей статье мы затронули тему размещения аккаунтов на отдельных поддоменах, а так же способ реализации публичного API в обычном приложении Django (с учетом того, что серверная сторона уже реализована в виде WebAPI для SPA-приложения).

Сегодня мы поговорим о шардинге баз данных и о том, как его можно применять при разработке SaaS продуктов. Частично о шардинге мы уже рассказывали ранее в серии статей о проектировании высоконагруженных веб-приложений: База данных. Рекомендую обратиться к этому материалу, т.к. тема оптимизации работы с БД достаточно сложная.

Сегодня речь пойдет по большей части о практике. Мы наглядно покажем (с примерами кода), как можно реализовать шардинг базы данных в SaaS проекте на Django, Python и PostgreSQL/MySQL.

Разработка SaaS на Django и Python. Часть 1. Поддомены и публичный API

Вдохновившись интересными решениями на последних наших проектах, я решил описать то, как можно реализовать три типичные составляющие SaaS проекта на Django и Python.

Материал будет разбит на две части, в которых мы рассмотрим следующие темы.

1. Размещение каждого аккаунта на отдельном поддомене; 
2. Простой и быстрый способ выделить публичный API вашего сервиса; 
3. Размещение данных каждого аккаунта в отдельных базах данных.

Сегодня речь пойдет о первых двух пунктах. Рассказ о размещении аккаунтов в разных базах данных заслуживает отдельной статьи.

На сервере мы часто используем Django и Python, Celery и Redis для реализации распределенной очереди задач, а в качестве СУБД PostgreSQL или MySQL. Клиентская сторона обычно реализуется на AngularJS, ReactJS или другом MVVM/MVC фреймворке.

Исходя из этого, далее по тексту я буду предполагать, что на вашем проекте используется подобный технологический стек, хотя это не принципиально.

Python-клиент для CloudPayments

В прошлой статье я рассказал о том, что у нашей компании накопился определенный опыт работы с различными биллинговыми системами. На одном из проектов мы работали с российской системой CloudPayments. К сожалению, эта система не предоставляет официальной клиентской библиотеки для взаимодействия с API на Python, а на Github мы нашли стороннюю реализацию только под Ruby.

Мы создали Python-клиент для API CloudPayments, когда работали над проектом, а сегодня решили опубликовать его исходный код для всех.

Работа с кастомными поддоменами в веб-приложении Django

В нашей компании сейчас идет разработка SaaS-системы для вендоров, чье программное обеспечение продается по подписке. Зарегистрировавшись в нашей системе, вендор может создать поддомен, на котором будет отображаться сайт с информацией об их компании и решении, которое они предлагают. Этот сайт можно всячески кастомизировать, но сейчас речь пойдет не об этом. Я хотел бы рассказать о том, как мы реализовали возможность создания кастомных поддоменов и их обработку.