DOU Проектор: Escapewithpro — наш досвід розробки travel-сервісу для бронювання турів

У рубриці DOU Проектор всі охочі можуть презентувати свій продукт (як стартап, так і ламповий pet-проект). Якщо вам є про що розповісти — запрошуємо взяти участь. Якщо ні — можливо, серія надихне на створення власного made in Ukraine продукту. Питання і заявки на участь надсилайте на [email protected].

Привіт, я Андрій Шкіря. Зараз я займаюся проектом Escapewithpro — сервісом для пошуку та бронюванню авторських турів. Ось декілька вражень, які отримала наша команда в процесі створення сервісу, якими я і хочу з вами поділитися.

Спочатку кілька слів по себе. За понад 14 років в ІТ мені довелося працювати на різних позиціях та в багатьох проектах. Починалося все з проектів для державних організацій та підприємств, яких було досить багато. Потім проекти для великих приватних компаній, банків, а також створення власних продуктів. Усе це допомогло акумулювати багато різнопланового досвіду та розуміння специфіки роботи на кожній позиції — підходів до побудови як проекту, так і команди. Процес розробки виявився для мене найбільш цікавим, а весь отриманий досвід допомагає вирішувати будь-які складні виклики.

Скажу одразу Firebase — це фантастика. Ти отримуєш неймовірне відчуття, коли дані на сайті оновлюються без будь-яких перевантажень сторінки. Тобі не потрібно весь час слідкувати за актуальністю даних та намагатися зменшити надмірну кількість запитів тої самої інформації. Angular у свою чергу підкинув нам декілька дуже невтішних сюрпризів, але давайте по порядку.

Ідея

Минув майже рік відтоді, як наша команда вирішила змінити напрямок діяльності та спробувати себе в новому амплуа. Раніше ми займалися створенням рішень для корпоративних клієнтів та мали досить непогані успіхи та великий багаж досвіду за плечами. Тільки одна ситуація нас бентежила: не завжди створені нами продукти знаходили очікуваний відгук у кінцевого користувача. Причин тому було багато, починаючи з нерозуміння як замовником, так і виконавцем кінцевого результату, закінчуючи всілякими обмеженнями з боку корпоративних платформ та бізнес-правил. Ще нам здавалося, що коли ти працюєш безпосередньо з кінцевим користувачем, то все стає прозорішим і зрозумілим. Та і всі ми плекали надію зробити щось нове і невідоме, але круте і технологічне. Ось так з’явилася ідея створити продукт Escapewithpro — сервіс, де зібрані авторські тури від досвідчених мандрівників. Наразі на сайті можна здійснювати пошук та бронювання турів.

Реалізація

Першим викликом для нас був пошук правильної бізнес-ідеї та платформи для побудови продукту. Оскільки команда в нас невелика, необхідно було робити всім усе і одразу. Перед нами постало важливе питання кваліфікації та досвіду в різних сферах — як ІТ, так і організаційно-маркетингових. Виявилося, що зі всіма проблемами можна розібратися за досить короткий час, маючи під рукою інтернет, бажання та підтримку товариша в складну мить.

Для розробки був вибраний MEAN стек, але без Mongo. Обираючи Angular 2 (зараз уже 5) для клієнтської частини та Node.js для серверної навіть не роздумували довго, оскільки ми вже мали невеликий досвід у цих технологіях і результат нам подобався (у всіх технологіях є свої мінуси, але про це згодом). Одне хочу додати: якщо ви плануєте будувати щось серйозне, необхідно озброюватися серйозними інструментами.

З фреймворками розібралися швидко, а ось з БД було питання: як знайти гнучкий, швидкий та доступний механізм для збереження даних? Почався пошук та спроби знайти золоту середину. Ось тут ми і зрозуміли, що немає універсального інструмента на всі випадки життя. Неможливо вивчити одну технологію і за допомогою неї вирішувати всі питання. Кожен підхід має свої плюси і свої мінуси, і дуже важко одразу визначитися на 100% з правильним рішенням. У стартапі це просто неможливо, оскільки ти повинен швидко видавати більш-менш готове рішення для підтвердження гіпотез та швидко його змінювати з появою нових. Необхідно завжди бути готовим до змін і пошуку рішень, які досі здавалося неможливо знайти.

