GoogleMaps, AngularFire, ng2-img-max, ng2-img-cropper ...
Наприклад фільтр: відібрати тур в Італію ціна якого знаходиться в діапазоні 100- 600 (при тому що ціна змінюється відносно поточної дати), період з 2 до 6 днів. Також в радіусі сьогоднішнього дня плюс/мінус від 7 до 60 днів. А також з набором різних інтересів, мов та груп. Такий запит в Firebase стандартними засобами зробити неможливо.
Для бізнесу переваги в тому що це сервіс який в себе включає готову підтримку, розгортання, розширення, як об’ємів так і динамічне навантаження користувачів. Також готова авторизація з використанням 7ми провайдерів. Пуш нотифікації.
Для користувачів. База реального часу підвищує швидкість завантаження даних. Там користувачі можуть бачити зміни даних в реальному часі, тобто завжди актуальні, з мінімальним використанням трафіку.
Для розробника. Не існувало проблем з моделью даних, так як вона постійно зміниться. В не реляційній базі даних вона не жорстка і її динамічно можна змінювати. Допомога в побудові месенджера. Також для Angular існує спеціальний модуль для роботи з БД (AngularFire), що дуже полегшувало роботу з даними.
Проблемы с SEO и Angular Universal. Так как завести его с сторонними модулями довольно проблематичним и у меня до конца так и не удалось.
Сім категорій фільтрів, які можуть накладатися в різній послідовності. База даних реального часу (firebase) не дозволяє робити комплексні запити, тому було використано elasticsearh для можливості досить швидко отримувати результати пошуку з різними запитами. В подальшому на цій платформі будемо реалізовувати повнотекстовий пошук.
Спасибо
Как я уже писал, имели опыт построения корпоративных систем, для использования внутри компаний. Соответственно не какой речи о SEO не было.
В тому то і питання, що запити досить складні та комплексні. Плюс не реляційна база даних. А також, заклавши основу, в майбутньому легше маневрувати.
Розумію ваше здивування таким вибором, але спробую пояснити. На той момент коли постало питання побудови фільтрів, база була в FireBase. Треба шукати альтернативу, SQL бази як сервіс коштують достатьньо догоро, для Elasticsearch теж треба піднімати открему віртуалку, яка коштує грошей. На той момент Google BigQuery знаходилось під рукою, було безкоштовним та давало можливість побудови комплексних запитів та поступове підвантаження даних. Зрозуміло що цей сервіс побудований для інших завдань, але нам було необхідно швидко реалізувати необхідний функціонал для можливості перевіряти роботу сервісу та шукати далі оптимальні рішення. Це було тимчасове рішення, яке допомогло нам побачити загальну картину, та проводити подальші покращення та зміни.