Главная » Хабрахабр » [Из песочницы] История рождения онлайн сервиса поиска и букинга авторских путешествий по всему миру: слово от разработчика

[Из песочницы] История рождения онлайн сервиса поиска и букинга авторских путешествий по всему миру: слово от разработчика

С чего все начиналось
Идейные муки
Технологии и как они не однозначны
Как хранить и где?
Не только хранить, но и искать
Это загадочное SEO
CDN наше все
Подытожим

С чего все начиналось

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

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

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

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

Идейные муки

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

Данные инструменты не давали нам возможности быстро и гибко отвечать поставленным вызовам. При старте, багаж технологий у нас был не очень jQuery и C# (которые мы использовали в наших предыдущих проектах). Наш выбор пал на Angular 2 и Node.js. Благо мы уже рассматривали новые подходы как для клиентской, так и для серверной разработки. Данное решение нам позволило быстро формировать компоненты и модули, которые мы могли видоизменять в кратчайшие сроки (в день мы могли переделывать их по два три раза).

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

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

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

Что же это?

Представьте, вы опытный путешественник, который объездил много интересных мест по всему миру и очень хочет поделиться своим опытом, ну и деньжат заработать. Если сформулировать кратко, то это UBER для путешественников. И этих людей надо как-то объединить. А с другой стороны турист, который устал от Турецкого отдыха с лежанием на пляже и поеданием и выпиванием. Вот мы и решили помочь этим людям найти друг друга.
Сервис представляет собой маркет, где опытные туристы могут зарегистрироваться, чтобы спроектировать свои туры и предоставить их для широких масс будущих путешественников.

Технологии и как они не однозначны

Как хранить и где?

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

Данный сервис помог решить нам вопросы хранения данных, хостинга, сервиса аутентификации, стореджа для хранение статических данных. Таким образом в процессе поиска было найдено решение, которое покрыло все наши требования, это был Firebase Realtime Database. Но и самое крутое, что мы получили — это RealTime Database из коробки. Плюс данный сервис находится под крылышком у Google, что в свою очередь дало нам приятные бонусы, так как предоставляло отдельные библиотеки для работы с Angular 2 и это было удобно и быстро. Первые наши ощущения были просто фантастическими.

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

Не только хранить, но и искать

И вот как только была готова первая бета возник вопрос в фильтрации данных, и мы осознали первые минусы в Firebase. Как оказалось, процесс выборки данных по большому количеству условий, просто не поддерживается. Есть возможность, отбирать данные только с одним условием, либо собирать несколько значений в одно поле и потом по нему выполнять фильтрацию. Данный подход нас не устраивал, и мы опять приступили к поиску решения.
Конечно, отказывается от Firebase мы не стали, так как этот один минус не перекрывал ту массу достоинств, предоставляемых этим сервисом. Благо, у нас был опыт использования Google Big Query, который мы получили в процессе наших изысканий, и мы решили его применить. Первый плюс то, что это Google, второй — родные и любимые SQL запросы ну и дешевизна владения 1TB данных в месяц бесплатно.

Забыл сказать, про бек в Firebase тоже позаботились, вы можете писать собственные триггеры на Nodejs и вешать их на любое событие в базе данных, а так же на http запрос. Снова все стало ясно и понятно, написали сервис отправки данных и успешно прикрутили его к Cloud Function.

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

Такие требования заставили нас отказаться от Big Query и искать что-то новое. Не успели мы расслабится и спокойно продолжать создавать наш сервис, как началось тестирование фокус группой, и мы осознали, что пользователи привыкли очень быстро переключать фильтры и хотят сразу видеть результат их работы. Тут их конечно не за чем ругать, так как сервис этот предназначен для обработки больших объемов информации, а не для быстрой реакции на кучу последовательных запросов. Так как Big Query нам давал скорость ответа максимум 2 секунды и это при минимальном объёме данных.

Данный продукт позволил нам построить быстрый поисковый движок, наша фильтрация стала отвечать требованиям наших пользователей. В результате мы остановили свой выбор на Elastic Search. Единственное, что хочу отметить, для данного продукта нужна виртуальная машина, которую надо где-то хостить. Тут много рассказывать не буду, так как данный продукт стал набирать популярность и информации по нему достаточно. Сконфигурировать ее так же просто используя ресурс bitnami. Данную возможность предоставляет как Google так и Microsoft, так что выбор за вами. Мы для себя выбрали Azure, данный выбор был не столько из-за технологических особенностей, а больше из-за сторонних факторов).