Ми зупинили вибір на сервісі Firebase, який включав у себе базу даних реального часу, хостинг, сховище для збереження статичної інформації, сервіс push-нотифікацій та сервіс авторизації. Цей достатньо потужний набір дозволив нам дуже швидко почати створювати наше концептуальне рішення та випробовувати його в реальних умовах. На додаток до всього він безкоштовний на початкових стадіях розробки та тестування, але в подальшому все ж таки доведеться платити. Хоча усе залежить від вашої моделі даних та їх використання.

У цілому база не дуже росте за обсягом. У нас за півроку набралося лише 8 МБ, але треба бути уважним із завантаженням даних на клієнт. Дані завантажуються кожен раз, коли ви перевантажуєте сторінку. Таким чином кожна нова сесія потребує нового завантаження, а це вже платний трафік. Безкоштовна частина складає 10 ГБ завантаження даних на клієнт за місяць, а далі — по одному долару за гігабайт.

Найбільше вражає у цьому сервісі real time. Редагування контенту та його динамічне завантаження без будь-якого дублювання. Це для нас було як магія. Рекомендую спробувати, ви не пошкодуєте. Тим паче для Angular використання дуже просте. Ми в своїй роботі користуємося модулем Angularfire.

Також існує дуже великий мінус при пошуку даних у базі. Неможливо знайти дані з декількох умов одночасно, і це підштовхнуло нас до подальших пошуків. Спочатку ми використовували Google Big Query для побудови фільтра, але зіткнулися з проблемою швидкості відповіді від сервісу. Вона була достатньо малою як для сервісу фільтрацій, тому що він створений для обробки великих масивів даних і швидкість відповіді в нього далеко не на першому місці. Ось і знову починаєш шукати рішення. Спочатку це дуже бентежило, а потім починаєш розуміти, що це нормальний процес і з кожною такою проблемою ти стаєш досвідченішим.

Урешті-решт ми зупинилися на Elasticsearch, який ми використовуємо для фільтрації всіх наших турів у реальному часі. Наразі в нас їх приблизно 200, але зі збільшенням обсягів зменшення швидкості не було помічено.

SEO для Single Page Application

Найбільш складним викликом у розробці виявилася доступність нашого рішення для пошукових ботів та шерінгу. Коли ми починали розробку, ніхто про це навіть не подумав, а варто було. На етапі тестової експлуатації постало перше просте завдання шарити посилання в соціальних мережах та усіляких месенджерах. Що може бути простіше — береш посилання та відправляєш. Але при публікації повинен з’явитися заголовок та опис і ще класна фотка, а в нас одне посилання.

Почали вивчати це питання, і виявилося, що в SPA (Single Page Application) пошуковий бот бачить лише index.html у всьому його мінімалізмі. Ми можемо додати og-теги автоматично, але ж нам потрібна індивідуальна картка для кожного нашого посилання.

Після нетривалих пошуків знайшли одне рішення, яке тоді здалося вирішенням усіх проблем, — Angular Universal. Це спеціальний модуль для серверного рендеренгу вашої сторінки та передачі клієнту вже готового html-файлу зі всім контентом та розміткою. Налагодити свій проект для використання цього модулю досить легко (в CLI 6.0 це виконується майже однією командою), але, як я вже казав, у нас проект уже на тестовій експлуатації з досить великою кількістю власних та сторонніх модулів.

Ми почали переносити та підлаштовувати нашу функціональність під серверний рендерінг. Декілька модулів на початку довелося зовсім видалити, а деякі переписати. Найскладнішим та зрештою і неможливим було змусити сторонні модулі коректно працювати на серверній стороні, оскільки вся сторінка повинна бути сформована на сервері, а це включає функціонування всіх необхідних модулів без браузера. Звичайно, є можливість визначити ті частини, які формуються на сервері, і ті, які вже в браузері, але тоді ми майже весь функціонал повинні відображати в браузері. Такий підхід виявився недостатнім, і після багатьох годин намагань ми почали шукати альтернативне рішення. І воно таки знайшлося. Дуже допомогла інформація, яку ми знаходили в процесі вирішення проблем із серверним рендерінгом.

