С чего все начиналось
Идейные муки
Технологии и как они не однозначны
Как хранить и где?
Не только хранить, но и искать
Это загадочное SEO
CDN наше все
Подытожим
С чего все начиналось
Я хочу поделиться нашей полугодичной историей создания онлайн сервиса поиска и букинга авторских путешествий по всему миру. При создании данной стати ставилась цель рассказать об опыте создания собственного решения с нуля и теми проблемами, и вызовами, с которыми мы столкнулись на этом пути, так что не судите строго.
Начну с того, что это за сервис, и зачем нужно было его создавать. Долгое время наша команда работала над различными крупными проектами для бизнес клиентов. Это порталы для банков, предприятий, крупных холдингов, а также системы документооборота. Естественно, работа с таким сегментом предполагает удовлетворение узкого круга заинтересованных сотрудников и не всегда заканчивается долгим и успешным использованием.
Причин этому несколько: непонимание проекта на начальной стадии, желание сэкономить и получить максимальную комплектацию, изменение требований на конечном этапе без каких-либо пересмотров сроков и бюджетов. Как вы можете понять, удовлетворение от проекта с обеих сторон, после таких условий, добиться очень сложно.
Так вот, после всего этого опыта, решили мы попробовать себя на масмаркете, где фидбек от клиента молниеносный, интерес к продукту ты понимаешь максимально быстро и видишь использование твоего сервиса каждый день.
Как оказалось, на этом наши спокойные дни закончились!
Идейные муки
Первое что надо было сделать это придумать идею, что же мы хотим предоставить такого полезного, чего нет на рынке и что будет воспринято и ожидаемо. Таких проб у нас было несколько и в течении первых двух месяцев мы занимались экспериментами для нахождения того самого будущего. Как вы можете понять с технологиями тоже была проблема, так как надо в кратчайшие сроки делать функционирующие макеты, проверять их на работоспособность и постоянно усовершенствовать или переделывать заново.
При старте, багаж технологий у нас был не очень jQuery и C# (которые мы использовали в наших предыдущих проектах). Данные инструменты не давали нам возможности быстро и гибко отвечать поставленным вызовам. Благо мы уже рассматривали новые подходы как для клиентской, так и для серверной разработки. Наш выбор пал на Angular 2 и Node.js. Данное решение нам позволило быстро формировать компоненты и модули, которые мы могли видоизменять в кратчайшие сроки (в день мы могли переделывать их по два три раза).
Пришли к тому, что каждый компонент должен быть максимально маленьким и интегрируемым в другие компоненты и модули. Таким образом в процессе экспериментов мы накопили достаточно шаблонов, из которых можно было собирать различные работающие макеты.
Но если с инструментарием мы разобрались достаточно быстро и в бою все больше прокачивали свои скилы (сразу замечу, гугл вам в помощь, но и не забывайте про видео уроки), то возник еще один вопрос, где же хранить данные. Но об этом я расскажу немного позже, а теперь вернемся к самой идее.
Основной вектор нашего сервиса мы нацелили на организацию путешествий, вы сразу скажете, что в наше время существует куча сайтов и сервисов для путешествий, плюс такая же куча тур агентств и я с вами соглашусь. Но, вопрос в том, как поменять отношение среднестатистического туриста к отдыху и дать ему возможность получить максимальный набор впечатлений и почувствовать индивидуальный подход к себе любимому.
Мы понимали, что такие амбициозные планы нельзя решить одним сервисом или каким-то одним решением, но всегда надо с чего-то начинать. И вот, утвердившись с главной целью, мы начали искать тот первый кирпичик, который послужит фундаментом нашего будущего решения. После долгих поисков у нас родилась идея сервиса, о котором теперь и хочу рассказать.
Что же это?
Если сформулировать кратко, то это UBER для путешественников. Представьте, вы опытный путешественник, который объездил много интересных мест по всему миру и очень хочет поделиться своим опытом, ну и деньжат заработать. А с другой стороны турист, который устал от Турецкого отдыха с лежанием на пляже и поеданием и выпиванием. И этих людей надо как-то объединить. Вот мы и решили помочь этим людям найти друг друга.
Сервис представляет собой маркет, где опытные туристы могут зарегистрироваться, чтобы спроектировать свои туры и предоставить их для широких масс будущих путешественников.
Технологии и как они не однозначны
Как хранить и где?
Как я уже писал, после выбора инструментария для создания сервиса, возник вопрос выбора хранилища данных. Конечно, за многие годы мы привыкли к реляционным базам данных и к SQL Server, в частности. Но, необходима была платформа для минимальной конфигурации при старте и минимуме усилий при дальнейшей поддержке, а также возможности масштабирования в процессе развития нашего сервиса и росте посетителей.
Таким образом в процессе поиска было найдено решение, которое покрыло все наши требования, это был Firebase Realtime Database. Данный сервис помог решить нам вопросы хранения данных, , сервиса аутентификации, стореджа для хранение статических данных. Плюс данный сервис находится под крылышком у Google, что в свою очередь дало нам приятные бонусы, так как предоставляло отдельные библиотеки для работы с Angular 2 и это было удобно и быстро. Но и самое крутое, что мы получили — это RealTime Database из коробки. Первые наши ощущения были просто фантастическими.
Нам теперь не надо было постоянно делать запросы к сервису, следить за актуальностью данных на клиенте, ждать пока данные придут на клиент (ну замечу, тут нам помогал и Angular). Все это мы сконфигурировали где-то за день после чего начали непосредственно создавать наш сервис, не отвлекаясь на вопросы инфраструктуры. Сразу замечу, в процессе разработки мы не потратили на данный сервис ни копейки, так как базовая версия бесплатна и ее вполне достаточно для разработки, тестирования и экспериментирования.
Не только хранить, но и искать
И вот как только была готова первая бета возник вопрос в фильтрации данных, и мы осознали первые минусы в Firebase. Как оказалось, процесс выборки данных по большому количеству условий, просто не поддерживается. Есть возможность, отбирать данные только с одним условием, либо собирать несколько значений в одно поле и потом по нему выполнять фильтрацию. Данный подход нас не устраивал, и мы опять приступили к поиску решения.
Конечно, отказывается от Firebase мы не стали, так как этот один минус не перекрывал ту массу достоинств, предоставляемых этим сервисом. Благо, у нас был опыт использования Google Big Query, который мы получили в процессе наших изысканий, и мы решили его применить. Первый плюс то, что это Google, второй — родные и любимые SQL запросы ну и дешевизна владения 1TB данных в месяц бесплатно.
Снова все стало ясно и понятно, написали сервис отправки данных и успешно прикрутили его к Cloud Function. Забыл сказать, про бек в Firebase тоже позаботились, вы можете писать собственные триггеры на Nodejs и вешать их на любое событие в базе данных, а так же на http запрос.
Как вы можете заметить процесс поиска решений и подходов для нас стал ежедневной задачей, так как почти каждый день мы сталкивались с новыми вызовами, которые надо было оперативно решать.
Не успели мы расслабится и спокойно продолжать создавать наш сервис, как началось тестирование фокус группой, и мы осознали, что пользователи привыкли очень быстро переключать фильтры и хотят сразу видеть результат их работы. Такие требования заставили нас отказаться от Big Query и искать что-то новое. Так как Big Query нам давал скорость ответа максимум 2 секунды и это при минимальном объёме данных. Тут их конечно не за чем ругать, так как сервис этот предназначен для обработки больших объемов информации, а не для быстрой реакции на кучу последовательных запросов.
В результате мы остановили свой выбор на Elastic Search. Данный продукт позволил нам построить быстрый поисковый движок, наша фильтрация стала отвечать требованиям наших пользователей. Тут много рассказывать не буду, так как данный продукт стал набирать популярность и информации по нему достаточно. Единственное, что хочу отметить, для данного продукта нужна виртуальная машина, которую надо где-то хостить. Данную возможность предоставляет как Google так и Microsoft, так что выбор за вами. Сконфигурировать ее так же просто используя ресурс bitnami. Мы для себя выбрали 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 возвращает его, но перед этим, подкидывает в него необходимые мета теги. В результате получилось хорошо и уже 3 месяца полет нормальный. Кстати, хостим мы все это тоже на Azure по все тем же сторонним факторам.
CDN наше все
Вот и снова некоторое время стабильности, и относительно спокойной работы. И не кто не думал, что сюрприз нас ждет со стороны Facebook. В один прекрасный день оказалось, что шаринг в FB не работает. Сначала мы думали, что это связанно с ужесточением политик безопасности в FB, потом с блокировкой IP, но так причины мы и не нашли. Обращались в поддержку как FB так и Firebase, но каждый пинал на другого.
Единственное, мы определили, что проблема в урлах к картинкам, которые у нас хранились в сторедже Firebase, а урл, скажу вам сразу, там очень специфический. Решили мы перевести весь статический контент так же на Azure и скажу я вам это решение было правильным, так как скорость загрузки фото возросла, ну и управлять этим всем, можно более гибко и прозрачно.
Подытожим
На данный момент мы уже в продуктиве 3 – тий месяц, постоянно ведем улучшение и расширение функционала. Для управления версиями конечно же используем Git, понемногу автоматизируем сборки и деплой. В день получаем порядка 450 новых уникальных заходов, бывают скачки до 1000 пользователей. И все это работает.
Что бы хотелось просуммировать из всего сказанного:
- Не надо пытаться за счет одного сервиса или одной технологии решать все задачи, которые появляются у вас в проектах.
- Старайтесь разрабатывать универсальные модули для большей гибкости в будущем.
- Выбор поставщика облачных сервисов вопрос сугубо личный, так как в целом все они предоставляют одинаковый набор сервисов. Остается вопрос в цене и ваших предпочтениях.
- Разрабатывайте свое решение так, чтобы иметь возможность мигрировать между разными поставщиками сервисов и технологиями или хотя бы продумывайте стратегию возможного переезда.
- Ну и не бойтесь экспериментировать.
Автор: Escapewithpro.com
