Мы начали организовывать конференцию 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 фреймворке.

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

Про опыт работы над проектами из США

Наша компания сейчас работает над вторым проектом для заказчика из Соединенных Штатов. Оба проекта — облачные SaaS-системы (B2B и B2C, соответственно). Основное их отличие для нашей компании заключается в том, что первый мы самостоятельно разрабатывали с нуля, а ко второму мы подключились как удаленная команда, чтобы улучшить и ускорить разработку. Об особенностях, различиях и некоторых выводах пойдет речь в этой статье.

Как мы начинаем разработку проекта

Начало работ по любому IT-проекту начинается с контакта заказчика и компании-разработчика. Если продукт нужно создавать с нуля, то, как правило, изначально у клиента есть только описанная своими словами идея и основные сценарии. Однако, с этим уже можно работать. Далее речь пойдет о процессе трансформации идеи в готовый продукт.

Git-flow: модель ветвления, применяемая в нашей компании

Мы описали модель ветвления для системы контроля версий Git, которую применяем в нашей компании. Основная задача этой модели — обеспечение удобной параллельной работы небольших команд разработчиков и тестировщиков, обеспечение возможности ручного и автоматизированного тестирования и частого выпуска релизов (буквально каждый день).

Материал составлен в виде свода правил и рекомендаций к действию в конкретных ситуациях и опубликован на Github.

Antida git-flow: https://github.com/antidasoftware/git-workflow.

Будем рады, если вы найдете этот поход интересным для себя, а так же с удовольствием обсудим модели ветвления, которые применяете вы.

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

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

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