Нам не хватает приложений получить что-то откуда-то сейчас: Deliveroo, Uber Eats, Grindr, Tinder и многие другие. Приложения такси тоже огромны, и это стало довольно серьезным бизнесом. Uber уже некоторое время работает над беспилотными автомобилями, а Daimler (Mercedes-Benz), пионер технологии автономного вождения, на самом деле владеет mytaxi, европейским приложением такси, которое объединилось с британским стартапом Hailo. Здесь, в Лондоне, есть из чего выбирать: Gett, TaxiApp, Kabbee, Taxify и даже старые Addison Lee.

Так зачем создавать еще одно приложение такси? Я хочу посмотреть, что для этого потребуется. Создав несколько мобильных приложений и поработав над масштабируемыми веб-платформами, я знаю, что это нечто большее, чем создание прототипа в качестве побочного проекта. Но что, если мы можем упростить концепцию, чтобы практически не требовать текущих затрат? Работая на AWS как можно более «бессерверным», мы можем свести код к минимуму, нам не нужно будет платить, когда он не используется, и он должен прекрасно масштабироваться, если когда-нибудь понадобится. Чтобы показать, как это работает, мы можем сделать все это на открытом воздухе.

Мы назовем его OpenTaxi.

Эта серия статей проведет нас через процесс прототипирования: проектирование, архитектуру и кодирование; включая макеты, шаблоны развертывания, исходный код (Python и JavaScript) и ссылки на инструменты/документацию, которые мы использовали.

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

Если вы хотите узнать больше, перейдите к Часть 2 — Подключение пассажиров к водителям.

Концепт

Нам нужно упростить, поэтому:

  1. Мы разрешаем использовать только лицензированные такси. Это позволяет избежать проблем с безопасностью и властями. Как правило, им нужно показать свое свидетельство о лицензии на такси в окне, и водители могут проверить это, прежде чем сесть в машину. (Это должно быть не менее безопасно, чем лицензированные такси, подбирающие людей на улице.)
  2. Все, что вам нужно, это номер мобильного телефона для входа в систему. Мы можем подтвердить номер с помощью SMS, что означает, что пользователю не нужно запоминать пароль, и у нас всегда есть подтвержденный номер мобильного телефона водителя и пассажира.
  3. Мы не принимаем оплату. Лицензированные такси уже могут принимать оплату.

Картинка стоит тысячи слов, поэтому давайте начнем с некоторых каркасов приложений:

Райдер Флоу

Это было бы очень похоже для новых регистраций и вернувшихся гонщиков.

Мы предоставим гонщику возможность фильтровать способ оплаты. (Лицензированные такси в Лондоне должны в настоящее время принимать платежи по картам, но их карточные автоматы все еще иногда сломаны. 🙄)

Поток водителей

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

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

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

Я думаю, что этого достаточно для нашей работы.

Архитектура

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

Мы уже говорили, что хотим использовать AWS «насколько это возможно без сервера». Я не собираюсь составлять исчерпывающий список всех преимуществ этого подхода, но вот некоторые соображения:

  • Производительность и масштабируемость. Пока мы избегаем единых точек отказа и строим с использованием компонентов без сохранения состояния и проверенных масштабируемых сервисов, нам не о чем беспокоиться.
  • Безопасность. Используя AWS IAM для ограничения доступа к ресурсам и службам с высокой степенью детализации и всегда предоставляя наименее разрешительные привилегии, мы можем снизить вероятность создания уязвимостей в нашем исходном коде. В основном полагаясь на централизованную настройку, элементы управления становятся более прозрачными, а экстренные ограничения могут устанавливаться динамически.
  • Слабая связь. Мы будем использовать асинхронные шаблоны там, где это уместно, и предполагать возможную согласованность везде, где это возможно.
  • Доступность и надежность. Это становится вопросом конфигурации для большинства баз данных и сервисов AWS, но его все равно необходимо учитывать заранее.

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

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