Фёдор Борщёв

Заметки с тегом «Программирование»

Кроме управления разработкой, я ещё пишу код. Под тегом «программирование» я выкладываю заметки связанные с разработкой ПО — пишу про технологии, фреймворки, тесты, железки и всё такое.

Сервис уведомлений и веб-сокетов для строительной компании

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

Современная стройка

Все слышали анекдоты, а многие и лично сталкивались с тем, насколько неэффективными бывают стройки, сколько там можно украсть да и просто сглупить. При этом экономия даже единиц процентов на крупной стройке — это миллионы рублей. Это — идеальная среда для инноваций. Крупные строительные компании активно вкладываются в разработку. Строители пытаются перенести в цифру весь процесс, начиная от архитектурного и инженерного плана здания (BIM, Building information modeling) до того, сколько материалов и когда нужно подвезти на площадку и контроля над тем, насколько точно выдержаны стандарты в процессе работ. У нас был целый эпизод подкаста про это с техническим директором группы компаний ПИК. 

У нашего клиента есть десятки веб-сервисов, которые вместе решают различные BIM проблемы: проектирование, согласование, тендеры, стройконтроль и прочее; десятки изолированных окружений для крупных корпоративных заказчиков, десятки тысяч пользователей.

Наша задача

Нас попросили создать единую, сквозную систему уведомлений. Разные сервисы должны иметь возможность отправить пользователю уведомление, а наша система должна сделать так, чтобы:

  1. сообщения дошли до адресата — по электронной почте, в телеграм, да хоть смской, но дошли — пропущенные правки в тендер или согласование проекта могут стоить миллионы в сутки;
  2. не забомбить пользователей лишними сообщениями — система должна уметь собирать не критичные уведомления в «дайджесты» и присылать их с настраиваемой периодичностью;
  3. дать возможность посмотреть «входящие» в едином интерфейсе;
  4. возможность управления системой без программирования — например, поменять шаблоны, поменять частоту дайджестов и так далее.

Проработка архитектуры. Интеграция с существующей системой.

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

Обмен информацией между модулями происходит синхронно через REST API и асинхронно через брокер сообщений (RabbitMQ).

MVP сервиса нотификаций, который изначально находился у клиента, работал просто и надежно. Спойлер: он очень удачно нас спас, в качестве fallback-сервиса, при досадных ошибках при запуске.

Выглядел он так:

Недостатками сервиса было большое время на внедрения новых событий и невозможность достаточного конфигурирования.

Новая система, в своей основе, также взаимодействует с шиной событий, но кроме этого, имеет свое АПИ для настроек пользователя, интерфейс администратора и удобное подключение к любым каналам доставки.

Спроектированный сервис представляет собой Django монолит (один репозиторий с кодом), который контейнеризуется и деплоится 4 разными способами:

  • Django Web App - реплицируемый uWSGI сервер приложений за балансировщиком нагрузки для предоставления доступа к административному веб-интерфейсу и REST API
  • Celery App - реплицируемый воркер для асинхронных задач
  • Celery Beat App - единственный инстанс планировщика асинхронных задач
  • Event Consumer - единственный инстанс консьюмера событий для нотификаций

Отдельным микро-сервисом реализован Websocket сервер - инстанс для мгновенного оповещения пользователя в браузер.

Разработка сервиса нотификаций

Наш Django-монолит состоит из консьюмера и двух воркеров: воркера-процессора и воркера-отправителя уведомлений.

Получение события

Консьюмер (приемник событий) сделан максимально простым. Его задача — получить сообщение, проверить метаданные и сохранить тело письма. В метаданных мы ожидаем общие параметры, чтобы различать из какого модуля, проекта и касательно какой сущности пришло событие. Далее, такое «сырое» событие подхватит воркер-процессор.

В случае «падения» консьюмера, события не будут потеряны — они накопятся в нашей очереди в брокере и будут доставлены при включении. В случае «падения» остальных частей приложения — события также не будут потеряны. Консьюмер сохраняет их в БД с признаками корректных, но еще не обработанных событий. Поэтому при включении воркеров события будут взяты в обработку и ничего не потеряется.

Такая развязка освобождает консьюмер от высокой нагрузки и обеспечивает персистентность (сохранность) данных в случае сбоев.

Процессинг нотификаций

Задача второго этапа - превратить “сырое” событие в объект нотификации и подготовленных сообщений (доставок) по каналам. Нотификации могут быть двух видов: прямые нотификации и подписки.

Под прямыми нотификациями мы подразумеваем сообщения адресованные непосредственно участникам события. Например, когда на тебя поставили задачу — ты должен быть уведомлен. Это — прямая нотификация.

Подписки — более сложный механизм, о них расскажем ниже в отдельной главе.

Общий подход такой, что процессор получает на вход событие и выполняет следующие действия:

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

Важная задача процессора - это обеспечить идемпотентность операций. Повторный процессинг сырого события не должен создать новых нотификаций.

В чем опасность? Например, при перегруженной очереди (красным на схеме) и частым повтором тасок (event1 -> repeat task for event1) может получиться так, что процессинг выполнится несколько раз. При неудачном сценарии можно отправить несколько десятков одинаковых уведомлений на одно событие.

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

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

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

Еще один важный момент: процессинг всего события в рамках одной БД-транзакции. В случае ошибки на любом этапе процесса, все изменения, сделанные в рамках транзакции, откатываются. Это предотвращает возникновение неконсистентных данных или частично обработанных событий. Такой подход сделал систему более предсказуемой и контролируемой.

Процессинг подписок на события

Одна из фич, которые удалось реализовать совместно с командой заказчика — это сохранение фильтров и подписка на события по сущностям, подпадающим, сейчас или в будущем, под условия этих фильтров. В качестве триггера подписки могут быть любые атрибуты сущности: параметр, диапазон значений, дат, пользователи, роли, компании.

Например, вы можете получать все события в Замечаниях, у которых «срок сдачи == неделя до дедлайна, с ответственными == проектировщики, секция дома == подвал».

Фильтрация сущностей — стандартная функциональность, которая есть в любом интернет-магазине. Директор по продукту поставил задачу не просто фильтровать, а иметь список любимых фильтров и получать уведомления, когда что-то происходит внутри сущностей, которые попадают под эти фильтры.

Такую фичу обслуживают 2 бекенда: бекенд модуля, который хранит сами сущности и наш бекенд нотификаций. Наш бекенд хранит у себя атрибуты подписок. Для каждого события мы проверяем все подписки и находим те, атрибуты которых удовлетворили бы заложенной фильтрации. То есть определяем, подходит данное событие подписчику или нет.

Приятная особенность в том, что при процессинге мы обогащаем данные через отдельный микро-сервис о каждом пользователе, компании или роли из события. Поэтому, например, при подписке на «роль = проектировщик», мы успешно рассылаем все события с Дмитрием Ивановым (проектировщиком), и не посылаем события с Василием Петровым (монтажником).

Существенных нюансов при реализации добавляют два требования:

Первое — важно не послать пользователю повторяющиеся нотификации в один канал доставки, если несколько фильтров подошли под событие. Диаграмма состояний для события в результате становится такой:

Слева направо в Статусе Доставки показано как вычисляются статусы для отправки - SKIPPED (пропускает отправку) и PENDING (ожидает отправку).

Второе — для каждой подписки и для модуля-источника события пользователь настраивает нужные каналы доставки. Т.е., например, важные подписки могут уведомлять в телеграмм, а не важные — на почту.

Доставка уведомлений

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

Новые каналы доставки добавляются просто: программисту необходимо отнаследовать новый провайдер нотификаций, а менеджеру — в админке добавить шаблоны для рендеринга сообщений под данный канал.

Благодаря тому, что тексты нотификаций уже подготовлены заранее в процессоре, отправка получается не сложной. Нам достаточно передать на вход провайдера параметры — кто получатель и готовые тексты (или вёрстку) для заголовка и тела письма.

Отправка происходит асинхронно, в фоне. Результатом работы процессора на предыдущем этапе является Доставка. Воркер доставки с помощью периодической задачи подхватывает Доставки, который находятся в статусе “ожидание”. В случае успеха, статус меняется на “доставлено”, в случае неудачи по вине провайдера - возврат к статусу “ожидание”.

Единственное исключение по каналам доставки — отправка уведомлений в веб-браузеры.

Отправка в браузер. Сервис Web-сокетов.

