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

Продолжаем рассказывать об интересных проектах студентов ФИИТ. В этот раз речь пойдёт о приложении для интерактивного мониторинга белых акул по заказу Стэнфордского университета. ? В статье ребята рассказали, какие возможности реализовали внутри приложения, какой стек технологий выбрали и что за сложности случились на фронтенде и бэкенде.

Что это за приложение и зачем оно понадобилось

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

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

У института океанологии Стэнфордского университета уже была подобная система. Она позволяла получать необработанные данные о перемещениях акул, но работала очень медленно — одна выгрузка занимала около 30 минут, а в результате пользователь получал файлик с кучей непонятных полей. Среди данных была и история перемещения акул в виде списка координат. Пользоваться этим было очень сложно. Интерактивная карта тоже уже была, но нам нужно было реализовать её в более красивом и удобном виде. 

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

Все задачи разделили на несколько стеков:

• Бэкенд-разработка. Здесь работы было больше всего, поэтому мы позвали на проект двух бэкендеров. Технологии выбрали такие:

  • Python — основные компетенции команды по написанию бэкенда были именно на этом языке.

  • Django — идеально ложилась на задачу «Сделать MVP бэкенд с админкой». Мы использовали асинхронную версию.

  • Managed Postgres — это было самое подходящее решение для нашей задачи. Сразу с репликацией.

  • Авторизация через встроенные в Django механизмы. Мы также сделали сброс пароля через подтверждение кодом на почту. А ещё добавили авторизацию через Google, для удобства даже сделали автоматическое объединение одинаковых аккаунтов одного пользователя.

• Фронтенд-разработка. В техническом задании был указан Flutter, и, исходя из обсуждений с заказчиком, которая знала про технологии оплаты, пришли к выводу, что Stripe будет наиболее просто и быстро внедрить для MVP. Фронтендер у нас был один.

• На мобильную разработку и дизайн тоже выделили по одному человеку — этого было достаточно.

• Также взяли в команду проектного менеджера — нужно было связующее звено между разработчиками и Стэнфордским университетом.

Рабочий процесс мы выстроили спринтами по две недели. Каждую неделю проводили общие командные синки и персональные созвоны чтобы решать точечные задачи. Задачами управляли в трекере YouTrack.

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

Теперь подробнее обо всех этапах.

Написали архитектуру

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

Архитектура БД тоже не была сложной, потому что к моменту разработки мы чётко понимали, какие сущности будут в проекте: акулы, карта, новости, пользователи. 

Создали прототип дизайна 

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

Реализовали бизнес-требования

Это начали делать сразу после согласования прототипов и написания архитектуры. 

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

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

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

Как создавали регистрацию и авторизацию пользователей

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

Ещё мы внедрили возможность объединять аккаунты: пользователи, которые зарегистрировались через почту Gmail, могли войти через Google.  Восстановление пароля реализовали привычно — кодом из письма. 

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

Как внедряли функцию донатов

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

Для донатов мы выбрали систему интернет-платежей Stripe — для рынка США это очень привычная и популярная платформа, к тому же её легко интегрировать. 

Когда механизм донатов заработал, мы его протестировали, моментами было забавно: Stripe предлагал тестовые карточки с большим балансом, так что в какой-то момент у всех акул стало много денег.

Какие сложности были 

Во время работы над проектом мы выделили два основных кризисных момента: на бэкенде и на фронтенде. 

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

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

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

Чтобы решить проблему, нужно было аккуратно изменить версии внутренних зависимостей и отредактировать несколько конфигов. С первым мы могли справиться, а со вторым боялись из-за неопытности что-то сломать, поэтому позвали эксперта по Flutter. С ним за один созвон отредактировали все конфиги, и вечером того же дня пакет Stripe уже нормально работал. 

Что получилось в итоге

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

Если остались вопросы по этому проекту и нужны подробности, готовы рассказать больше в комментариях!