Як я вже казав, нам необхідно було підготувати статичний контент для пошукових роботів у відповідності до посилання. Таким чином ми за допомогою Express.js опублікували наше рішення та почали обробляти всі запити, які надходили до index.html. У відповідності до запиту ми формували необхідні og-теги, статичний контент та вбудовували його в html-сторінку і віддавали її браузеру.

Після того як сторінка завантажувалася, відпрацьовували скрипти та будувалася повноцінна сторінка з необхідним нам контентом. У такому рішенні пошуковий бот отримував всю необхідну інформацію та відображав необхідні нам картки сторінок при шерінгу.

У подальшому постало питання індексації нашого сайту для доступності та просування в пошукових сервісах. Це завдання для нас було більш легким, оскільки в нас був уже готовий механізм. Нам потрібно було тільки додати умови визначення запитів та процес формування статичного контенту на сторінці. Також ми почали будувати файл sitemap.xml та додавати schema.org розмітку на сторінку, що дозволило пошуковим результатам виглядати більш презентабельно.

Наша команда

Ігор — засновник проекту. Він має вагомий досвід у сфері ІТ та декілька власних компаній з розробки програмного забезпечення. При цьому завжди любив подорожувати. Саме жага до подорожей та бажання допомогти людям побачити нетуристичні місця та подорожувати частіше надихнули його на створення цього проекту.

Андрій, тобто я, — CTO. Відповідаю за технології та інновації, напрограмував левову частку сайта. Роблю всілякі круті технологічні штучки, такі як швидке завантаження великих фото, миттєві фільтри й інше.

Толік — талановитий розробник. Зробив разом з Андрієм вже не одну систему. Завдяки йому користувачі можуть у нас на сайті чатитися, отримують SMS- і email-нотифікації. Він налагодив інтеграцію з ticketsUA, а незабаром ще буде онлайн-оплата.

Саша — працює з Pro (організаторами турів). Саме вона шукає найцікавіші пропозиції та найяскравіших організаторів мандрівок. Також Саша відповідає за комунікації з Pro і з користувачами.

Оля — відповідає за контент на сайті, PR та роботу з лідерами думок.

Проект стрімко розвивається, тому нещодавно до нашої команди приєдналася Таня. Вона займається зйомками відеоінтерв’ю, дизайном і маркетингом, включаючи Facebook, Instagram, YouTube.

Результати та плани на майбутнє

Майже за рік ми побудували онлайн-сервіс та досягли певних результатів:

  • кількість активних та унікальних турів — 130;
  • кількість тур-лідерів — 46;
  • за липень на сервіс зайшло більше ніж 10 000 користувачів;
  • кількість сторінок, які продивились користувачі у липні, — більше ніж 200 000.

Головні виклики, які нас спіткали:

  • постійний пошук інформації;
  • постійне вивчення нових технологій;
  • постійна зміна функціоналу;
  • робота в будь-який час та в будь-якому місці.

Плануємо додати до сервісу такі можливості:

  • пошук квитків;
  • онлайн-платежі;
  • побудова блогу;
  • створення конструктора тематичних сторінок.

Дякую за увагу. Пишіть, якщо було цікаво, та здавайте питання. Будемо тримати вас у курсі нових звершень.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



28 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Чому не реакт? Там вибір інструментів наче більший і спеціалістів на ринку більше.
Взагалі стаття цікава, дякую!

CTO->8MB->BigQuery — убило. а сервіс класний. не зрозумів для чого юзера заставляти реєструватись, підтверджувати телефон і вибирати чи він мандрівник, коли він хоче оплатити тур. вангую це вам трохи псує конверсію.