Отдельная часть проекта — уведомления пользователей в браузере. Представьте, что у вас открыта страница, где вы работаете с тендерами. Она открыта у вас и ещё у 500 пользователей. Вася добавил новое требование, Петя стёр пару папок — вы хотите оперативно узнать об этом. Но не о каждом чихе, а только о нужных вам событиях.

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

У ребят уже был такой сервис, но больше похожий на прототип: не было аутентификации, сложно добавить новое событие и нужно тратить время на техническую поддержку, а свободных рук нет. Решили добавить эту функциональность в наш сервис уведомлений.

Важное отличие от обычного брокера сообщений — функция контроля доступа. Наш сервис должен проверять, имеет ли пользователь право получить сообщение и доставить только поля, предназначенные для конкретного пользователя.

Система живая — сегодня в исходном событии есть дата создания тендера, а завтра появятся дата окончания и контакты ответственного. В итоговую нотификацию дату окончания тендера добавить надо, а контакты — ни в коем случае.

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

Общая схема сервиса

Чтобы удовлетворить всем этим требованиям, мы добавили в сервис аутентификацию и авторизацию. Перед тем как пользователь сможет подписаться на уведомления, получаем и проверяем JWT-токен. В результате, когда отправляем уведомление, можем проверить, имеет ли пользователь право его получить.

Так же сделали настройку сервиса через конфиг, в котором описано, на какие уведомления можно подписаться, какие параметры нужны для подписки, как исходное событие преобразовывается в уведомления для пользователей, какие уведомления нужно авторизовывать, а какие — нет.

Как делаем из события уведомление для браузера

Сервис написали на асинхронном python. Для работы с веб-сокетами используем библиотеку websockets. Чтоб получать события из RabbitMQ — aio-pika. Код — простой и лёгкий: один инстанс сервиса может обслуживать сотни и даже тысячи одновременных подключений — для наших требований достаточно.

Убедились на тестах, что сервис справится с нагрузкой: написали скрипт, который имитирует действия пользователей — подключается, подписывается, а затем получает уведомления. Проверили на 4 тысячах подключений: всё в порядке — не задыхается у успевает обрабатывать наш поток сообщений. Запустили на самом нагруженном окружении с более чем 5000 пользователями и сервис даже не напрягся. 🚀

Периодическая рассылка новостей - дайджест

Отдельный слой работы с нотификациями — формирование регулярных отчетов. Пользователь выбирает куда хочет получать отчеты и в какие дни. В результате, в назначенный час ему приходит письмо, в котором события сгруппированы по модулям-источникам событий.

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

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

Проверки прав на объекты (контроль доступа)

Отправляя кому-то сообщение о событии, важно перепроверить, что получатель действительно имеет право знать о таком событии. Например, руководитель может спокойно следить за всеми событиями сотрудника, но не наоборот.

Это касается любых уведомлений — от сервиса нотификаций и сервера веб-сокетов до любого другого источника в будущем. При этом права надо проверять именно в момент отправки сообщения, а не когда-то заранее, например, при подписке на объект.

Каждый модуль в системе — законченный сервис со своей жизнью. Внутри себя сервисы знают о правах пользователей на работу с объектами. Чтобы решить нашу задачу, пришлось бы отдельно интегрироваться с каждым модулем и запрашивать права на объект. Вместо этого мы сделали сервис-медиатор. Его роль — прослойка между потребителями данных о правах и источниками этих данных. Это обеспечивает единый контракт для всех сервисов и снижает нагрузку на все остальные модули.

Чтобы получить права, нужно передать данные об объекте: имя модуля, id проекта, тип объекта, id объекта и пользователя. В ответ вы получаете обогащенные данные с правами на чтение или запись.

Сервис принимает сразу пачку объектов, по которым надо проверить права. Он заботливо сходит в каждый модуль, соберет права и вернем вам такую же пачку ресурсов с правами. Повторные запросы кешируются на небольшое время, поэтому это дополнительно разгружает бекенды модулей. Все работает асинхронно и написано на FastAPI.

Мониторинг

Сервис работает стабильно. На самом нагруженном окружении, в день он обрабатывает под тысячу событий и отправляет несколько тысяч email-писем и столько же уведомлений в браузер.

Для технического мониторинга, показатели CPU, RAM, количество тасок — выведены в Graphana.

В среднем нагрузка на процессор — несколько процентов CPU, в пиках доходит до 10% CPU.

