Что нужно, чтобы создать сервис знакомств Meet

Всем привет ! Это продолжение моей первой статьи про сервис знакомств в Telegram - Meet. Постараюсь ответить на вопрос, какие технологии оказались ключевыми при создании сервиса.

Главное, что нужно понимать, что это возможность запустить свой фронт WEB внутри приложения Telegram, возможно чем-то похоже на PWA. У них даже есть свой манифест. Telegram взял курс на развитие своего Магазина приложений TWA и интеграцией его с блокчейном TON. Приложение Meet еще не интегрировано с блокчейном, но есть планы по интеграции и оплаты подписки через блокчейн по миру.

Чтобы наше приложение стало реативным и быстрым, мы применили несколько технологий по доставке скриптов и изображений. Telegram выполняет свою обработку изображений при отправке в бот и это вся помощь. Далее нам было необходимо где-то кешировать изображения и скрипты, в чем нам и помог cdn. И с помощью своего CI/CD все отправляем во время сборки версии для продакшена. Во время сборки выполняем некоторые алгоритмы сжатия скриптов, i18n файлов и изображений.

Проблема с нашим CDN:

Наш CDN от VK не поддерживает регион Азии и Европы, хотя пишут, что по запросу готовы их подключить. Поэтому через VPN наш сервис не доступен.

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

Когда вы оптимизировали загрузку приложения вы должны сходить за данными и вернуть их. И тут мы знакомимся с технологией хранения в Meet.

Мы используем:

MongoDB для хранения данных
Redis и быстрый кеш

Выбор инструмента конечно зависит от технологий, но самое главное конечно, это умение им пользоваться. Чтобы понять, что с MongoDB могут быть проблемы, мы провели НТ(Нагрузочное тестирование) не выполняя работ по оптимизации. Сохраняем результаты и приступаем к оптимизации.

Если будут вопросы, как мы проводили НТ, то спрашивайте в комментариях, расскажу подробнее.

Какие выводы надо сделать при оптимизации:

Индексировать данные
Уменьшить кол-во обращений к БД если это можно не делать
Оптимизировать сам запрос к бд в различных функциях приложения

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

Уменьшение кол-во обращений к БД

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

В нашем случае мы использовали Redis. Ранее запрос в БД это цепочка вызовов к разным таблицам, асинхронная, пусть даже с помощью Promise.all(). Теперь это помогло сделать только один запрос, к примеру поиск партнеров. Профиль клиента уже в кеше и ряд функций мы тоже поместили в кеш. Все что лежит в кеше мы не боимся потерять, это главный принцип хранения в нем.

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

Ну и у всех данных в Redis можно задать время хранения, поэтому мы настроили его для разных данных по необходимости.

Еще немного про оптимизацию запросов к БД

Сам запрос можно оптимизировать некоторыми финтами:

Использовать агрегирующие запросы типа countDocuments
Использовать сложные условия типа $ne $nin $in $or $geometry
Использовать bulkWrite

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

И помните: