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