Потребление памяти - 1,8 Гбайт.

Потребление сервиса веб-сокетов совсем мизерное:

CPU:

RAM:

Для получения информации о конкретных событиях, на каждом этапе жизненного цикла события мы получаем информацию из django-админки. Выстроенная архитектура позволяет гибко работать с сущностями и выполнять повторные таски в случае инцидентов.

Админка помогла нам расследовать инциденты как по отдельным юзерам, когда кто-то не сделал работу во время и сказал, что «не знал», так и глобальные вопросы с доставками всем пользователям.

Выводы

Кто думает об уведомлениях веб-сервисов как об источнике технической сложности? Дьявол, как всегда, в деталях (требований).

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

Мы сделали этот сервис в плотном сотрудничестве с технарями и продакт-директором заказчика. Почти все схемы-иллюстрации — только части более подробных диаграмм, которые мы готовили в процессе согласования архитектуры с техническим директором клиента и которые стали частью документации, которую мы передали вместе с работающим проектом.

Над проектом работали:

Архитектор — Алексей Чудин

Бекенд, соавтор этой статьи — Николай Кирьянов

Фронтенд — Иван Седов

Менеджер — Анастасия Шаркова

Как мы перезапускали Медицинскую информационную систему

Клиники «Чайка» — это сеть премиальных клиник с отличными врачами, куда можно обратиться с любым вопросом — от сломанной ноги до зубной боли. Для организации работы, они используют собственную МИС (медицинскую информационную систему), которую пилит небольшая команда разработчиков в штате.

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

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

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

Задача и генеральная идея

Сначала нас позвали как консультантов: команда разработки медленно пилила фичи, нанять новых людей было трудно, а те программисты, которых всё-таки нанимали — увеличивали фонд оплаты труда, но не ускоряли существенно разработку нужных бизнесу фичей. Бизнес хотел понять, в чем причина и как эту ситуацию изменить.

До этого проекта, у нас был опыт «технологической трансформации» команд разработки и тогда мы зареклись делать «консалтинг» — это работа, в которой нужно 100% вовлечение технического директора и её сложно делегировать — такой бизнес мы с Федей масштабировать не умеем, а повторять одно и то же, чтобы просто заработать денег — скучно.

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

Существующая МИС решала кучу задач, автоматизируя работу клиник со всех сторон — от ведения медицинских карточек до учёта денег, заплаченных пациентом. Варианта переписать какую-то её часть, временно остановив разработку, как мы сделали в Вебиуме или Снобе, у нас не было — бизнес растёт, и открытие новой клиники в Тбилиси не будет ждать, пока мы перепишем миллион строк с TypeScript на Python.

Всё это осложнялось тем, что медицина — самая сложная доменная область, с которой мы встречались. Каждая, даже самая простая задача в ней, на проверку оказывается верхушкой гигантского айсберга. Взять хранение диагнозов. Казалось бы — одна таблица для пациентов, вторая для диагнозов, выбранных из стандартного справочника, третья для их связи. Но нет. Первичный ли это диагноз? Он уже подтверждён, или это промежуточный результат диффиренцированного диагноза? Его поставил один доктор или коллегия? А может это результат автоматизированного измерения? Актуален ли диагноз сейчас, или это запись из анамнеза? По какому справочнику этот диагноз — МКБ или SNOMED? А если диагноз «перелом», то он где — на руке или ноге? Правой или левой? А куда записать информацию об аллергии?

К счастью, в проекте была сильная продуктовая команда: продакты с медицинским образованием и дизайнер с большим опытом работы над проектом — они были нашими основными партнерами в этой работе.

Архитектура и планы

Текущую разработку замораживать нельзя, так что новый код для бизнес-фич надо писать сбоку. Учитывая, что бекенд написан на чужом для нас стеке (TypeScript), единственное решение — это event-driven архитектура. Пусть текущая МИС будет одной из многих систем в гетерогенной среде, где программы, обслуживающие разные части бизнеса, общаются друг с другом через события. Скажем, сотрудник ресепшн завёл карточку пациента в привычном интерфейсе — система сформировала событие «пациент заведён», обогатила его всеми данными пациента, и положила это в общее информационное пространство — брокер событий. Все другие программы, которым нужна информация о пациентах, слушают, поток событий и заводят пациента у себя. Точно так же передаются данные о новых докторах, диагнозах, операциях, взаиморасчётах и всех других изменениях в системе.