Розумію ваше здивування таким вибором, але спробую пояснити. На той момент коли постало питання побудови фільтрів, база була в FireBase. Треба шукати альтернативу, SQL бази як сервіс коштують достатьньо догоро, для Elasticsearch теж треба піднімати открему віртуалку, яка коштує грошей. На той момент Google BigQuery знаходилось під рукою, було безкоштовним та давало можливість побудови комплексних запитів та поступове підвантаження даних. Зрозуміло що цей сервіс побудований для інших завдань, але нам було необхідно швидко реалізувати необхідний функціонал для можливості перевіряти роботу сервісу та шукати далі оптимальні рішення. Це було тимчасове рішення, яке допомогло нам побачити загальну картину, та проводити подальші покращення та зміни.

Відповім на питання по реєстрації користувачів. Вона є обов’язковою з кількох причин:
1) Після бронювання організатор тура (ми його називаємо Pro) зв’язується з клієнтом.
2) Для багатьох користувачів важливо питання безпеки і більшість хоче розуміти, з ким вони їдуть — як ті, хто купує, так і ті, хто пропонує. Підтвердження телефона, емейла, соціальних акаунтів зменшує ризики шахрайства. Пізніше ми ще додамо перевірку паспорта як це робить, наприклад, airbnb.com. Доречі, реєстрація користувачів є типовою практикою на всіх основних букінг-сервісах таких як вже названий airbnb.com та booking.com.

при оплаті юзер залишає пошту або/і телефон. залишати неправильні дані, коли заплатив гроші було б дивно. я не про потрібність реєстрації. а про те яким чином і на якому етапі вона відбувається. хотілося б, коли вибрав тур і забронював побачити «введіть, будь ласка, ше оце і оце, шоб завершити реєстрацію». або як в блаблакарі. ти за секунду зареєструвався через фб, а потім шоб твій профіль мав вищий рейтинг і викликав більше довіри — додаєш інші підтвердження.

Досить цікава ідея, звісно є альтернативи яким більше довіряєш як iloveasia, bodo travel.
Але у вас типу напряму з гідом, тільки от питання надійності і гарантій при замовленні через ваш сервіс якісь надаються.
Як монетизуєтесь?
Яка стратегія в маркетингу?
Скільки успішних замовлень?

Раді, що ідея сподобалася. Згоден, що кожен молодий стартап повинен заслужити довіру користувачів. Нам 4 місяці і ми над цим працюємо кожен день і ніч. Доречі, на нашому сайті публікують тури в тому числі і організації рівня наведених вами. Всі ми разом з ними працюємо над тим, щоб надихнути людей подорожувати по нетуристичним маршрутам, які часто бувають значно яскравіше ніж протоптані доріжки. При тому на нашому сайті зібрана велика кількість організаторів і у користувача є великий вибір — у нас вже публікували свої тури 65 організаторів з різними тревел-форматами такими як яхт-тріпи, авто-тріпи, вело, гастро, вино, віскі, арт, треккінг, скалелазання, духовне, йога, фітнес і інші.

Питання надійності одне з ключових для нас. Для цього на сайті діє система відгуків, рейтингів і рекомендацій, у кожного гіда в профілі видно, чи підключено профілі facebook і twitter і скільки там друзів/підписників, з кожним гідом ми спілкуємося, з багатьма записуємо відео-інтерв‘ю і незабаром вони з‘являться як на сайті так і на нашому новому youtube-каналі. Також в instagram @escapewithpro.ua ви можете подивитися сторіз від багатьох гідівз нашого сайту з різних куточків світу.

Стратегія маркетингу розроблена і реалізовується. Настільки, наскільки у нас вистачає досвіду. Ми не є супергуру в маркетинзі, ми такі самі айтішники як і аудиторія dou. Просто в якийсь момент вирішили, що хочеться зробити щось більше, ніж аутсорсити — допомогти в чомусь людям. А подорожі — це те, що нас дуже надихає.

Досі не можу збагнути, навіщо на такому проекті

База даних реального часу

