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

Одна вещь, которую я знал, когда впервые разрабатывал Kwippe, заключалась в том, что наше искусство должно было подтягиваться молниеносно, иначе пользователи отключатся. Кроме того, результаты поиска должны были быть возвращены почти мгновенно, с максимально релевантными произведениями искусства. Кроме того, нам нужно было разработать связанные ключевые слова и категории для тысяч и тысяч изображений. Все это должен был сделать только 1 человек: я.

Страшный.

Ах, и я забыл добавить, что это нужно было сделать в рамках общего бюджета на обувь (например, меньше, чем цена хорошей пары кроссовок в месяц). Поэтому я начал исследовать различные платформы для доставки результатов поиска в приложение, а также тарифные планы для баз данных, API-сервисов отдыха и любых других сервисов, которые утверждали, что помогают обслуживать ваши данные в каком-то автоматическом, молниеносно быстром формате.

Я быстро понял, что Firebase — мой провайдер аутентификации и первый удар по базе данных и хранилищу — может очень быстро стать ужасно дорогим. 1 доллар за гигабит данных? Помимо того, что это в 10 раз выше обычной скорости, это плохой знак для скорости, с которой ваши данные будут обслуживаться, если вы начнете действительно набирать обороты с кучей одновременных пользователей. И никто не работает так усердно, чтобы запустить следующее величайшее приложение в мире, чтобы медленно расти! Хотя мне по-прежнему нравится Firebase для аутентификации и базовой информации о пользователе, я знал, что он не сработает для обслуживания моих данных — в дополнение к тому факту, что это невозможно для работы в автономном режиме или в мобильном приложении.

Итак, после того, как я опробовал 4 или 5 других API-сервисов базы данных/отдыха, я начал задаваться вопросом, не мог бы я придумать что-то лучше — систему, в которой пользователи могли бы получить доступ ТОЛЬКО к тем данным, которые им нужны, через наименьшие возможные фрагменты данных, доставленные как можно быстрее. Когда я начал читать о двоичных и текстовых данных и о том, насколько эффективнее и быстрее предоставлять пользователям двоичные файлы, я понял, что база данных моей мечты может на самом деле вообще не быть базой данных.

Что! Вы должны быть сумасшедшим! Приложение с десятками тысяч, а со временем и сотнями тысяч изображений и ключевых слов, работает вообще без базы данных? Ага. Вот что я вам говорю. Только файловая система, детка. И вот как я это сделал.

Во-первых, я отказался от идеи, что только потому, что мне нужен JSON, я должен хранить данные как JSON. Просмотрел все: Protocol Buffers, FlatBuffers, MessagePack и пару других. Но, честно говоря, документация для большинства вещей в Javascript была довольно ужасной, и главное, что я вынес из всего этого исследования, это то, что BINARY был ключевым. Поместите свои вещи в Binary, и вам станет лучше. В порядке. Я выбрал CBOR для своего двоичного формата просто потому, что с ним было очень легко иметь дело, документация была превосходной, и я мог легко кодировать эти данные в CBOR через Node.js, а затем декодировать их на стороне клиента, без проблем. Но это был только первый шаг к блаженству без баз данных.

Вторая часть была чем-то, о чем я не читал ни в одном из вышеперечисленных ресурсов, и уменьшил размер моих двоичных файлов более чем на 50%, а в некоторых случаях даже больше. Я использовал потрясающую, очень простую библиотеку сжатия строк, чтобы сжать строки перед кодированием в CBOR. Я даже конвертирую массивы в строки перед сохранением.

Затем нужно было просто разработать рациональную систему для размещения моих художественных файлов, а также файлов с ключевыми словами в папках и создать индексный файл для каждой папки — и я был готов обслуживать как изображения, так и предварительно кэшированные поисковые запросы по ключевым словам. , все из файловой системы. Дополнительным преимуществом является то, что все файлы изображений, условия поиска и индексы кэшируются вашим браузером, так что, если я не обновлю файлы, пользователю не придется снова запрашивать эти данные. Такой вид управления кешем без кода — это, безусловно, блаженство для этого программиста, так как программное управление всем этим — еще одна головная боль, которая мне не нужна.

Теперь вы можете спросить: «Хорошо, но как, черт возьми, вы создаете всю эту чушь!» Простой, с Node.js. С моей стороны 2 системы баз данных: великолепная и волшебная RethinkDB на моей локальной машине, а также старый добрый Node Dirty для временных операций. Таким образом, RethinkDB содержит все наши материалы и используется для регенерации наших ключевых слов и связанных с ними определений ключевых слов, которые необходимо выполнять заново всякий раз, когда вы добавляете иллюстрацию. Я понимаю, что это не лучшая система, но на самом деле нет никакого способа обойти это, если вы хотите использовать систему без базы данных.

Эту часть можно было бы легко выполнять каждую ночь с помощью chron job.

Что касается получения связанных ключевых слов для изображений — я разработал несколько скриптов на Node.js для запросов к службам Word API, которые возвращают красивые списки синонимов, антонимов и даже категорий для каждого введенного термина. Затем я сопоставляю это с терминами, которые действительно существуют в нашей базе данных, чтобы пользователю не предлагалось слово, для которого у нас на самом деле нет изображения.

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