Uber-like приложения стали популярны в последние годы, в связи с небывалым ростом количества стартапов. Такие приложения называют поколением “Uber for X”. Такое название отсылает к одноименному приложению, которое несколько лет назад стало предоставлять инновационный сервис по заказу такси и поэтому стало очень популярным.
Весь 2018 год мы работали над приложением для Uber-like стартапа, который в конце года превратился в очень успешный бизнес в своей области, запустившись лишь в августе того года. Это был очень значимый и интересный опыт разработки для нашей компании.
Американская компания GoTrashy обратилась к нам в феврале 2018 года с проектом под названием GoTrashy 2.0: нам было необходимо оптимизировать и заменить существующую систему GoTrashy 1.0, которая уже какое-то время работала.
Система напоминает уже известный нам всем сервис Uber, только здесь доставляется мусор грузовиками. Клиент создает заказ с фотографиями мусора, а грузовик приезжает, чтобы его вывезти. Начало проекта было довольно интересным:
Поскольку существующая версия приложения нуждалась в сильных доработках, мы решили сжать сроки разработки новой версии до 9 месяцев, чтобы заменить приложение в максимально сжатый срок. Это решение повлияло на другие моменты разработки, например, в качестве платформы был выбран кросс-платформенный React Native.
Новая система была более многокомпонентной, чем первая и состояла из следующих частей:
Все части системы должны были четко работать вместе, поэтому для их разработки мы применили следующие практики и технологии:
В качестве потенциальных мы рассматривали два типа архитектур: монолитную и микросервисную. Применение монолитной архитектуры было дешевле, проще и быстрее, а также требовало меньше поддержки после запуска. Однако после того, как мы приняли во внимание потенциальный рост бизнеса у нашего клиента, мы поняли, что монолит не настолько гибок и масштабируем.
Поэтому мы решили использовать микросервисную архитектуру на базе AWS. Вопервых, она позволяла нам иметь несколько атомарных сервисов вместо одного бэкэнда, а во-вторых, изменения в одном сервисе, в худшем случае, привело бы к поломке только его, а не всей системы.
Более того, мы использовали Elasticsearch для индексирования данных, поскольку стек технологий ELK (Elasticsearch, Logstash, Kibana) уже интегрирован в AWS. Это дешевле и быстрее, чем копирование данных в Postgres и дальнейшая сортировка их там. Выбранный стек технологий позволил нам настроить автоматическую миграцию данных из старой системы в AWS.
GoTrashy 1.0 был разработан на чистых платформах iOS и Android, поэтому нам было необходимо решить, будем ли мы продолжать такой подход или перейти к кросс-платформенному фреймворку.
Применение кросс-платформенного фреймворка нам подходило по нескольким причинам:
В дополнение кросс-платформенный фреймворк имел преимущества, которые мы могли выгодно использовать для GoTrashy 2.0:
Приняв всё это во внимание, мы решили вести разработку GoTrashy 2.0 на React Native. Также мы решили соединить его с Expo framework, который бы позволил нам одномоментно обновлять приложения в сторах по воздуху без непосредственного взаимодействия с каждым с них.
На момент разработки в 2018 году Expo framework был довольно сырым продуктом, поэтому взаимодействие с поддержкой, настройка и тестирование отняли у нас драгоценное время. Однако мы все равно выиграли при его применении, поскольку обновление по воздуху перевешивало все неудобства.
В GoTrashy 1.0 использовался Twilio для отправки сообщений, поэтому мы решили также использовать его при разработке мульти- и одноканальных чатов для клиентов и водителей-перевозчиков.
Twilio обрабатывает сообщения через свои сервера и посылает их получателю. Однако когда мы начали работать с Twilio, оказалось, что нам нужен фильтр контента в чатах, а его сервис не предоставляет. Поэтому данную функциональность пришлось доработать и интегрировать самостоятельно.
Таким образом, мы стали фильтровать потенциально оскорбительные или неподходящие фотографии, бранные выражения и нерелевантную информацию (например, адрес клиента) до начала работ по заявке.
В процессе работы мы столкнулись с еще одним ограничением Twilio – лимит канала. После того, как работа считалась оконченной, мы не удаляли чаты между клиентом и водителем, чтобы Служба Поддержки GoTrashy могла обратиться к ним в случаях жалоб. Довольно быстро это привело к переполнению лимита. Мы справились с проблемой следующим образом:
Разрабатывая GoTrashy 2.0, мы придерживались подхода DevOps. А именно:
Этот проект включил в себя API сервис, три веб-приложения, две версии мобильных приложений. В процесс разработки было включено около 20 человек. Каждые 2 недели был запланированный релиз, таким образом DevOps подход справился с необходимой скоростью разработки и уровнем качества.
Такой подход очень подходит, когда дело касается стандартизованной инфраструктуры разработки, автоматического тестирования и релизов, а также сокращения времени реакции на ошибки и время на её исправление.
Мы зарелизили систему в августе 2018 года в AppStore и Google Play. Работа над приложением продолжалась вплоть до ноября 2018, поскольку компания решила внести ряд изменений после анализа поведения клиентов.
На настоящий момент GoTrashy 2.0 находится в стадии поддержки. Мы помогаем клиенту с любым вопросом : большими и маленькими изменениями, новой функциональностью или доработками. Мы разработали большую Uber-like экосистему в довольно короткий срок, приступая к разработке которой мы крайне мало знали о первой версии проекта.
GoTrashy – удивительный пример стартапа, который не остановился в развитии после запуска. Компания проанализировала ошибки, допущенные в первом релизе, чтобы не допустить их повторения. Мы очень рады, что нам удалось поработать с таким проектом!