Это загадочное SEO

И вот сервис обкатывается, платформы осваиваются и все вроде хорошо, стремимся к светлому будущему. Но, тут возникает вопрос продвижения нашего сервиса и ключевой вопрос SEO. Никогда не мог подумать, что этот вопрос может быть настолько не проработанным со стороны создателей Angular. Как оказалось, Single Page Application очень слабо предоставляет эту возможность, а если сказать честно — вообще не предоставляет. Да, вы можете зашить статические данные в мета теги и при обходе краула или при шаринге выдавать одну и ту же информацию, ну это будет как-то неправильно и безрезультативно. Прошерстив просторы интернета, мы наткнулись на такой чудесный сервис, который входит в состав Angular 4, Angular Universal. Почитав описание, мы поняли, что это то что нужно и что зря мы ругали разработчиков framework’а.

Первая конфигурация чистого проекта прошла отлично, благодаря мануалам в интернете, и вроде все завелось. Началась эпопея с прикручиванием данного счастья к нашему проекту, замечу, на этот момент было уже написано порядка 10 крупных модулей и использовалось примерно 12 сторонних npm пакетов. Ну а теперь надо ж и боевой код пробовать, и тут появились проблемы. Причем серверную часть мы крутили все на том же Cloud Function от Firebase. Первое, как оказалось все сторонние npm пакеты должны поддерживать Angular 4, в коде на серверной части нельзя использовать переменные window, document и т.д., ну и отладить это все счастье просто не реально.

Скажу одно, мы его так и не побороли, не знаю или до конца не поняли или просто он еще сыроват и не готов к продуктивному использованию. Я не буду описывать все наши муки, с этим сервисом, так как это было много и больно. В результате, был написан сервис, который слушает все http запросы и при запросе index.html возвращает его, но перед этим, подкидывает в него необходимые мета теги. В целом решать вам, может у кого и получится, но мы решили на этом остановиться. Кстати, хостим мы все это тоже на Azure по все тем же сторонним факторам. В результате получилось хорошо и уже 3 месяца полет нормальный.

CDN наше все

Вот и снова некоторое время стабильности, и относительно спокойной работы. И не кто не думал, что сюрприз нас ждет со стороны Facebook. В один прекрасный день оказалось, что шаринг в FB не работает. Сначала мы думали, что это связанно с ужесточением политик безопасности в FB, потом с блокировкой IP, но так причины мы и не нашли. Обращались в поддержку как FB так и Firebase, но каждый пинал на другого.

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

Подытожим

На данный момент мы уже в продуктиве 3 – тий месяц, постоянно ведем улучшение и расширение функционала. Для управления версиями конечно же используем Git, понемногу автоматизируем сборки и деплой. В день получаем порядка 450 новых уникальных заходов, бывают скачки до 1000 пользователей. И все это работает.

Что бы хотелось просуммировать из всего сказанного:

  1. Не надо пытаться за счет одного сервиса или одной технологии решать все задачи, которые появляются у вас в проектах.
  2. Старайтесь разрабатывать универсальные модули для большей гибкости в будущем.
  3. Выбор поставщика облачных сервисов вопрос сугубо личный, так как в целом все они предоставляют одинаковый набор сервисов. Остается вопрос в цене и ваших предпочтениях.
  4. Разрабатывайте свое решение так, чтобы иметь возможность мигрировать между разными поставщиками сервисов и технологиями или хотя бы продумывайте стратегию возможного переезда.
  5. Ну и не бойтесь экспериментировать.

Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Сетевой дайджест: 20 экспертных материалов о протоколах, стандартах и информационной безопасности

В эту подборку мы включили свежие посты, подготовленные специалистами компании VAS Experts. Главные темы подборки — сетевые протоколы, 5G и информационная безопасность. Под катом вы также найдете ряд рекомендаций по построению сетей операторов связи. / Pxhere / PD Про ИБ ...

[Перевод] Забудьте о мегаструктурах инопланетян: новые наблюдения объясняют поведение звезды Табби одной только пылью

Художественное изображение KIC 8462852, яркость которой за последние несколько лет менялась необычным образом Когда планета проходит перед её родительской звездой, если смотреть с нашей точки зрения, часть света звезды на некоторое время исчезает. Научная охота за планетами в XXI веке ...