Чтобы не изобретать велосипед, мы построили свою модель данных на основе готового стандарта — FHIR. Кроме прямой пользы — держать данные в едином стандарте, FHIR помогал нам погружаться в доменную область — изучая описание стандарта, легко узнать, что диагнозы надо привязывать к частям тела (диагноз «кариес», часть тела «22 зуб со стороны языка»).

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

AstraShare

Одно дело — красивая архитектура, а другое — реальная жизнь. Найдём ли мы все нужные точки в монолите, которые меняют данные в базе, чтобы генерировать в них события? Сможем ли мы гарантировать 100% доставку этих событий? Найдутся ли у команды монолита силы, чтобы выполнить все наши требования? Сможем ли мы жить в инфраструктуре, которую поддерживают сторонние сисадмины?

Начинать большой проект, не проверив эти риски — глупо: можно влить кучу человекомесяцев, а в конце узнать, что проект никогда не запустится, потому что события 2% случаев просто теряются, и данные о новых пользователях не долетают до всех систем. Мы начали с маленького — решили сделать сервис, который проверял бы все риски интеграции, но не стоил как космолёт. Выбрали AstraShare. Его идея простая — когда врачи Чайки направляют данные пациента в стороннюю больницу или в страховую компанию, можно не печатать сотни страниц истории болезни, а сделать сервис, в котором эти данные можно будет получить в электронном виде, или скачать PDF и распечатать самому. А у нас останется инструмент коммуникации со всеми, кто пользовался этим сервисом и уверенность, что данные получены кем надо.

Сервис мы в итоге запустили за 5 месяцев силами команды из трёх программистов и одного архитектора. Чтобы упростить задачу команде клиента, мы пожертвовали проработкой событийной модели: вместо десятка «удобных» событий «заведён пользователь», «поставлен диагноз», «сделано наблюдение» сделали одно большое событие «медицинская запись изменена», данные из которого уже разбирали в нашей системе. Но даже такое гигантское событие доставлялось плохо — примерно в 0.5% случаев событие не генерировалось. Чтобы понять, насколько это много, представьте, что из вашей карточки в стоматологии с такой вероятностью пропадёт информация о вашей аллергии на обезболивающее.

Для решения этой проблемы, мы дали возможность администраторам переотправлять карточки в сервис. Как бы грустно для программистов это ни звучало, для бизнеса результат был отличный — они получили новый сервис и команду, которая точно знает, что может сделать, а что — нет. Чёткое «нет» от программистов — вообще очень важная штука: гораздо лучше, чем «да», которое превращается в «нет» через полгода, когда клиентам или партнерам уже обещан новый сервис.

Итак, мы убедились, что архитектура работает. Время браться за более сложные задачи! У бизнеса было три основных запроса: улучшение системы биллинга, мета-лаборатория и новый интерфейс стоматологов. Рассказ о биллинге здесь опустим — это довольно скучная (хотя и безумно сложная для новичков) штука, которую мы успешно делали уже много раз. А вот о лабораториях и интерфейсе стоматологов расскажем подробнее.

AstraLab — мета-лаборатория

Чайка работает с несколькими лабораториями, отсылая туда пациентов и забирая результаты анализа. Конечно, эту работу нужно максимально автоматизировать — чтобы клиентам не приходилось таскать справки из лабораторий, а медсёстрам — забивать в систему данные из них, попутно допуская ошибки. В идеале мы выписываем направления на анализы в своей информационной системе и через какое-то время в карточке пациента автоматом появляются результаты анализов, а врач с пациентом получают об этом уведомление.

Любая интеграция такого рода — это сложная задача: другие системы делали программисты со своим представлением о доменной области, о структурах данных и о том, что такое надёжность передачи информации. Одна лаборатория поддерживает FHIR, но с каким-то другим справочником, другая — отдаёт результаты в виде XML-файлов, которые забирает с сервера специальная софтина на винде, у третьей — свой собственный REST API с особым способом аутентификации.

