Добавить в корзинуПозвонить
Найти в Дзене
Chris Roylance

Stryfe.online предварительные результаты миграции на Couchbase СУБД

Всем привет, ждать следующей статьи не пришлось неделю как в тот раз. И мы продолжаем говорить о развитие социальной сети stryfe.online. Перейдем разу к делу, от части переезд основных компонентов оказался не столь долгим, за исключением разве что capjs, под которую надо будет полностью переделывать все запросы. Благодаря переезду, я пересмотрел подход в некоторых таблицах к формату уникальных ключей, как например информацию о страницах я привязал к коротким названиям ранее, а сейчас использую его как уникальный идентификатор. Да это чуть топорно, но основная информация о страницах храниться в СУБД, а не на фронте. Выглядит это таким образом. Если посмотреть с точки зрения N1QL, то информация о страницах выглядит так. Если кому то интересно, что бы я сделал небольшой обзор на саму Couchbase, пишите в комментарии, сделаю чуть позже. Как БД будет себя вести на больших данных я пока не знаю, но тут удобно, что инстансы СУБД можно поднимать под конкретные назначения, что упрощает масштаби
Оглавление

Всем привет, ждать следующей статьи не пришлось неделю как в тот раз. И мы продолжаем говорить о развитие социальной сети stryfe.online.

Предварительные результаты

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

Благодаря переезду, я пересмотрел подход в некоторых таблицах к формату уникальных ключей, как например информацию о страницах я привязал к коротким названиям ранее, а сейчас использую его как уникальный идентификатор. Да это чуть топорно, но основная информация о страницах храниться в СУБД, а не на фронте.

Выглядит это таким образом.

-2

Если посмотреть с точки зрения N1QL, то информация о страницах выглядит так.

-3

Если кому то интересно, что бы я сделал небольшой обзор на саму Couchbase, пишите в комментарии, сделаю чуть позже.

Как БД будет себя вести на больших данных я пока не знаю, но тут удобно, что инстансы СУБД можно поднимать под конкретные назначения, что упрощает масштабирование, поднимая только то, чего начинает не хватать.

Для простых запросов, на подобие создание записи или найти по id записи хорошо подходит формат NoSQL форматов, как у той же MongoDB.

Как видно на скринах выше, тут нет никакой сложности, все лего и читаемо. Как вы понимаете, перед тем как csrf-токен попадет до функции проверки, будет произведена еще ни одна проверка на корректность данных.

Регистрация пользователя

После того, как ранее созданный функционал я перевел на couchbase, время пришло вернуться к разработке функционала. Я остановился как раз на api регистрации пользователя. В данный момент времени я остановился на валидации данных, которые будут приходить в систему.

Валидацию я создал на основе Zod.js и схема валидации данных для регистрации будет выглядеть следующим образом.

-5

А полный список ошибок, при некорректных данных выглядит так.

-6

Ошибки я стараюсь делать понятные и максимально читаемыми, а то потом сам же буду долго и упорно пытаться разобраться, что я там понаписал.

Из функционала создания пользователя осталось совсем немного, добавить проверку csrf-токена, который будет браться из заголовков, а так же поправить создание пользователя, т.к. это последние по мимо capjs компонента, что я еще не успел переписать, но переписать с классического SQL, на формат создания N1QL не составит много усилий.

На этом пока все, держу в курсе развития проекта, еще увидемся.