Я не знаю, как именно назвать Exact:
- In-memory СУБД для обработки публичных данных
- REST API для поиска по JSON
- Поисковый бэкенд для JAMstack сайтов
В общем, это готовый унифицированный бэкенд для поиска, совместимый с любым датасетом. (список словарей с любыми полями)
На входе - данные из СУБД, или из JSON/YAML файла или URL. Через HTTP можно по ним искать. Типичный пример использования - поиск по товарам в онлайн-магазине, на уровне хороших маркетплейсов, вроде яндекс-маркета и Озона.
Зачем это нужно?
- Разработка идет быстрее и дешевле. Поисковый бэкенд уже готов (да в общем-то весь бэкенд к публичным данным готов, только личный кабинет нельзя в Exact реализовать)! Нужно только дать Exact’у данные и обращаться к нему с фронт-енда. Ну и взять с заказчика деньги за разработку бэкенда.
- Поиск очень гибкий, например (на человеческом языке) “Смартфоны от Apple или Samsung, с экраном от 5 до 6.5 дюймов, ценой от X до Y с поддержкой WiFi 802.11ac либо без поддержки, если цена меньше X) " или “Найти все фильмы в которых Джек Никлсон снимался вместе с молодой Одри Хепберн”. Возможно, такая гибкость и не потребуется, но хорошо ведь, когда есть возможность.
- Поиск реактивный во всех смыслах.
- Можно искать через JavaSсript fetch(), обновляя контент страницы результатами поиска без перегрузки страницы. Это очень быстро и приятно для пользователя (только указал, что тебе нужны товары не выше такой-то цены - тут же с экрана исчезли все слишком дорогие, и заблокировались самые дорогие бренды, в которых все равно все дорого).
- Поиск по 1 000 000 записей занимает 200мс (на достаточно обычном “домашнем” железе). Для сравнения, ассортимент крупного гипермаркета - 30-80 тысяч наименований товаров.
- Это заранее безопасно (см ниже).
- Использование API позволяет сделать сами сайты статичными, загружать их быстро, с CDN и в результате - высокие оценки от Google Lighthouse, более высокие позиции в результатах боиска. Ваш SEO специалист будет счастлив.
- Отсутствует нагрузка на основную СУБД при поиске. В черную пятницу ваш сервер не будет перегружен и сможет обработать все покупки, а пользователи будут пользоваться быстрым, не тормозящим сайтом и получат хорошее впечатление от процесса выбора и покупки.
Как это работает
Exact основан на Docker / FastAPI / Evalidate.
При старте - загружает в себя данные и больше не обращается к СУБД/файлам для поиска.
Поисковый запрос с фронтенда приходит в синтаксисе Python expression, например price<123.45 and vendor in ["Apple", "Samsung"]. Запрос компилируется в AST дерево и проверяется через evalidate (чтобы оставить только безопасные запросы и не допустить никаких опасных операций). Затем уже скомпилированный безопасный запрос применяется ко всем записям в датасете. За счет того, что все данные у нас уже в памяти, а код уже скомпилирован - это дает очень высокую скорость (200мс на фильтрацию 1 миллиона записей). Время поиска меньше, чем время, которое уходит на сетевые операции отправки-получения запроса и отрисовку контента.
Дополнительные плюшечки
Read-only доступ (поиск или получение какой-то записи) - анонимный, не требует никакой авторизации. Но тем не менее, можно включить и write доступ (по Bearer токену и с whitelist IP). В этом случае можно перегружать (обновлять) датасет, удалять записи или “патчить” их. Например, когда все запасы товара проданы, можно поставить onstock=False чтобы больше он не находился поиском.
Есть агрегации - например, при указании каких-то параметров поиска (например, бренды), можно сразу получить минимальную и максимальную стоимость (а так же просуммировать или посчитать среднее).
А это безопасно?
Да. Гораздо более безопасно, чем самописно написанный “традиционный” бэкенд работающий с базой. Во-первых, весь стек технологий - open source, и вы можете сами проверить его. Сам exact - достаточно небольшое и простое приложение. Легко убедиться в его безопасности.
К тому же, “параноидальное” использование Exact подразумевает тройную изоляцию:
- Пользовательский запрос проходит фильтрацию через evalidate и не может выйти за пределы песочницы “eval”
- Exact может (и рекомендуется) исполняться внутри docker контейнера. И даже если мы допустим крайне маловероятный “пробой” на предыдущем этапе, все равно, выйти за пределы докер-контейнера взломщику не получится, а внутри контейнера - только публичные данные.
- Exact может быть изолирован от СУБД и получать поисковые данные из файлов или внешних URL с JSON документами. Даже в фантастическм случае, если в докере есть уязвимость, и можно выскочить из контейнера - взломщик остается на бесполезной непривелегированной машине, без доступа к СУБД, на которой, максимум, есть публичные SSH ключи.
Shinhub - реактивный шинный сайт
Для демонстрации есть шинный сайт shinhub.ru, использующий Exact для быстрого поиска по базе товаров.
