Иногда задачи в проектах выглядят очень просто… Пока ты не начинаешь их делать.
У нас был проект с уже внедрённым поиском на OpenSearch. Всё работало: индексы, фильтры, кастомная логика запросов — даже своя «мини-ORM» над поиском, через которую фронтенд отправлял сложные query.
И в какой-то момент пришло решение: «Давайте просто заменим OpenSearch на TypeSense.»
Спойлер: это никогда не бывает «просто».
Почему решили менять OpenSearch на TypeSense
На бумаге выглядело логично — TypeSense дешевле в эксплуатации. Казалось, что это технический размен без особых потерь.
Главная проблема: нельзя ломать фронт
Самое важное ограничение — фронтенд не должен заметить никаких изменений.
То есть API остаётся тем же, структура запросов остаётся той же, поведение поиска остаётся тем же. А внутри — полностью другой движок.
Что это означало на практике
Мне нужно было брать запросы, заточенные под OpenSearch, трансформировать их, отправлять в TypeSense и возвращать результат в прежнем формате. По сути — написать полноценный адаптер между двумя разными мирами.
Где всё пошло не по плану
Ожидание: «Ну там клиент поменять и пару запросов поправить».
Реальность:
- разные подходы к фильтрации;
- разный синтаксис query;
- разная работа с индексами;
- разная логика ранжирования.
Проблема в том, что это не просто разные API — это разные философии поиска.
Например: в OpenSearch — гибкий DSL, который позволяет строить запросы практически любой сложности. В TypeSense — упор на простоту и скорость, с намеренно ограниченным синтаксисом. И просто «переконвертировать JSON» не работает — нужно переосмыслить логику запросов целиком.
Что пришлось реально переписать
Фактически пришлось переделывать генерацию query, фильтрацию, агрегации и их аналоги в TypeSense, работу с индексами и вспомогательные утилиты. И всё это — сохраняя поведение 1:1, без права на регрессии, потому что фронт не должен был почувствовать разницу.
Сжатые сроки и немного боли
Классика жанра: время на задачу было сильно недооценено на этапе планирования. И вот тут начинается интересное.
Где реально помог ИИ
Без ИИ-ассистента я бы эту задачу не закрыл в срок. Серьёзно.
ИИ в этом кейсе выступал сразу в нескольких ролях:
- живая документация;
- наставник по незнакомой технологии;
- ревьюер кода;
- генератор заготовок под конкретную задачу.
Причём ты можешь задавать «тупые» вопросы, просить объяснить концепции, сравнивать подходы и генерировать код — и он не устаёт, не раздражается и отвечает мгновенно.
Как это выглядело на практике
Я буквально разбирал кусок OpenSearch-логики, спрашивал, как это реализовать в TypeSense, получал адаптер, тестировал, находил расхождения, возвращался с уточнёнными вопросами — и повторял. И так десятки раз, итерация за итерацией, пока поведение не совпадало.
Важный инсайт
Если раньше новая технология означала: «нам нужен специалист с опытом именно в этом стеке» — то теперь формула изменилась: «нам нужно время и нормально сформулированные вопросы». ИИ сильно снижает порог входа в незнакомую область.
Аналогия (жизненная)
Можно представить это так: ИИ — это как друг, которого ты позвал с собой на разборку. Он очень круто дерётся, НО:
- иногда подтупливает;
- временами отвлекается;
- бывает что бежит впереди паровоза;
- отвечает масло масленое.
Если приправить это хорошим промптом и чётко указывать, кого бить — он реально помогает. И главное: вас уже двое.
Выводы
1. Замена поискового движка — это не замена клиента, это замена архитектуры.
2. Разные search engines — это разные философии, а не просто разный синтаксис.
3. Самое сложное — сохранить поведение 1:1 без изменений на стороне потребителя.
4. ИИ — это не игрушка, а реальный рабочий инструмент, который уже сейчас меняет то, как мы решаем сложные задачи.
Главная мысль
Если вы сталкиваетесь с новой технологией — не нужно паниковать и не нужно срочно искать «сеньора с 10 годами опыта в этом конкретном стеке». Достаточно разобраться в базовых принципах, использовать ИИ как напарника и методично двигаться итерация за итерацией.
Да, я сгорел. Да, это было сложно. Но без ИИ это было быИтог