К тому же сразу после запуска сложных интеграций нужно закладывать период в 1–2 недели, когда всё работает нестабильно, а программисты почти в реальном времени правят мелкие несоответствия в форматах данных или протоколах. Это довольно сложно делать на старом монолите из-за длинного релизного цикла: внести одно изменение на проде почти нереально, нужно подсаживать его в «релизный поезд» — пачку изменений, которая уходит на ручное тестирование и будет выпущена только после того, как все фичи из неё будут проверены. В таком режиме даже маленькие исправления могут ждать света дня неделю.

В новой архитектуре у нас получилось реализовать этот модуль отдельным сервисом силами 4 программистов за 6 месяцев.

AstraDental

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

Цель, которую мы ставили с самого начала сотрудничества — сделать удобный интерфейс для врачей. Информационные технологии не сильно поменяли рутину докторов: они как заполняли карточки в 80-х годах прошлого века, так заполняют и сейчас. Правда карточки теперь показываются на экране монитора, а подписи под ними стали электронными. Мы решили это исправить.

Дело в том, что врачи вынуждены заполнять карточки примерно так же, как они хранятся в базе данных: выбрать пациента, указать диагноз, записать текстом наблюдения. То есть удобно для программистов и неудобно для врачей. При этом уже в 60е годы был разработан эффективный формат клинических заметок — SOAP, в котором записи делятся на 4 блока: Subjective (Субъективный), Objective (Объективный), Assessment (Оценка) и Plan (План). Новый интерфейс использует эту же схему, ускоряя заполнение информации, где это возможно.

Внедрить такую систему «на живую» очень сложно: медицинские карточки — это сердце МИС. Чтобы не переписывать всю работающую систему без необходимости, мы выбрали небольшой, и по совместительству самый интересный кусок работы — стоматологов.

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

Дизайнеры Астры выстроили удобный интерфейс для докторов на основе зубной формулы:

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

Для обеспечения бесшовности, мы придумали, как быстро встроить свой фронтенд в существующий. Для этого существуют несколько инженерно красивых решений вроде микрофронтендов, но в нашем случае, результат нужно было показать как можно быстрее, поэтому решили не пилить свой фронтенд сбоку, а поработать в текущем, то есть отложить в сторону любимый vue.js и поработать с react.

Такое решение, хоть и позволило нам на первых порах ускориться, стоило очень много нервов — уж очень тяжело было приносить свои стандарты разработки в текущую команду. Самой острой проблемой стали линтеры — ребята предпочитали много правил держать в голове, а мы привыкли к максимально жёстким линтерам, которые гарантируют исполнение договоренностей. Вторая проблема — это релизный цикл: старый фронт живёт с релизными поездами, с которыми мы работать не привыкли и честно говоря не готовы. Здесь приняли довольно тяжёлое решение — в старом проекте релизные поезд пусть ходят как есть, а весь наш код едет напрямую в продакшен. Получилось, что мы работаем по привычному gitflow, а штатные ребята — недельными релизами. Конечно, изменения, затрагивающие общий код, мы прогоняли через поезда, но всё равно, продакшн мы разочек положили. Не делайте так.

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

Финал

В результате, мы запустили несколько классных сервисов, закрыли несколько горящих задач бизнеса. Но большая цель: «получить такую техническую часть проекта, такую команду, которая будет предсказуемо и быстро решать задачи бизнеса» — осталась нерешенной.

Для нас такое завершение сотрудничество было ударом. Представьте, что вы посвятили полгода своей профессиональной жизни на проект, который приходится закрыть. У нас нет претензий к заказчику — произошел форс-мажор.

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

А что насчет ускорения проекта? Можно ли было успеть достичь «большой цели» быстрее? Конечно да. Можно было рискнуть и начать разработку большого сервиса не проводя полноценный тест на маленьком. Можно было ещё больше напрячь продуктовую команду и запустить больше проектов в параллели. Все эти шаги увеличили бы риски проекта выше комфортных для нас и для заказчика.

Вывод

Если же сделать шаг назад и вспомнить о «генеральной гипотезе», что технологическую трансформацию бизнеса проще реализовать, приведя с собой небольшую, но супер высококвалифицированную команду разработки и внедряя изменения её руками — то тут мы считаем, что эта гипотеза в целом оправдалась. Прямо сейчас мы запускаем ещё один подобный проект. Надеюсь, что в этот раз мы сможем довести его до конца.

Если вам нужна подобная помощь или просто классная разработка — пишите Самату Галимову @samatg.

Технические директора:
Фёдор Борщёв
Самат Галимов

Архитектор:
Антон Давыдов

Бекенд-программисты:
Вячеслав Набатчиков
Денис Сурков
Алексей Чудин
Эдуард Степанов
Николай Кирьянов
Даниил Мальцев
Владимир Войтенко
Анна Агаренко

Фронтенд-программисты:
Александр Нестеров
Алексей Богословский
Владимир Тарановский
Тимур Брачков
Михаил Бурмистров

Менеджеры:
Анастасия Шаркова
Ксения Сафронова
Иван Борисов
Дарья Львова

Сотрудники заказчика:
Алена Салкова
Александр Скоромнюк
Александр Климов
Валентин Раншаков
Виктор Косарев
Вячеслав Ключников
Денис Турьяница
Дмитрий Верижников
Дмитрий Зозулин
Дмитрий Афанасьев
Дмитрий Панов
Мария Чистова
Павел Власенко

Почему я не люблю GraphQL

Будучи разработчиком, я не любил GraphQL с самого его появления — из-за ноды, привязки к Apollo, отсутствия APM (если не покупать подписку у Apollo) и сложного, вложенного языка запросов. В принципе до сих пор ничего изменилось, но в этом посте я хочу отдельнло поговорить о своей любимой теме – тестировании.

GraphQL замечательно умеет делать одну вещь: вытаскивать данные с сервера в произвольном формате, удобном в каждый конкретный момент. «Выгрузи мне все книги — название, количество страниц, пару интересных цитат и автора, а у каждого автора покажи ФИО, фотографию и список популярных произведений» — это типичный запрос для GraphQL, с которым он справляется идеально. В REST для такой специфичной выборки пришлось бы писать отдельный эндпоинт, следить за ним и поддерживать. А тут даже кода писать не надо — один раз описал схему данных, и всё работает из коробки.

Минус в том, что вместо понятного набора эндпоинтов с заранее определённым поведением, мы получаем один эндпоинт на все наши данные. Тестировать такой эндпоинт очень больно. Первая проблема –  контракт между бекендом и фронтендом: раньше мы могли написать батарею юнит-тестов, которые проверяют все возможные запросы, аутентификацию и авторизацию, а затем копипастить их для разных эндпоинтов, добавляя локальную специфику. Тесты для GraphQL так не могут — мы же не знаем, что у нас запросят в каждый конкретный момент, а значит не можем написать тесты, которые отражают реальность. Остаётся только делать тесты для типичных запросов, и надеяться, что когда фронт или бек что-то поменяет, программисты сами договорятся и друг-другу ничего не сломают.

Сложно тестировать не только контракты, но и прозводительность. Раньше мы для каждого эндпоинта могли предсказать количество тяжёлых запросов с джоинами, и даже ограничить их количество в тестах или в рантайме (по ссылкам питон, в вашем стеке будут другие инструменты). Теперь мы каждый раз не знаем, что у нас запросят, а значит можно выгрузить хоть всю базу за один запрос.

Конечно, есть бизнесы, которые выигрывают от умения отдавать по 20 сущностей на один запрос, и делают это своей core-ценностью — к примеру облачные BaaS или высокоуровневые headless CMS вроде Sanity. Но если вам надо просто отдавать на фронт десяток известных сущностей, даже если вы планируете добавить в будущем ещё пару десятков — скорее всего GraphQL обойдётся вам намного дороже чем обычный REST, потому что с самого старта вам придётся тратить намного больше сил на тесты.

LMS для Школы Сильных Программистов

У Школы Сильных Программистов была небольшая LMS. Делать её решили потому, что принятый в индустрии Getсourse превращает редактирование уроков в мучение (в школе привыкли писать и редактировать в Notion), а пафосные опенсорсные LMS вроде moodle годились для чего угодно, кроме обучения взрослых людей. К тому же почти во всех курсах внедрена сложна фича, которую не найти в готовых продуктах — p2p-проверка домашки, когда одни студенты смотрят и ревьюят работу других: это экономит время экспертов и здорово повышает доходимость.

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

Решили, раз уж все гипотезы доказаны, просто переписать всё без новых фич, но с нестыдным кодом. Сформулировали вот такую задачу:

  • Нормальный код покрытый тестами
  • Хороший дизайн и UI-kit
  • Удобная мобильная версия для чтения на ходу