Прошу привести приклад як було б зі звичайною базою даних та які суттєві переваги дає такий підхід. Недолік було приведено в статті — для кожної сесії дані мають завантажуватись щоразу, що збільшує трафік. Які суттєві переваги, окрім

Це для нас було як магія

для розробника, отримує користувач від такого підходу? Які суттєві переваги це дає бізнесу в Вашій сфері?

Для бізнесу переваги в тому що це сервіс який в себе включає готову підтримку, розгортання, розширення, як об’ємів так і динамічне навантаження користувачів. Також готова авторизація з використанням 7ми провайдерів. Пуш нотифікації.
Для користувачів. База реального часу підвищує швидкість завантаження даних. Там користувачі можуть бачити зміни даних в реальному часі, тобто завжди актуальні, з мінімальним використанням трафіку.
Для розробника. Не існувало проблем з моделью даних, так як вона постійно зміниться. В не реляційній базі даних вона не жорстка і її динамічно можна змінювати. Допомога в побудові месенджера. Також для Angular існує спеціальний модуль для роботи з БД (AngularFire), що дуже полегшувало роботу з даними.

Вітаю колег! :)

Так, а где проблемные моменты с Angular?

Проблемы с SEO и Angular Universal. Так как завести его с сторонними модулями довольно проблематичним и у меня до конца так и не удалось.

А с какими сторонними модулями вы пробовали?

GoogleMaps, AngularFire, ng2-img-max, ng2-img-cropper ...

Проект супер! Молодцы

У вас усього 200 турів а ви видумуєте якісь хитромудрі рішення для пошуку у базі?!
Да звичайний селект при кожному запиті буде працювати швидше і дешевше для бізнесу ніж пошуки цих оптимізацій наперед :)

В тому то і питання, що запити досить складні та комплексні. Плюс не реляційна база даних. А також, заклавши основу, в майбутньому легше маневрувати.

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

Ок, а можна тоді детальніше або якийсь елементарний приклад? Я не розумію де тут складність. У вас досить невелика кількість турів, кількість фільтрів на сайті також мінімальна.

Сім категорій фільтрів, які можуть накладатися в різній послідовності. База даних реального часу (firebase) не дозволяє робити комплексні запити, тому було використано elasticsearh для можливості досить швидко отримувати результати пошуку з різними запитами. В подальшому на цій платформі будемо реалізовувати повнотекстовий пошук.

Тобто, від послідовності фільтрів результат може змінюватись? А можна приклад?

Наприклад фільтр: відібрати тур в Італію ціна якого знаходиться в діапазоні 100- 600 (при тому що ціна змінюється відносно поточної дати), період з 2 до 6 днів. Також в радіусі сьогоднішнього дня плюс/мінус від 7 до 60 днів. А також з набором різних інтересів, мов та груп. Такий запит в Firebase стандартними засобами зробити неможливо.

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

Серьёзно, опытная команда не подумала про SEO ?

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

Дякуємо за комплімент про «досвідчену команду») Ми є звичайними айтішниками. І так, не про все подумали на початку. Вирішили, що якщо поділимося по чесному з комьюніті, то ця інформація може комусь допомогти врахувати це напочатку. Ми були сильно здивовані, коли дізналися, що гуглівський Angular не дуже товаришує з гуглівськими пошуковими алгоритмами. Ми знали, що є ньюанси, але не думали, що ситуація настільки «глибока».

Перепрошую, але то не комплімент, а враження про ваше власне позиціонування, яке я особисто отримав зі статті (абсолютно суб’єктивно, зрозуміло)

Раніше ми займалися створенням рішень для корпоративних клієнтів та мали досить непогані успіхи та великий багаж досвіду за плечами.
Обираючи Angular 2 (зараз уже 5) для клієнтської частини та Node.js для серверної навіть не роздумували довго, оскільки ми вже мали невеликий досвід у цих технологіях
Ігор — засновник проекту. Він має вагомий досвід у сфері ІТ та декілька власних компаній з розробки програмного забезпечення.

Підписатись на коментарі