Старт

Для старта работ у нас было:

  1. Бекенд на Django, покрытый тестами
  2. Код текущего фронтенда LMS
  3. Большой пост с описанием функциональности

Старый код рефакторить было бесполезно, так что решили выкинуть всё и написать всё с нуля, ориентируясь на пост с постановкой задачи. Причин для такого решения было две:

  1. Писать хорошую дизайн-систему с нуля проще, чем рефакторить старую
  2. Cтарая LMS была написана на Vue 2, а в то время уже вышел Vue 3, в котором появилась поддержка Typescript, а ещё крутой туллинг в виде Vite и Pinia

С решением не ошиблись, получилось быстро и круто.

Редизайн LMS мы решили делать прямо в коде. Используя старую LMS как вайрфреймы, мы собрали все страницы внутри Storybook на мокнутых данных из фейкера.

Чтобы дизайн был консистентным и не отнимал много времени, мы взяли Tailwind — его атомарность позволяла быстро примерять разные варианты, а токенизированность упрощала создание компонентов в единой стилистике.

Материалы

Материалы для LMS пишутся в ноушене и отдаются на фронтенд через хитрое API. Бекенд нужен, чтобы контролировать доступ к материалам, кешировать их (чтобы грузилось быстрее, чем в самом ноушене) и немножечеко его менять, чтобы было просто рендерить на фронте.

На фронтенде материалы рендерятся в удобном интерфейсе: пригодном для чтения, с хорошо натсроенным шрифтом и с тёмной темой, Таким образом редакторы пользуются удобным и привычным текстовым редактором, а ученики читают материалы в интерфейсе школы.

Забегая вперёд: такое решение — единственная сложная часть LMS. Реализации рендеринга на Vue печальные: одна очень плохо написана, а другая редко обновляется. Сейчас мы форкнули удачную реализацию и обновляем её сами (к счастью, ноушен ничего не меняет, поэтому это не много работы).

Почему просто не использовать маркдаун? Маркдаун нужно уметь писать, а курсы в школе пишут не только программисты. Кроме того, наладить простое (git — это не простое) совместное редактировние текстов в маркдауне — тяжёлая задача.

Домашки

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

Ответы на домашку ученики пишут в удобном WYSIWYG редакторе. Редактор собран на основе tiptap. Чтобы оживить общение между студентами, мы добавили возможность оставлять реакции.

Профиль студента

По окончании каждого курса школа выдаёт кайфовый диплом: можно положить в LinkedIn, добавить в резюме или просто повесить на стенку. Чтобы в диплом было вписано корректное имя пользователя, мы сделали раздел «профиль», где студенты заполняют свои данные На странице настроек ученик управлет своими данными, а также указывает информацию, которая появится на дипломе.

К моменту работы над этой страницей уже скопилось достаточно полей, которым нужна была валидация. Делать хорошую валидацию сложно и долго, а делать среднюю — просто долго. Хотелось найти вариант, над которым не придётся думать, но при этом он будет точно понятен пользователям.

На бекенде уже была сделана хорошая валидация с понятными текстами ошибки. Чтобы забыть про валидацию на фронтенде раз и навсегда ответы с бекенда в выводятся в тосты. Перехват ошибок делается на уровне axios и все ошибки ловятся автоматически, без использования try … catch.

Релиз и что дальше

От старта до готовности к релизу прошло три месяца. Чтобы не релизить в праздники, мы решили потратить декабрь на дополнительные фичи, а после нового года выкатили её для всех учеников.

Релиз прошел плавно. В том, что так будет, мы были уверены — код был хорошо покрыт тестами.

Дополнительно убедиться в том, что новые фичи не развалили все прямо перед релизом, помогали тесты на визуальный регресс. Они сравнивают скриншоты актуального интерфейса с тем, как он выглядит в мастере, и показывают различия если что-то поменялось. Чтобы написать такой тест, нужно добавить историю в Storybook и написать тест который ходит туда через Playwright, делает скриншот и сравнивает его. Через такой такой тест не пройдут ошибки, затрагивающие рендер, в том числе ошибки на уровне CSS.

Код проекта открытый. Посмотреть можно на гитхабе.

Технологии: vue3, pinia, vitest, playwright.

Разработчик и автор статьи: Тимур Брачков.